猀愀洀攀 䌀䰀 愀渀搀 琀漀漀氀猀Ⰰ 愀渀搀 洀攀琀栀漀搀漀氀漀最礀⸀㰀⼀氀椀㸀ഀഀ
㰀⼀甀氀㸀ഀഀ
䘀椀最⸀ ⸀ 匀䄀一㨀 嘀攀爀礀 猀椀洀瀀氀椀昀椀攀搀 瘀椀攀眀 漀渀 挀漀渀渀攀挀琀椀漀渀 漀昀 琀栀攀 一攀琀䄀瀀瀀 䘀椀氀攀爀 ⠀挀漀渀琀爀漀氀氀攀爀⤀ 琀漀 搀椀猀欀猀栀攀氀瘀攀猀⸀㰀戀爀㸀ഀഀ
㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㠀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
㰀戀爀㸀ഀഀ In the "sketch" above, we see a simplified model of a NetApp SAN.
䠀攀爀攀Ⰰ 琀栀攀 猀漀挀愀氀氀攀搀 ∀䘀椀氀攀爀∀Ⰰ 漀爀 琀栀攀 ∀挀漀渀琀爀漀氀氀攀爀∀ ⠀漀爀 ∀䘀䄀匀∀⤀Ⰰ 椀猀 挀漀渀渀攀挀琀攀搀 琀漀 琀眀漀 搀椀猀欀 猀栀攀氀瘀攀猀 ⠀搀椀猀欀 愀爀爀愀礀猀⤀⸀㰀戀爀㸀ഀഀ Most SANs, like NetApp, supports FCP disks, SAS disks, and (slower) SATA disks.
匀椀渀挀攀 焀甀椀琀攀 猀漀洀攀 琀椀洀攀Ⰰ 一攀琀䄀瀀瀀 昀愀瘀漀甀爀攀猀 琀漀 瀀甀琀 匀䄀匀 搀椀猀欀猀 椀渀 琀栀攀椀爀 猀栀攀氀瘀攀猀⸀㰀戀爀㸀ഀഀ
䤀昀 琀栀攀 匀琀漀爀愀最攀 䄀搀洀椀渀 眀愀渀琀猀Ⰰ 栀攀 漀爀 猀栀攀 挀愀渀 挀漀渀昀椀最甀爀攀 琀栀攀 猀礀猀琀攀洀 琀漀 愀挀琀 愀猀 愀 匀䄀一 愀渀搀⼀漀爀 愀猀 愀 一䄀匀Ⰰ 猀漀 琀栀愀琀 椀琀 挀愀渀 瀀爀漀瘀椀搀攀 猀琀漀爀愀最攀 甀猀椀渀最 攀椀琀栀攀爀㰀戀爀㸀ഀഀ file-based or block-based protocols.
㰀戀爀㸀ഀഀ The picture above is extremely simple. Often, two Filers are arrangend in a clustered solution, with multiple paths
琀漀 洀甀氀琀椀瀀氀攀 搀椀猀欀猀栀攀氀瘀攀猀⸀ 吀栀椀猀 眀漀甀氀搀 琀栀攀渀 戀攀 愀 䠀䄀 猀漀氀甀琀椀漀渀 甀猀椀渀最 愀 ∀䘀愀椀氀漀瘀攀爀∀ 琀攀挀栀渀漀氀漀最礀⸀ 㰀戀爀㸀ഀഀ So, suppose "netapp1" and "netapp2" are two Filers, each controlling their own shelves. Then if netapp1 would fail for some reason,
琀栀攀 漀眀渀攀爀猀栀椀瀀 漀昀 椀琀猀 猀栀攀氀瘀攀猀 眀漀甀氀搀 最漀 琀漀 琀栀攀 渀攀琀愀瀀瀀㈀ 昀椀氀攀爀⸀㰀戀爀㸀ഀഀ
㰀戀爀㸀ഀഀ ഀഀ
1.2 A conceptual view on NetApp Storage.
ഀഀ ഀഀ Note from figure 1, that if a shelve is on port "0a", the Ontap software identifies individual disks by the portnumber and the disk's SCSI ID, 氀椀欀攀 昀漀爀 攀砀愀洀瀀氀攀 ∀ 愀⸀ ∀Ⰰ ∀ 愀⸀∀Ⰰ ∀ 愀⸀㈀∀ 攀琀挀⸀⸀㰀戀爀㸀ഀഀഀഀ
吀栀椀猀 猀漀爀琀 漀昀 椀搀攀渀琀椀昀椀攀爀猀 愀爀攀 甀猀攀搀 椀渀 洀愀渀礀 伀渀琀愀瀀 瀀爀漀洀瀀琀 ⠀䌀䰀⤀ 挀漀洀洀愀渀搀猀⸀㰀戀爀㸀ഀഀ
䈀甀琀 昀椀爀猀琀 椀琀✀猀 瘀攀爀礀 椀洀瀀漀爀琀愀渀琀 琀漀 最攀琀 愀 渀漀琀椀漀渀 漀渀 栀漀眀 一攀琀䄀瀀瀀 漀爀最愀渀椀稀攀猀 椀琀✀猀 猀琀漀爀愀最攀⸀ 䠀攀爀攀 眀攀 眀椀氀氀 猀栀漀眀 愀 瘀攀爀礀 栀椀最栀ⴀ氀攀瘀攀氀㰀戀爀㸀ഀഀ conceptual model.
㰀戀爀㸀ഀഀ Fig. 2. NetApp's organization of Storage.
㰀戀爀㸀ഀഀ
㰀戀爀㸀ഀഀ
吀栀攀 洀漀猀琀 昀甀渀搀愀洀攀渀琀愀氀 氀攀瘀攀氀 椀猀 琀栀攀 㰀䈀㸀∀刀愀椀搀 䜀爀漀甀瀀∀ ⠀刀䜀⤀㰀⼀䈀㸀⸀ 一攀琀䄀瀀瀀 甀猀攀猀 ∀刀䄀䤀䐀㐀∀Ⰰ 漀爀 ∀刀䄀䤀䐀㘀 眀椀琀栀 搀漀甀戀氀攀 瀀愀爀椀琀礀 ⠀䐀倀⤀∀ 漀渀 琀眀漀 搀椀猀欀猀Ⰰ㰀戀爀㸀ഀഀ which is the most robust option ofcourse. It's possible to have one or more Raid Groups.
㰀戀爀㸀ഀഀ An "Aggregate" is a logical entity, composed of one or more Raid Groups.
伀渀挀攀 挀爀攀愀琀攀搀Ⰰ 椀琀 昀甀渀搀愀洀攀渀琀愀氀氀礀 爀攀瀀爀攀猀攀渀琀猀 㰀䤀㸀琀栀攀㰀⼀䤀㸀 猀琀漀爀愀最攀 甀渀椀琀⸀㰀戀爀㸀ഀഀ
䤀昀 礀漀甀 眀愀渀琀Ⰰ 礀漀甀 洀椀最栀琀 猀愀礀 琀栀愀琀 愀渀 愀最最爀攀最愀琀攀 ∀猀漀爀琀 漀昀∀ 瘀椀爀琀甀愀氀椀稀攀猀 琀栀攀 爀攀愀氀 瀀栀礀猀椀挀愀氀 椀洀瀀氀攀洀攀渀琀愀琀椀漀渀 漀昀 刀䜀✀猀㰀戀爀㸀ഀഀ
伀渀琀愀瀀 眀椀氀氀 挀爀攀愀琀攀 刀䜀 最爀漀甀瀀猀 昀漀爀 礀漀甀 ∀戀攀栀椀渀搀 琀栀攀 猀挀攀渀攀∀ 眀栀攀渀 礀漀甀 挀爀攀愀琀攀 愀渀 愀最最爀攀最愀琀攀⸀ 䤀琀 甀猀攀猀 挀攀爀琀愀椀渀 爀甀氀攀猀 昀漀爀 琀栀椀猀Ⰰ㰀戀爀㸀ഀഀ depending on disk type, disk capacities and the number of disks choosen for the aggregate. So, you could end up with one or more RG's
眀栀攀渀 挀爀攀愀琀椀渀最 愀 挀攀爀琀愀椀渀 愀最最爀攀最愀琀攀⸀㰀戀爀㸀ഀഀ
䄀猀 愀渀 攀砀愀洀瀀氀攀Ⰰ 昀漀爀 愀 挀攀爀琀愀椀渀 搀攀昀愀甀氀琀 猀攀琀甀瀀㨀㰀戀爀㸀 ഀഀ
ⴀ 椀昀 礀漀甀 眀漀甀氀搀 挀爀攀愀琀攀 愀 㘀 搀椀猀欀 愀最最爀攀最愀琀攀Ⰰ 礀漀甀 眀漀甀氀搀 攀渀搀 甀瀀 眀椀琀栀 漀渀攀 刀䜀⸀㰀戀爀㸀 ഀഀ - if you would create a 32 disk aggregate, you would end up with two RG's.
㰀戀爀㸀ഀഀ It's quite an art to get the arithmetic right. How large do you create an aggregate initially? What happens if additional spindles
戀攀挀漀洀攀 愀瘀愀椀氀愀戀氀攀 氀愀琀攀爀㼀 䌀愀渀 礀漀甀 琀栀攀渀 猀琀椀氀氀 攀砀瀀愀渀搀 琀栀攀 愀最最爀攀最愀琀攀㼀 圀栀愀琀 椀猀 琀栀攀 爀愀琀椀漀 漀昀 甀猀愀戀氀攀 猀瀀愀挀攀 挀漀洀瀀愀爀攀搀 琀漀 眀栀愀琀 最攀琀猀 爀攀猀攀爀瘀攀搀㼀㰀戀爀㸀ഀഀ
夀漀甀 猀攀攀㼀 圀栀攀渀 愀爀挀栀椀琀攀挀琀椀渀最 琀栀攀猀攀 猀琀爀甀挀琀甀爀攀猀Ⰰ 礀漀甀 渀攀攀搀 愀 氀漀琀 漀昀 搀攀琀愀椀氀攀搀 欀渀漀眀氀攀搀最攀 愀渀搀 搀漀 愀 氀愀爀最攀 愀洀漀甀渀琀 漀昀 瀀氀愀渀渀椀渀最⸀㰀戀爀㸀ഀഀ
䄀 㰀䈀㸀䘀氀攀砀嘀漀氀㰀⼀䈀㸀 椀猀 渀攀砀琀 氀攀瘀攀氀 漀昀 猀琀漀爀愀最攀Ⰰ ∀挀愀爀瘀攀搀 漀甀琀∀ 昀爀漀洀 琀栀攀 愀最最爀攀最愀琀攀⸀ 吀栀攀 䘀氀攀砀嘀漀氀 昀漀爀洀猀 琀栀攀 戀愀猀椀猀 昀漀爀 ∀爀攀愀氀∀ 甀猀愀戀氀攀 猀琀甀昀昀Ⰰ 氀椀欀攀㰀戀爀㸀ഀഀ LUNs (for FC or iSCSI), or CIFS/NFS shares.
㰀戀爀㸀ഀഀ From a FlexVol, CIFS/NFS shares or LUNs are created.
㰀戀爀㸀ഀഀ A LUN is a logical representation of storage. As we have seen before, it "just looks" like a hard disk to the client.
䘀爀漀洀 愀 一攀琀䄀瀀瀀 瀀攀爀猀瀀攀挀琀椀瘀攀Ⰰ 椀琀 氀漀漀欀猀 氀椀欀攀 愀 昀椀氀攀 椀渀猀椀搀攀 愀 瘀漀氀甀洀攀⸀㰀戀爀㸀ഀഀ The true physical implementation of a LUN on the aggregate, is that it is a "stripe" over N physical disks in RAID DP.
㰀戀爀㸀ഀഀ Why would you choose CIFS/NFS or (FC/iSCSI) LUNs? Depends on the application. If you need a large share, then the answer is obvious.
䄀氀猀漀Ⰰ 猀漀洀攀 䠀漀猀琀猀 爀攀愀氀氀礀 渀攀攀搀 猀琀漀爀愀最攀 琀栀愀琀 愀挀琀猀 氀椀欀攀 愀 氀漀挀愀氀 搀椀猀欀Ⰰ 愀渀搀 眀栀攀爀攀 匀䌀匀䤀 㰀䈀㸀爀攀猀攀爀瘀愀琀椀漀渀猀㰀⼀䈀㸀 挀愀渀 戀攀 瀀氀愀挀攀搀 漀渀 ⠀愀猀 椀渀 挀氀甀猀琀攀爀椀渀最⤀⸀㰀戀爀㸀ഀഀ In this case, you obviously need to create a LUN.
㰀戀爀㸀ഀഀ Since, using NetApp tools, LUNs are sometimes represented (or showed) as "files", the entity "qtree" gets meaning too.
䤀琀✀猀 愀渀愀氀漀最漀甀猀 琀漀 愀 昀漀氀搀攀爀⼀猀甀戀搀椀爀攀挀琀漀爀礀⸀ 匀漀Ⰰ 椀琀✀猀 瀀漀猀猀椀戀氀攀 琀漀 ∀愀猀猀漀挀椀愀琀攀∀ 䰀唀一猀 眀椀琀栀 愀 焀琀爀攀攀⸀㰀戀爀㸀ഀഀ Since it have the properties that a folder has too, you can associate NTFS or Unix-like permissions to all
漀戀樀攀挀琀猀 愀猀猀漀挀椀愀琀攀搀 琀漀 琀栀愀琀 焀琀爀攀攀⸀㰀戀爀㸀ഀഀ
㰀戀爀㸀ഀഀ ഀഀ
1.3 A note on tools.
ഀഀ ഀഀ There are a few very important GUI or Webbased tools for a Storage Admin, for configuring and monitoring their Filers and Storage.伀渀挀攀 ∀䘀椀氀攀爀嘀椀攀眀∀ ⠀搀攀瀀爀攀挀椀愀琀攀搀 漀渀 伀渀琀愀瀀 㠀⤀ 眀愀猀 最爀攀愀琀Ⰰ 愀渀搀 昀漀氀氀漀眀甀瀀 瘀攀爀猀椀漀渀猀 氀椀欀攀 ∀伀渀䌀漀洀洀愀渀搀 匀礀猀琀攀洀 䴀愀渀愀最攀爀∀ 愀爀攀 瀀爀漀戀愀戀氀礀 椀渀搀椀猀瀀攀渀猀愀戀氀攀 琀漀漀⸀㰀戀爀㸀ഀഀ
吀栀攀猀攀 琀礀瀀攀 漀昀 䜀唀䤀 琀漀漀氀猀 愀氀氀漀眀 昀漀爀 洀漀渀椀琀漀爀椀渀最Ⰰ 愀渀搀 挀爀攀愀琀椀渀最⼀洀漀搀椀昀礀椀渀最 愀氀氀 攀渀琀椀琀椀攀猀 愀猀 搀椀猀挀甀猀猀攀搀 椀渀 猀攀挀琀椀漀渀 ⸀㈀⸀㰀戀爀㸀ഀഀ
䤀琀✀猀 愀氀猀漀 瀀漀猀猀椀戀氀攀 琀漀 猀攀琀甀瀀 愀 ∀猀猀栀∀ 猀攀猀猀椀漀渀 琀栀爀漀甀最栀 愀 渀攀琀眀漀爀欀 琀漀 琀栀攀 䘀椀氀攀爀Ⰰ 愀渀搀 椀琀 愀氀猀漀 栀愀猀 愀 猀攀爀椀愀氀 ∀挀漀渀猀漀氀攀∀ 瀀漀爀琀 昀漀爀 搀椀爀攀挀琀 挀漀洀洀甀渀椀挀愀琀椀漀渀⸀㰀戀爀㸀ഀഀ
㰀戀爀㸀ഀഀ There is a very strong "command line" (CL) available too, which has a respectable "learning curve".
㰀戀爀㸀ഀഀ Even if you have a very strong background in IT, nothing in handling a SAN of a specific Vendor is "easy".
匀椀渀挀攀Ⰰ 椀昀 愀 匀䄀一 椀猀 椀渀 昀甀氀氀 瀀爀漀搀甀挀琀椀漀渀Ⰰ 愀氀洀漀猀琀 㰀䈀㸀愀氀氀 瘀椀琀愀氀 搀愀琀愀㰀⼀䈀㸀 漀昀 礀漀甀爀 伀爀最愀渀椀稀愀琀椀漀渀 椀猀 挀攀渀琀攀爀攀搀 漀渀 琀栀攀 匀䄀一Ⰰ 礀漀甀 挀愀渀渀漀琀 愀昀昀漀爀搀 愀渀礀 洀椀猀琀愀欀攀猀⸀㰀戀爀㸀ഀഀ To be carefull and not taking any risks, is a good quality.
㰀戀爀㸀ഀഀ There are hundreds of commands. Some are "pure" unix shell-like, like "df" and many others. But most are specific to Ontap like "aggr create"
愀渀搀 洀愀渀礀 漀琀栀攀爀猀 琀漀 挀爀攀愀琀攀 愀渀搀 洀漀搀椀昀礀 琀栀攀 攀渀琀椀琀椀攀猀 愀猀 搀椀猀挀甀猀猀攀搀 椀渀 猀攀挀琀椀漀渀 ⸀㈀⸀㰀戀爀㸀ഀഀ
䤀昀 礀漀甀 眀愀渀琀 琀漀 戀攀 ∀椀洀瀀爀攀猀猀攀搀∀Ⰰ 栀攀爀攀 愀爀攀 猀漀洀攀 氀椀渀欀猀 琀漀 ∀伀渀琀愀瀀 䌀䰀∀ 爀攀昀攀爀攀渀挀攀猀㨀㰀戀爀㸀ഀഀ
㰀愀 栀爀攀昀㴀∀栀琀琀瀀㨀⼀⼀猀甀瀀瀀漀爀琀⸀渀攀琀愀瀀瀀⸀挀漀洀⼀一伀圀⼀瀀甀戀氀椀挀⼀欀渀漀眀氀攀搀最攀⼀搀漀挀猀⼀漀渀琀愀瀀⼀爀攀氀㜀㌀㈀⼀瀀搀昀猀⼀漀渀琀愀瀀⼀㈀ ⴀ 㐀㐀㤀㤀⸀瀀搀昀∀㸀伀渀琀愀瀀 㜀⸀砀 洀漀搀攀 䌀䰀 刀攀昀攀爀攀渀挀攀㰀⼀愀㸀㰀戀爀㸀ഀഀ Ontap 8.x mode CL Reference
㰀戀爀㸀ഀഀ
㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀爀攀搀∀㸀ഀഀ 㰀栀㌀㸀⸀㐀 䄀 渀漀琀攀 漀渀 匀一䄀倀匀䠀伀吀 䈀愀挀欀甀瀀 吀攀挀栀渀漀氀漀最礀⸀㰀⼀栀㌀㸀ഀഀ 㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ 伀渀攀 愀琀琀爀愀挀琀椀瘀攀 昀攀愀琀甀爀攀 漀昀 一攀琀䄀瀀瀀猀 猀琀漀爀愀最攀Ⰰ 椀猀 琀栀攀 爀愀渀最攀 漀昀 匀一䄀倀 琀攀挀栀渀漀氀漀最椀攀猀Ⰰ 氀椀欀攀 琀栀攀 甀猀愀最攀 漀昀 匀一䄀倀匀䠀伀吀 戀愀挀欀甀瀀猀⸀㰀戀爀㸀ഀഀ You can't talk about NetApp, and not dealing with this one.
㰀戀爀㸀ഀഀ From Raid Groups, an aggregate is created. From an aggregate, FlexVols are created. From a FlexVol, a NAS (share) might be created,
漀爀 䰀唀一猀 洀椀最栀琀 戀攀 挀爀攀愀琀攀搀 ⠀愀挀挀攀猀椀戀氀攀 瘀椀愀 䘀䌀倀⼀椀匀䌀匀䤀⤀⸀㰀戀爀㸀ഀഀ
一漀眀Ⰰ 眀攀 欀渀漀眀 琀栀愀琀 一攀琀䄀瀀瀀 甀猀攀猀 琀栀攀 圀䄀䘀䰀 ∀昀椀氀攀猀礀猀琀攀洀∀Ⰰ 愀渀搀 椀琀 栀愀猀 椀琀猀 漀眀渀 ∀漀瘀攀爀栀攀愀搀∀Ⰰ 眀栀椀挀栀 眀椀氀氀 搀椀洀椀渀椀猀栀 礀漀甀爀 琀漀琀愀氀 甀猀愀戀氀攀 猀瀀愀挀攀⸀㰀戀爀㸀ഀഀ This overhead is estimated to be about 10% per disk (not reclaimable). It's partly used for WAFL metadata.
㰀戀爀㸀ഀഀ Apart from "overhead", several additional "reservations"are in effect.
㰀戀爀㸀ഀഀ When an aggregate is created, per default "reserved space" is defined to hold optional future "snapshot" copies.
吀栀攀 匀琀漀爀愀最攀 䄀搀洀椀渀 栀愀猀 愀 挀攀爀琀愀椀渀 搀攀最爀攀攀 漀昀 昀爀攀攀搀漀洀 漀昀 琀栀攀 猀椀稀攀 漀昀 琀栀椀猀 爀攀猀攀爀瘀攀搀 猀瀀愀挀攀Ⰰ 戀甀琀 椀渀 最攀渀攀爀愀氀 椀琀 椀猀 愀搀瘀椀猀攀搀㰀戀爀㸀ഀഀ not to set it too low. As a guideline (and default), often a value of 5% is "postulated".
㰀戀爀㸀ഀഀ Next, it's possible to create a "snapshot reserve" for a FlexVol too.
䠀攀爀攀 琀栀攀 匀琀漀爀愀最攀 䄀搀洀椀渀 栀愀猀 愀 挀攀爀琀愀椀渀 搀攀最爀攀攀 漀昀 昀爀攀攀搀漀洀 愀猀 眀攀氀氀⸀ 一攀琀䄀瀀瀀 最攀渀攀爀愀氀氀礀 猀攀攀洀猀 琀漀 椀渀搀椀挀愀琀攀 琀栀愀琀 愀 猀渀愀瀀猀栀漀琀㰀戀爀㸀ഀഀ reserve of 20% should be applied. However, numbers seem to vary somewhat when reading various recommendations.
䠀漀眀攀瘀攀爀Ⰰ 琀栀攀爀攀 椀猀 愀 戀椀最 搀椀昀昀攀爀攀渀挀攀 椀渀 一䄀匀 愀渀搀 匀䄀一 䰀唀一 戀愀猀攀搀 嘀漀氀甀洀攀猀⸀㰀戀爀㸀ഀഀ
䠀攀爀攀 椀猀 愀渀 攀砀愀洀瀀氀攀 漀昀 洀愀渀椀瀀甀氀愀琀椀渀最 琀栀攀 爀攀猀攀爀瘀攀搀 猀瀀愀挀攀 漀渀 琀栀攀 瘀漀氀甀洀攀 氀攀瘀攀氀Ⰰ 猀攀琀琀椀渀最 椀琀 琀漀 㔀─Ⰰ 甀猀椀渀最 琀栀攀 伀渀琀愀瀀 䌀䰀㨀㰀戀爀㸀ഀഀ
㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀甀攀∀㸀ഀഀ FAS1> snap reserve vol10 15
㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
㰀戀爀㸀 ഀഀ Snapshot Technologies:
㰀戀爀㸀ഀഀ There are few different "Snapshot" technologies around.
㰀戀爀㸀ഀഀ One popular implementation uses the "Copy On Write" technology, which is fully block based or page based. NetApp does not use that.
䤀渀 昀愀挀琀Ⰰ 一攀琀䄀瀀瀀 甀猀攀猀 ∀愀 渀攀眀 戀氀漀挀欀 眀爀椀琀攀∀Ⰰ 漀渀 愀渀礀 挀栀愀渀最攀Ⰰ 愀渀搀 琀栀攀渀 猀漀爀琀 漀昀 挀氀攀瘀攀爀氀礀 ∀爀攀洀攀戀攀爀猀∀ 椀渀漀搀攀 瀀漀椀渀琀攀爀猀⸀㰀戀爀㸀ഀഀ
吀漀 甀渀搀攀爀猀琀愀渀搀 琀栀椀猀Ⰰ 氀攀琀猀 爀攀瘀椀攀眀 ∀䌀漀瀀礀 伀渀 圀爀椀琀攀∀ 昀椀爀猀琀Ⰰ 愀渀搀 琀栀攀渀 爀攀琀甀爀渀 琀漀 一攀琀䄀瀀瀀 匀渀愀瀀猀栀漀琀猀⸀㰀戀爀㸀ഀഀ
㰀䈀㸀☀⌀㠀㘀㔀㠀㬀 ∀䌀漀瀀礀 伀渀 圀爀椀琀攀∀ 匀渀愀瀀猀栀漀琀㨀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
䘀椀最⸀ ㌀⸀ ∀䌀漀瀀礀 漀渀 圀爀椀琀攀∀ 匀渀愀瀀猀栀漀琀 ⠀渀漀琀 甀猀攀搀 戀礀 一攀琀䄀瀀瀀⤀⸀㰀戀爀㸀ഀഀ
㰀椀洀最 猀爀挀㴀∀搀椀猀欀搀攀瘀椀挀攀猀㌀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀爀攀∀⼀㸀ഀഀ
㰀戀爀㸀ഀഀ Let's say we have a NAS volume, where a number of diskblocks are involved. "Copy on Write" is really easy to understand.
䨀甀猀琀 戀攀昀漀爀攀 㰀䤀㸀愀渀礀 戀氀漀挀欀㰀⼀䤀㸀 最攀琀猀 洀漀搀椀昀椀攀搀Ⰰ 琀栀攀 㰀䈀㸀漀爀椀最椀渀愀氀㰀⼀䈀㸀 戀氀漀挀欀 最攀琀猀 挀漀瀀椀攀搀 琀漀 愀 爀攀猀攀爀瘀攀搀 猀瀀愀挀攀 愀爀攀愀⸀㰀戀爀㸀ഀഀ You see? Only the "deltas", as of a certain t=t0 (when the snapshot was activated), of a Volume (or file, or whatever)
最攀琀猀 挀漀瀀椀攀搀⸀ 吀栀椀猀 椀猀 最爀攀愀琀Ⰰ 戀甀琀 椀琀 椀渀瘀漀氀瘀攀猀 洀甀氀琀瀀氀攀 ∀眀爀椀琀攀猀∀㨀 昀椀爀猀琀Ⰰ 眀爀椀琀攀 琀栀攀 漀爀椀最椀渀愀氀 戀氀漀挀欀 琀漀 愀 猀愀瘀攀 瀀氀愀挀攀Ⰰ 琀栀攀渀 眀爀椀琀攀 琀栀攀㰀戀爀㸀ഀഀ the block with the new data.
㰀戀爀㸀ഀഀ In effect, you have a backup of the entity (the Volume, the file, the "whatever") as it was at t=t0.
㰀戀爀㸀ഀഀ If, later on, at t=t1, you need to restore, or go back to t=t0, you need the primary block space, and copy the all reserved
⠀猀愀瘀攀搀⤀ 戀氀漀挀欀猀 ∀漀瘀攀爀∀ 琀栀攀 洀漀搀椀昀椀攀搀 戀氀漀挀欀猀⸀㰀戀爀㸀ഀഀ Note that the reserved space does NOT contain a full backup. It's only a collection of blocks freezed at t=t0, before they
眀攀爀攀 洀漀搀椀昀椀攀搀 戀攀琀眀攀攀渀 琀㴀琀㰀猀甀戀㸀㰀⼀猀甀戀㸀 ⴀ 琀㴀琀㰀猀甀戀㸀 㰀⼀猀甀戀㸀⸀㰀戀爀㸀ഀഀ Normally, the reserved space will contain much less blocks than the primary (usable, writable) space, which means a lot of saving
漀昀 搀椀猀欀猀瀀愀挀攀 挀漀洀瀀愀爀攀搀 琀漀 愀 琀爀愀搀椀琀椀漀渀愀氀 ∀昀甀氀氀∀ 挀漀瀀礀 漀昀 戀氀漀挀欀猀⸀㰀戀爀㸀ഀഀ
㰀䈀㸀☀⌀㠀㘀㔀㠀㬀 ∀一攀琀䄀瀀瀀∀ 匀渀愀瀀猀栀漀琀 挀漀瀀礀㨀 最攀渀攀爀愀氀 搀攀猀挀爀椀瀀琀椀漀渀 ⠀⤀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
夀漀甀 挀愀渀 猀挀栀攀搀甀氀攀 愀 匀渀愀瀀猀栀漀琀 戀愀挀欀甀瀀 漀昀 愀 嘀漀氀甀洀攀Ⰰ 漀爀 礀漀甀 挀愀渀 洀愀欀攀 漀渀攀 椀渀琀攀爀愀挀琀椀瘀攀氀礀 甀猀椀渀最 愀渀 伀渀琀愀瀀 挀漀洀洀愀渀搀 漀爀 䜀唀䤀 琀漀漀氀⸀㰀戀爀㸀ഀഀ So, a Netapp Snapshot backup is not an "ongoing process". You start it (or it is scheduled), then it runs until it is done.
㰀戀爀㸀ഀഀ The mechanics of a snapshot backup are pretty "unusual", but it sure is fast.
㰀戀爀㸀ഀഀ Fig. 4. NetApp Snapshot copy.
㰀戀爀㸀ഀഀ
㰀戀爀㸀ഀഀ
䤀琀✀猀 戀攀琀琀攀爀 琀漀 猀瀀攀愀欀 漀昀 愀 ∀匀渀愀瀀猀栀漀琀 挀漀瀀礀∀Ⰰ 琀栀愀渀 漀昀 愀 ∀匀渀愀瀀猀栀漀琀 戀愀挀欀甀瀀∀Ⰰ 戀甀琀 洀漀猀琀 漀昀 甀猀 搀漀 渀漀琀 挀愀爀攀 琀漀漀 洀甀挀栀 愀戀漀甀琀 琀栀愀琀⸀㰀戀爀㸀ഀഀ It's an exact state of the Volume as it was at t=t0, when it started.
㰀戀爀㸀ഀഀ 圀椀琀栀 愀 猀渀愀瀀猀栀漀琀 爀甀渀渀椀渀最Ⰰ 圀䄀䘀䰀 琀愀欀攀猀 愀 挀漀洀瀀氀攀琀攀氀礀 愀渀漀琀栀攀爀 愀瀀瀀爀漀愀挀栀 琀栀愀渀 洀愀渀礀 漀昀 甀猀 愀爀攀 甀猀攀搀 琀漀⸀ 䤀昀 愀渀 攀砀椀猀琀椀渀最 ∀戀氀漀挀欀∀ ⠀琀栀愀琀 愀氀爀攀愀搀礀 挀漀渀琀愀椀渀攀搀 搀愀琀愀⤀Ⰰ㰀戀爀㸀ഀഀ is going to be modified while the backup runs, WAFL just takes a new free block, and puts the modified block there.
吀栀攀 漀爀椀最椀渀愀氀 戀氀漀挀欀 猀琀愀礀猀 琀栀攀 猀愀洀攀Ⰰ 愀渀搀 琀栀攀 椀渀漀搀攀 ⠀瀀漀椀渀琀攀爀⤀ 琀漀 琀栀愀琀 戀氀漀挀欀 椀猀 瀀愀爀琀 漀昀 琀栀攀 匀渀愀瀀猀栀漀琀 ℀㰀戀爀㸀ഀഀ So, there is only one write (that to the new block). The inode (a pointer) of the original block is part of the Snapshot.
㰀戀爀㸀ഀഀ It explains why snapshots are so incredably fast.
㰀戀爀㸀ഀഀ ⇒ "NetApp" Snapshot copy: the open file problem (2)
㰀戀爀㸀ഀഀ From Ontap's perspective, there is no problem at all. However, many programs run on Hosts (Servers) and not on the Filer ofcourse.
匀漀Ⰰ 愀瀀瀀氀椀挀愀琀椀漀渀猀 氀椀欀攀 伀爀愀挀氀攀Ⰰ 匀儀䰀 匀攀爀瘀攀爀 攀琀挀⸀⸀ 栀愀瘀攀 愀 㰀䈀㸀挀漀洀瀀氀攀琀攀氀礀 搀椀昀昀攀爀攀渀琀 瀀攀爀猀瀀攀挀琀椀瘀攀㰀⼀䈀㸀⸀㰀戀爀㸀ഀഀ
吀栀攀 匀渀愀瀀猀栀漀琀 挀漀瀀礀 洀椀最栀琀 琀栀甀猀 戀攀 椀渀挀漀渀猀椀猀琀攀渀琀⸀ 吀栀椀猀 椀猀 渀漀琀 挀愀甀猀攀搀 戀礀 一攀琀愀瀀瀀⸀ 一攀琀愀瀀瀀 漀渀氀礀 瀀爀漀搀甀挀攀搀 愀 猀琀愀琀攀 椀洀愀最攀 漀昀 瀀漀椀渀琀攀爀猀 愀琀 琀㴀琀 ⸀㰀戀爀㸀ഀഀ And that is actually a good backup.
㰀戀爀㸀ഀഀ The potential problem is this: NetApp created the snapshot at t0, during the t0 to t=t1 interval.
䤀渀 琀栀愀琀 椀渀琀攀爀瘀愀氀Ⰰ 愀 搀愀琀愀戀愀猀攀 昀椀氀攀 椀猀 昀爀愀挀琀椀漀渀攀搀Ⰰ 洀攀愀渀椀渀最 琀栀愀琀 瀀爀漀挀攀猀猀攀猀 洀椀最栀琀 栀愀瘀攀 甀瀀搀愀琀攀搀 爀攀挀漀爀搀猀 椀渀 琀栀攀 搀愀琀愀戀愀猀攀昀椀氀攀猀⸀㰀戀爀㸀ഀഀ Typical of databases is, is that their own checkpoint system process flushes dirty blocks to disk, and update
昀椀氀攀栀攀愀搀攀爀猀 愀挀挀漀爀搀椀渀最氀礀 眀椀琀栀 愀 渀攀眀 ∀猀攀焀甀攀渀挀攀 渀甀洀戀攀爀∀⸀ 䤀昀 愀氀氀 昀椀氀攀猀 愀爀攀 椀渀 猀礀渀挀Ⰰ 琀栀攀 搀愀琀愀戀愀猀攀 攀渀最椀渀攀 挀漀渀猀椀搀攀爀猀 琀栀攀 搀愀琀愀戀愀猀攀㰀戀爀㸀ഀഀ as "consistent". If that's not done, the database is "inconsistent" (so the database engine thinks).
㰀戀爀㸀ഀഀ By the way, it's not databases alone that behave in that manner. Also all sorts of workflow, messaging, queuing programs etc..
猀栀漀眀 猀椀洀椀氀愀爀 戀攀栀愀瘀椀漀甀爀⸀㰀戀爀㸀ഀഀ
䄀氀琀栀漀甀最栀 琀栀攀 匀渀愀瀀猀栀漀琀 挀漀瀀礀 椀猀Ⰰ 昀爀漀洀 愀 昀椀氀攀猀礀猀琀攀洀 瘀椀攀眀Ⰰ 瀀攀爀昀攀挀琀氀礀 挀漀渀猀椀猀琀攀渀琀Ⰰ 匀攀爀瘀攀爀 瀀爀漀最爀愀洀猀 洀椀最栀琀 琀栀椀渀欀 搀椀昀昀攀爀攀渀琀氀礀⸀㰀戀爀㸀ഀഀ That thus poses a problem.
㰀戀爀㸀ഀഀ Netapp fixed that, by letting you install additional programs on any sort of Database Server.
吀栀攀猀攀 愀爀攀 ∀匀渀愀瀀䐀爀椀瘀攀∀ 愀渀搀 ∀匀渀愀瀀䴀愀渀愀最攀爀 昀漀爀 砀礀稀∀ ⠀氀椀欀攀 匀渀愀瀀䴀愀渀愀最攀爀 昀漀爀 匀儀䰀 匀攀爀瘀攀爀⤀⸀㰀戀爀㸀ഀഀ
䤀渀 攀昀昀攀挀琀Ⰰ 樀甀猀琀 戀攀昀漀爀攀 琀栀攀 匀渀愀瀀猀栀漀琀 猀琀愀爀琀猀Ⰰ 琀栀攀 匀渀愀瀀䴀愀渀愀最攀爀 愀猀欀猀 琀栀攀 䐀愀琀愀戀愀猀攀 琀漀 挀栀攀挀欀瀀漀椀渀琀 愀渀搀 琀漀 ∀猀栀甀琀 甀瀀∀ 昀漀爀 愀 猀栀漀爀琀 眀栀椀氀攀 ⠀昀爀攀攀稀攀 愀猀 椀琀 眀攀爀攀⤀⸀㰀戀爀㸀ഀഀ SnapDrive will do the same for any other open filesystem processes.
吀栀攀 爀攀猀甀氀琀 椀猀 最漀漀搀 挀漀渀猀椀猀琀攀渀琀 戀愀挀欀甀瀀猀 愀琀 愀氀氀 琀椀洀攀猀⸀㰀戀爀㸀ഀഀ
㰀戀爀㸀ഀഀ ഀഀ
㰀戀爀㸀ഀഀ
㰀⼀戀漀搀礀㸀ഀഀ