79 Posts
0
4434
Snapshot Doubts
Hello,
I want to enable the snapshot of a lun, but I have some doubts:
Q1 - Where are shanpshot stored? In the same volume of the LUN? Or in another area?
Q2 - The snapshot reserve (%) is the space provided for snapshot. Does this mean that if I want a 1TB LUN, do I need to create a larger LUN to accommodate this percentage? Does not this percentage interfere with the LUN's useful area space?
Q3 - How do I estimate the space required to create a snapshot? If I select to keep two snapshots, do I have to double the amount of space consumed and so on?
Q4 - What would these options be:
- Make writable snapshots?
- Set snapshot online?
- Make snapshot read-write?
Q5 - If I want to go back to snapshot, can I restore it to hot? Is there any procedure to run that I need to be aware of?
Q6 - When I restore the LUN, but before setting it to offline, it appeared another snapshot in the list. Why did this happen?
Thank you.
dwilliam62
1 Rookie
1 Rookie
•
1.5K Posts
1
December 20th, 2018 06:00
Hello,
Yes you can enable thin provisioning at any time w/o damage. The host is not aware of the change.
Re: KB. That article will help regardless of virus or malware scanner. Since ANY read invokes a small write. DBs tend to do a lot of reads. So the SQL engine is going to be doing those reads all the time.
Re: 64K NTFS cluster size. That is a long standing recommendation that applies across storage vendors. The 64K stripe size of the EQL array means that if you send less than 64K the read or write will be misaligned from the RAID stripe. On writes this means more steps to get the write done compared to one that aligns on the 64K boundary. Other storage vendors may use a different size.
Unfortunately, you can only set that when you format the volume. So you would have to create a new volume format it, then migrate your data.
However, if you are not expressing a large load on the array the difference won't be significant.
Regards,
Don
dwilliam62
1 Rookie
1 Rookie
•
1.5K Posts
1
December 21st, 2018 06:00
Hi,
Thin provisioning does not affect how fast you use space. That it up to the server itself, not the storage device. Thin provisioning helps you conserve space in the meantime.
Don
dwilliam62
1 Rookie
1 Rookie
•
1.5K Posts
1
December 19th, 2018 12:00
Hello,
Quite a list.
Hope that helps.
Regards,
Don
Sandro Silva Alves
79 Posts
0
December 19th, 2018 14:00
I would like to share a practical scenario to clarify the understanding.
I'll try to explain, but the translation may be confusing.
- A 10GB LUN in use with 5GB;
- Snapshot configured to use (50% = 5GB of Pool);
- I took a first snapshot, that means it will occupy (0GB) in the first one.
- At the next snapshot the amount of data modified will be filled using the (50%) defined in the snapshot policy. Example: (1GB).
- Occupation summary: (0GB + 1GB = 1GB)
- In the next snapshot will be occupied the amount of data modified based on the previous snapshot, ie more (1GB). Then it will be (1GB + 1GB = 2GB).
- Total Occupancy Summary: (2GB of the 5GB "50%" reserved). That's good, I'm within the reserve limit. And so on.
Does this mean that my reservation limit is always based on the size of the existing LUN?
If I have a 50GB LUN, but I want to have several snapshots and this sum will exceed 50GB of the original LUN, ie, it will exceed the (%) set. How can it be done? Or this is not possible.
dwilliam62
1 Rookie
1 Rookie
•
1.5K Posts
0
December 19th, 2018 16:00
Hello,
No. It does not work that way.
if you have 5GB of data and create a snapshot it's zero size. If you do NOT make any changes then the next snapshot is also ZERO. Because nothing has changed yet. It's still the same as the base volume.
So start over. You have 5GB of data and create snapshot. Snapshot is empty. You make a change now the snapshot is the amount of the change. Let's say 15MB. You take another snapshot, but there are no changes yet. So the 2nd snapshot is ZERO because it matches the first snapshot. You make a change again. Another 15MB, now the second snapshot is 15MB. Any data that snapshots have in common with each other or the base volume are not copied. Just the changes from the base volume and from each other. So the total used for all snapshots is 30MB.
Regards,
Don
Sandro Silva Alves
79 Posts
0
December 19th, 2018 18:00
You are beginning to understand better.
I have LUNs that undergo many changes. New information is written every second, but growth is small. This is a database.
After enabling the snapshot (this takes about 10 minutes before making this comment), I noticed that the reserved area is growing very fast and I believe it will end quickly throughout the day.
I set use 50%, that is, a 500GB LUN and is only using 300GB. The reserved area for the 50% was approximate 300GB.
What happens when this area goes over? Am I going to lose the snapshot done before?
If I increase the snapshot buffer to 100% and still keep growing what do I do?
Thank you.
dwilliam62
1 Rookie
1 Rookie
•
1.5K Posts
0
December 19th, 2018 20:00
Hello,
If you run out of snapshot reserve the oldest snapshots will be deleted to make space available for the new one.
One thing about most filesystems is that every READ also creates a WRITE. To update the last access time and date. Virus scanners and backup programs make this worse. I've included a KB article with more info on snapshots but also how to disable the last access time/date for Windows. This helps reduce the churn a little.
One thing you can do is enable thin-provisioning on that volume. So then the reserve is based on in-use space not total volume.
Also depending on the operating system and filesystem you can run reclaim against that volume to recover blocks that no longer have active data on them. First delete the snapshots before doing that.
Regards,
Don
Snapshots only occupy space when data is modified. The space occupied by a snapshot is the space on the original volume that has been modified since the snapshot. So the moment a snapshot is made it occupies very little space, since it's just a pointer to the original volume. As modifications to the original volume are made, snapshot space is used up by keeping a copy of the original data.
When a second snapshot is made, it is made relative to the first snapshot. Space is allocated to the second snapshot whenever the first snapshot is changed - the second snapshot contains a copy of the first snapshot's data before the change. A third snapshot is made relative to the second. For this reason, deleting a snapshot doesn't release all of its reserve space, since snapshot reserve can be a part of multiple snapshots, depending on when the data was modified.
For more information on snapshot reserve space refer to the EqualLogic article How snapshot reserve space is allocated and used.
Why is Snapshot/Replica space getting used up too quickly on a EqualLogic (EQL) Array
If snapshot reserve space is filling up faster than expected, or replication jobs are much larger expected, this is due to the volume being written to more than expected. There are a number of reasons why the file systems may be getting modified more than expected. The following list is representative rather than exhaustive (there are probably many more packages that make a quiet but significant changes to a volume).
Microsoft Exchange Server has an option called mailbox management that can rearrange the location of mailboxes on the volume, causing lots of unexpected modifications to a volume. It can be disabled in the SETUP Properties dialog.
Defragmenting a disk will essentially modify every block on the volume that has data on it. Any process that defragments in the background will cause the snapshot reserve to fill (and increase the size of replication jobs) at an alarming rate. This will also occur with some Logical Volume Managers (LVMs). However, defragmenting occasionally can actually shrink average snapshot size over time, at the cost of a spike in snapshot size at the time the defragmentation occurs. A single defragmentation job when snapshots seem too large can help you decide if a regular defragmentation regimen is appropriate.
On Window file servers, the system automatically updates the Last Access Time field of the directory entry for each file touched, which can prove to have a very relevant impact on snapshot and replication utilization. To disable Last Access Time handling on an NTFS file system, add the following key to the Registry on your server:
HKeyLocalMachine\SYSTEM\CurrentControlSet\Control\file system\NtfsDisableLastAccessUpdate
REG_DWORD
And set it to 1
A reboot of the host is required for the update to take effect. Snapshots and replications taken after the next reboot of that host may be noticeably smaller, and increased performance may be seen. For more information on this registry entry refer to the NtfsDisableLastAccessUpdate entry in the Windows Server 2003 Resource Kit Registry Reference.
Some virus scanners and backup programs modify the directory entries of every file they touch, usually setting the Last Access time for each file and/or the Archive Bit in the directory entries. Although these scans aren't modifying the files themselves, directories occupy disk space as well, and modifying them causes snapshot reserve to be used. Because directories are normally distributed randomly across the disk, any task that routinely accesses every file in a file system, and is not careful about how it does it, will use up a lot more snapshot reserve than might be expected.
For backup software, you should have the backup job not modify the Archive Bit, but instead use a database catalog or modification time to track file changes, if the software supports such an option.
One possible approach to minimizing the impact of directory scans like that is to rearrange the file system to put all the directories in the same area of the disk. Some defragmenting tools can do this, though you will need to specifically look for this feature. Windows defrag may not support this option. Remember that disk defragmentation can cause a spike in snapshot utilization because of the number of blocks it writes to as it moves data around. Directory defragmentation is not normally something that would need to be run often, but the operator will need to find a balance between the impact of the defragmentation itself, and the impact of the directory scan.
Sandro Silva Alves
79 Posts
0
December 20th, 2018 03:00
Can I enable thin-provisioning on these volumes with existing data without causing damage or performance loss?
On this server there is no antimalware protection, so this should not be the offender. That's why I'm looking to enable snapshot.
I read about that KB you indicated, it seems that it helped some people in other similar cases. In my case, these LUNs are attached directly to the SQL server, that is, the scenario indicated by Dell. He even mentions that LUNs must be created separately from S.O, which is my scenario. There are three database-only LUNs. There is nothing else on these LUNs.
During the research I found another interesting information that is the size of the blocks, since I usually create with the EQL standard. But the Dell statement is to create with 64K blocks for better performance of the S.O.
It is immediately set up for thin provisining as you suggested, as I do not need to do anything to the server.
If it does not help, I'll have to apply the KB, which I'm not sure will help a lot, since scenario I have no antimalware.
Sandro Silva Alves
79 Posts
0
December 20th, 2018 18:00
I set up to keep only one snapshot in the daily schedule.
But I had done a manual snapshot.
Should it have removed that previous and maintained only what was done during the scheduling?
dwilliam62
1 Rookie
1 Rookie
•
1.5K Posts
0
December 20th, 2018 22:00
Hello,
You can delete it, if you wish. It will eventually get deleted when snapshot reserve is used up.
It does no harm.
Don
Sandro Silva Alves
79 Posts
0
December 21st, 2018 03:00
I enabled the thin provisioned, but growth continues to accelerate.
I noticed that after enabling thi provisined, the buffer space narrowed and stayed small to maintain the growth. So instead of 50%, I had to put 100%.
I believe I will have to use KB to see if it will help.