vSphere 5 存储空间回收

vSphere5.x存储空间回收--用DELLEQL为例子近日，公司内部很多案子都讨论到空间回收这个话题起因，是客户在EQL（其他存储也一样）的管理界面看到的可用空间和vmware内部看到的不一致原因，EQL是block（块）级别的存储，它不是一个文件系统；当一个文件被删除了，ESXi没有告诉底层把这文件占用的块清除掉；这个新的（相对于esxi4）名词叫-unmap|』在esxi5.x已经开始支持用一个工具手工的回收这些空间。所以在esxi看到的空间和存储上显示的不同。一般情况下，esxi看到的可用空间是比存储上看到的可用空间要大解决办法或者说工具在帖子后面ARRAY:GUIspaceusagediffersfromwhattheOSshowsQ:WhyisthereadiffereneebetweenwhatmyfilesystemshowsasspaceusedandwhatthePSarrayGUIshowsforin-useforthevolume?A:ThePSarrayisblock-storage,andonlyknowsaboutareasofavolumethathaveeverbeenwritten.ThePSSeriesGUIreportsthisinformationforeachvolume.Volumeallocationgrowsautomaticallyduetoapplicationdatawrites.Iflatertheapplicationfreesupspace,thespaceisnotmarkedasunusedinthePSSeriesGUI.HencethediffereneeinviewsbetweentheOS/filesystemandthePSSeriesGUI.Withthinprovisionedvolumes,thisperceptioncanbemorepronounced.Thinprovisioningisastoragevirtualizationandprovisioningmodelthatallowsadministratorstologicallyallocatelargeaddressablestoragespacetoavolume,yetnotphysicallycommitstorageresourcestothisspaceuntilitisusedbyanapplication.Forexample,usingthinprovisioningyoucancreateavolumethatanapplicationviewsas3TB,whileonlyallocatting300GBofphysicalstoragetoit.Astheoperatingsystemwritestothevolume,physicaldiskspaceisallocatedtothevolumebythestoragearray.Thisphysicaldiskspaceistakenfromtheavailablefreespaceinthepoolautomaticallyandtransparently.Asaresult,lessphysicalstorageisneededovertime,andthestrandedstorageproblemiseliminated.Theadministratorenjoysmanagementbenefitssimilartoover-provisioning,yetmaintainstheoperationalefficienciesofimprovedphysicalstorageutilization.Thismoreefficientuseofphysicalstorageresourcestypicallyallowsanorganizationtodeferorreducestoragepurchases.Thinprovisioningisaforwardplanningtoolforstorageallocationinwhichallthestorageanapplicationwillneedisallocatedupfront,eliminatingthetraumaofexpandingavailablestorageinsystemsthatdonotsupportonlineexpansion.Becausetheadministratorinitiallyprovisionstheapplicationwithallthestorageitwillneed,repeateddatagrowthoperationsareavoided.Mostimportant,becauseofthediffereneebetweenrealityandperception,anyoneinvolvedwiththinprovisionedstoragemustbeawareofthedualityinplay.Ifallplayersarenotvigilantsomeonecouldstartdrawingontheun-provisionedstorage一exceedingcapacity,disruptingoperations,orrequiringadditionalunplannedcapitalinvestments.Athin-provisionedvolumealsogrowsautomaticallyduetoapplicationdatawrites一thespaceisdrawnfromthepoolfreespace(ratherthanhavingbeenpre-allocatedinanormalvolume).Iflatertheapplicationfreesupspace,thespaceisfreeinthefilesystembutisnotreturnedtothefreespaceinthePSSeriespool.TheonlywaytoreducethephysicalallocationintheSANistocreateanewvolume,copytheapplicationdatafromtheoldvolumetothenew,andthendeletetheoldvolume.AsimilarproblemiswhentheinitiatorOSreportssignificantlymorespaceinusethanthearraydoes.ThiscanbepronouncedinsystemslikeVMWarethatcreatelarge,sparsefiles.InVMWare,ifyoucreateyourselfa10GBdiskforaVMasaVMDKfile,VMWaredoesnotwrite10GBofzerostothefile.Itcreatesanempty(sparse)10GBfile,andsubtracts10GBfromfreespace.TheactofcreatingtheemptyfileonlytouchesafewMBofactualsectorsonthedisk.SoVMWaresays10GBmissing,butthearraysays,perhaps,only2MBwrittento.neetheminimumvolumereserveforanyvolumeis10%,thefilesystemhasalongwaytogobeforetheMB-scalewritescatchupwiththeminimumreservationofavolume.Forinstanee,acustomerwitha100GBvolumemightcreate5VMswith10GBdisks.That's50GBusedaccordingtoVMWare,butonlyperhaps5x2MB(10MB)writtentothearray.UntilthecustomerstartsfillingtheVMDKfileswithactualdata,thearraywon'tknowanythingisthere.IfhasnoideawhatVMFSis;itonlyknowswhat'sbeenwrittentothevolume.Example:Afileshareisthin-provisionedwith1TBlogicalsize.Dataisplacedintothevolumesothatthephysicalallocationgrowsto500GB.Filesaredeletedfromthefilesystem,reducingthereportedfilesysteminuseto100GB.Theremaining400GBofphysicalstorageremainsallocatedtothisvolumeintheSAN.Thisissuecanalsooccurwithmaintenanceoperationsincludingdefragmentation,databasere-organization,andotherapplicationoperations.Inmostenvironments,filesystemsdonotdramaticallyreduceinsize,sothisissueoccursinfrequently.Alsosomefilesystemswillnotmakeefficientre-useofpreviouslyallocatedspace,andmaynotreusedeletedspaceuntilitrunsoutofunusedspace(thisisnotanissueforNTFS,VMFS).Arelatedquestionishowcanthispreviouslyused,butnownot-in-usespacebereclaimedintheSAN?Todaythiswouldrequirethecreationofanewvolumeandcopyingthevolumedatafromoldtonew.Thislikelywouldrequiretheapplication/usersthatusethefilesystemtobeoffline(aplannedmaintenancewindow).Inthefuture,filesystemssuchasNTFSinWindowsServer2008willallowonlineshrinkinadditiontotheexistingonlinegrowoperations.Theresultwiththisprocedurewouldbetheabilitytoreclaimfreespacewouldbedoneonline(perhapsduringnon-peaktimes),wherethefilesystemisshrunkonline,thenre-grownonlinetoitsoriginalsize.Thiswouldreclaimthevolumespace,howevertheremaybeadelayingainingthefreespacebacktothepoolfreespaceifsnapshotsarepresent,astheywouldholdthereleasedspaceuntilthesnapshotsage(andareautomaticallydeleted).InsomecasestheamountofspaceusedonthearraywillshowLESSthanwhatisshownbytheOS.Forexample,VMwareESX.WhenESX3.xcreatesa20GBVMDK,itdoesn'tactuallywrite20GBofdatatothevolume.Asmallfileiscreated,thenESXtellsthefileallocationtablethat20GBhasbeenallocated.Overtimeasdataisactuallywrittenanddeleted,thiswillswingbacktheotherway.WhereESXsaysthere'slessspaceallocatedthanwhatthearrayGUIindicates.先看机器翻译的:数组：GUI空间使用不同于操作系统的显示解决方案详细信息问：为何会有我的文件系统空间使用的显示和PS阵列GUI使用的卷中的显示之间的区别?答：PS阵列是数据块的存储，并只知道以往任何时候都已写入卷的领域°PS系列GUI报告此为每个卷的信息。卷分配自动增长，由于应用程序的数据写操作。如果稍后应用程序来释放空间，空间未标记为未使用PS系列GUI中。因此差异视图之间的OS/文件系统和PS系列GUI。与薄资源调配的卷，这种看法可以会更明显。精简资源调配是存储虚拟化和资源调配的模型，它允许管理员以逻辑上分配到一个卷，大的可寻址存储空间但又没有物理地存储资源提交到此空间直到应用程序使用它。例如，使用精简资源调配您可以创建一个应用程序视为3TB,同时只分配给它的物理存储300GB的卷。作为操作系统写入该卷，物理磁盘空间存储阵列由分配给卷。自动、透明地，此物理磁盘空间是采取从池中的可用空间。其结果是，少的物理存储需要随着时间的推移和孤立的存储问题中被淘汰。管理员享有类似于过度配置的情况，管理的好处，却保持运营效率的提高物理存储利用率。此更有效地使用物理存储资源通常使组织能够推迟或减少存储购买。所以精简资源调配是远期规划工具，存储分配的应用程序将需要的所有存储都分配提前付款,消除扩大可用存储系统不支持在线扩展中的创伤。因为管理员最初规定用它将需要的所有存储的应用程序，可避免重复的数据增长业务。最重要的是，因为现实和感知，之间的区别涉及精简调配的存储与任何人必须意识到剧中的对偶。如果所有的角色都不警惕有人能启动绘图上的un-provisioned存储 超过能力、中断操作，或要求更多计划外的资本投资。精简资源调配的卷还自动增长由于应用程序的数据写操作——空间从池中的可用空间（而具有正常卷中已预分配）绘制。如果稍后应用程序来释放空间，在文件系统中是自由的空间，但不是会返回到池中的PS系列的可用空间。减少物理分配SAN中的唯一方法是创建新的卷将应用程序数据从旧的卷复制到一个新的然后删除旧的卷。类似的问题时，启动器OS报告中使用数组不会超过相当多的空间。这可以明显像VMWare创建大型、稀疏文件的系统中。在VMWare,如果您自己创建一个10GB的磁盘为VM为VMDK文件，VMWare不写入10GB的文件到零。它创建一个空的（稀疏）10GB文件，并减去10GB的可用空间。创建空文件的行为只涉及到几MB的磁盘上的实际部门。VMWare也这样说失踪10GB,但数组说，也许，只有2MB的写入。由于任何卷的最小体积储备金是10%,文件系统有很长的路要走之前MB规模写入赶上最低保留的卷。例如，客户提供100GB的卷可能具有10GB磁盘创建5Vm。这就是使用VMWare，但或许只有5x2MB（10MB）写入阵列50GB。直到客户开始用实际数据填充VMDK文件，该数组不知道任何东西都是有。如果根本不知道什么是VMFS；它只知道什么已写入该卷。•示例：文件共享是精简资源调配1TB逻辑大小。因此，物理分配增长到500GB数据放入卷。从文件系统中，减少到100GB的报告的文件系统使用中删除文件。其余400GB的物理存储仍然分配给该卷在SAN中。与维护操作包括碎片整理、数据库重组和其他应用程序的操作也会出现此问题。在大多数环境中，文件系统不急剧减少的大小，所以这一问题很少发生。此外有些文件系统不会使先前分配的空间，有效地重复使用和可不重新使用已删除的空间，直到用完未使用的空间（这不是NTFS,VMFS的一个问题）。一个相关的问题是如何可以这个以前用过，但现在不在使用的空间回收在SAN中吗？今天这将需要新的卷，并从旧的卷的数据复制到新的创作。这可能需要使用文件系统