You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: exercises/ansible_ripu/2.2-snapshots/README.md
+159-13
Original file line number
Diff line number
Diff line change
@@ -48,13 +48,122 @@ While COW snapshots are not a substitute for traditional full and incremental ba
48
48
49
49
There are a number of different types of snapshot solutions you may choose from. Each has their own benefits and drawbacks as summarized in the table below:
50
50
51
-
| Snapshot type | Works with | Benefits | Drawbacks |
| LVM |<ul><li>Bare metal</li><li>On-prem VMs</li><li>Cloud*</li></ul>|<ul><li>No external API access required</li><li>Scope can be just OS or everything</li></ul>|<ul><li>Free space required in volume group</li>Snapshots can run out of space if not sized correctly</li><li>Automation must backup and restore /boot separately</ul>|
54
-
| VMware |<ul><li>On-prem VMs (ESX)</li></ul>|<ul><li>Simple and reliable</li><li>Scope includes everything</li></ul>|<ul><li>Doesn't support bare metal, etc.</li><li>Using VMware snapshot for over 3 days is discouraged</li><li>Getting API access can be difficult</li><li>No free space in datastores because of overcommitment</li><li>Everything scope might be too much</li></ul>|
55
-
| Amazon EBS |<ul><li>Amazon EC2</li></ul>|<ul><li>Simple and reliable</li><li>Unlimited storage capacity</li><li>Scope can be just OS or everything</li></ul>|<ul><li>Only works on AWS</li></ul>|
56
-
| Break Mirror |<ul><li>Bare metal</li></ul>|<ul><li>Alternative to LVM for servers with hardware RAID</li></ul>|<ul><li>Significant development and testing effort required</li><li>RAID and Redfish API standards vary across different vendors and hardware models</li></ul>|
57
-
| ReaR |<ul><li>Bare metal</li><li>On-prem VMs</li></ul>|<ul><li>Method of last resort if no snapshot options will work</li></ul>|<ul><li>Not really a snapshot, but does offer boot ISO full recovery capability</li></ul>|
51
+
<tableborder="1"cellpadding="5"cellspacing="0">
52
+
<thead>
53
+
<tr>
54
+
<th>Snapshot type</th>
55
+
<th>Works with</th>
56
+
<th>Benefits</th>
57
+
<th>Drawbacks</th>
58
+
</tr>
59
+
</thead>
60
+
<tbody>
61
+
<tr>
62
+
<td>LVM</td>
63
+
<td>
64
+
<ul>
65
+
<li>Bare metal</li>
66
+
<li>On-prem VMs</li>
67
+
<li>Cloud*</li>
68
+
</ul>
69
+
</td>
70
+
<td>
71
+
<ul>
72
+
<li>No external API access required</li>
73
+
<li>Scope can be just OS or everything</li>
74
+
</ul>
75
+
</td>
76
+
<td>
77
+
<ul>
78
+
<li>Free space required in volume group</li>
79
+
<li>Snapshots can run out of space if not sized correctly</li>
80
+
<li>Automation must backup and restore /boot separately</li>
81
+
</ul>
82
+
</td>
83
+
</tr>
84
+
<tr>
85
+
<td>VMware</td>
86
+
<td>
87
+
<ul>
88
+
<li>On-prem VMs (ESX)</li>
89
+
</ul>
90
+
</td>
91
+
<td>
92
+
<ul>
93
+
<li>Simple and reliable</li>
94
+
<li>Scope includes everything</li>
95
+
</ul>
96
+
</td>
97
+
<td>
98
+
<ul>
99
+
<li>Doesn't support bare metal, etc.</li>
100
+
<li>Using VMware snapshot for over 3 days is discouraged</li>
101
+
<li>Getting API access can be difficult</li>
102
+
<li>No free space in datastores because of overcommitment</li>
103
+
<li>Everything scope might be too much</li>
104
+
</ul>
105
+
</td>
106
+
</tr>
107
+
<tr>
108
+
<td>Amazon EBS</td>
109
+
<td>
110
+
<ul>
111
+
<li>Amazon EC2</li>
112
+
</ul>
113
+
</td>
114
+
<td>
115
+
<ul>
116
+
<li>Simple and reliable</li>
117
+
<li>Unlimited storage capacity</li>
118
+
<li>Scope can be just OS or everything</li>
119
+
</ul>
120
+
</td>
121
+
<td>
122
+
<ul>
123
+
<li>Only works on AWS</li>
124
+
</ul>
125
+
</td>
126
+
</tr>
127
+
<tr>
128
+
<td>Break Mirror</td>
129
+
<td>
130
+
<ul>
131
+
<li>Bare metal</li>
132
+
</ul>
133
+
</td>
134
+
<td>
135
+
<ul>
136
+
<li>Alternative to LVM for servers with hardware RAID</li>
137
+
</ul>
138
+
</td>
139
+
<td>
140
+
<ul>
141
+
<li>Significant development and testing effort required</li>
142
+
<li>RAID and Redfish API standards vary across different vendors and hardware models</li>
143
+
</ul>
144
+
</td>
145
+
</tr>
146
+
<tr>
147
+
<td>ReaR</td>
148
+
<td>
149
+
<ul>
150
+
<li>Bare metal</li>
151
+
<li>On-prem VMs</li>
152
+
</ul>
153
+
</td>
154
+
<td>
155
+
<ul>
156
+
<li>Method of last resort if no snapshot options will work</li>
157
+
</ul>
158
+
</td>
159
+
<td>
160
+
<ul>
161
+
<li>Not really a snapshot, but does offer boot ISO full recovery capability</li>
162
+
</ul>
163
+
</td>
164
+
</tr>
165
+
</tbody>
166
+
</table>
58
167
59
168
The following sections explain the pros and cons in detail.
60
169
@@ -70,7 +179,7 @@ Logical volumes are contained in a storage pool known as a volume group. The sto
70
179
71
180
To create logical volume snapshots, there must be free space in the volume group. That is, the total size of the logical volumes in the volume group must be less than the total size of the volume group. The `vgs` command can be used query volume group free space. For example:
72
181
73
-
```
182
+
```bash
74
183
# vgs
75
184
VG #PV #LV #SN Attr VSize VFree
76
185
VolGroup00 1 7 0 wz--n- 29.53g 9.53g
@@ -134,11 +243,48 @@ This practice helps to enforce a key tenet of the RHEL in-place upgrade approach
134
243
135
244
With these concepts in mind, let's consider if we want to include the apps and app data in what gets rolled back if we need to revert the RHEL upgrade:
136
245
137
-
| Snapshot scope | Benefits | Drawbacks |
138
-
| -------------- | -------- | --------- |
139
-
| OS only |<ul><li>Simplifies storage requirements</li><li>Preserves isolation of OS changes from apps and app data</li><li>Reduces risk of rolling back impacting external apps</li></ul>|<ul><li>Probably not possible with VMware snapshots</li><li>Discipline required to avoid temptation of trying quick app changes to fix impacts</li></ul>|
140
-
| OS and apps/data |<ul><li>Reduces risk if trying to fix app impact during maintenance window</li><li>Helpful if app impact could lead to app data corruption</li></ul>|<ul><li>More storage space required</li><li>Rolling back app data could impact external systems</li></ul>|
141
-
246
+
<tableborder="1"cellpadding="5"cellspacing="0">
247
+
<thead>
248
+
<tr>
249
+
<th>Snapshot scope</th>
250
+
<th>Benefits</th>
251
+
<th>Drawbacks</th>
252
+
</tr>
253
+
</thead>
254
+
<tbody>
255
+
<tr>
256
+
<td>OS only</td>
257
+
<td>
258
+
<ul>
259
+
<li>Simplifies storage requirements</li>
260
+
<li>Preserves isolation of OS changes from apps and app data</li>
261
+
<li>Reduces risk of rolling back impacting external apps</li>
262
+
</ul>
263
+
</td>
264
+
<td>
265
+
<ul>
266
+
<li>Probably not possible with VMware snapshots</li>
267
+
<li>Discipline required to avoid temptation of trying quick app changes to fix impacts</li>
268
+
</ul>
269
+
</td>
270
+
</tr>
271
+
<tr>
272
+
<td>OS and apps/data</td>
273
+
<td>
274
+
<ul>
275
+
<li>Reduces risk if trying to fix app impact during maintenance window</li>
276
+
<li>Helpful if app impact could lead to app data corruption</li>
277
+
</ul>
278
+
</td>
279
+
<td>
280
+
<ul>
281
+
<li>More storage space required</li>
282
+
<li>Rolling back app data could impact external systems</li>
283
+
</ul>
284
+
</td>
285
+
</tr>
286
+
</tbody>
287
+
</table>
142
288
When snapshots only include the upgraded OS volumes, the best practice of isolating OS changes from app changes is followed. In this case, it is important to resist the temptation to make some heroic app changes in an attempt to avoid rolling back in the face of application impact after a RHEL upgrade. For the sake of safety and soundness, gather the evidence required to help understand what caused any app impact, but then do a rollback. Don't make any app changes that could be difficult to untangle after rolling back the OS.
143
289
144
290
Unfortunately, a VMware snapshot saves the full state of a VM instance including all virtual disks irrespective of whether they contain OS or app data. This can prove challenging for a couple reasons. First, more storage space will be required for the snapshots and it is more difficult to anticipate how much snapshot growth will result because of app data activity. The other problem is that rolling back app data may result in the app state becoming out of sync with external systems leading to unpredictable issues. When rolling back app data for any reason, be aware of the potential headaches that may result.
0 commit comments