Zaujimavy koncept behu systemov komplet iba v pamati.
Zdroj:
http://www.ntpro.nl/blog/archives/1664-RAMClouds-Scalable-High-Performance-Storage-Entirely-in-DRAM.html
nedeľa 19. decembra 2010
utorok 14. decembra 2010
Ako nakonfigurovat SRM - video
Video s postupom ako nakonfigurovat niektore s diskovych poli pre SRM.
Zdroj:
How to Configure VMware SRM with your Vendor's Storage Array
http://blogs.vmware.com/kb/2010/12/how-to-configure-vmware-srm-with-your-vendors-storage-array.html
Zdroj:
How to Configure VMware SRM with your Vendor's Storage Array
http://blogs.vmware.com/kb/2010/12/how-to-configure-vmware-srm-with-your-vendors-storage-array.html
piatok 10. decembra 2010
Thin-on-thin
Pouzivat thin VMDK disk na thin provisioningu na urovni diskoveho pola?
VMware hovori "You can..."
Tu je dalsi prispevok:
So… What’s right - thin provisioning at the VMware layer or the storage layer? The general answer is that is BOTH.
If your array supports thin provisioning, you’ll generally get more efficiency using the array-level thin provisioning in most operational models.
1. If you thick provision at the LUN or filesystem level, there will always be large amounts of unused space until you start to get it highly utilized - unless you start small and keep extending the datastore - which operationally is heavyweight, and general a PITA.
2. when you use thin provisioning techniques at the array level using NFS or VMFS and block storage you always benefit. In vSphere all the default virtual disk types - both Thin and Thick (with the exception of eagerzeroedthick) are “storage thin provisioning friendly” (since they don’t “pre-zero” the files). Deploying from templates and cloning VMs also use Thin and Thick (but not eagerzeroedthick as was the case in prior versions).
3. Thin provisioning also tends to be more efficient the larger the scale of the “thin pool” (i.e. the more oversubscribed objects) - and on an array, this construct (every vendor calls them something slightly different) tends to be broader than a single datastore - and therefore more efficiency factor tends to be higher.
Obviously if your array (or storage team) doesn’t support thin provisioning at the array level – go to town and use Thin at the VMware layer as much as possible.
What if your array DOES support Thin, and you are using it that way - is there a downside to “Thin on Thin”? Not really, and technically it can be the most efficient configuration – but only if you monitor usage. The only risk with “thin on thin” is that you can have an accelerated “out of space condition”.
Zdroj:
Prvy odstavec na strane 11 VMware dokumentu
Performance Study of VMware vStorage Thin Provisioning
www.vmware.com/pdf/vsp_4_thinprov_perf.pdf
Thin on Thin? Where should you do Thin Provisioning – vSphere 4.0 or Array-Level?
http://virtualgeek.typepad.com/virtual_geek/2009/04/thin-on-thin-where-should-you-do-thin-provisioning-vsphere-40-or-array-level.html
VMware hovori "You can..."
Tu je dalsi prispevok:
So… What’s right - thin provisioning at the VMware layer or the storage layer? The general answer is that is BOTH.
If your array supports thin provisioning, you’ll generally get more efficiency using the array-level thin provisioning in most operational models.
1. If you thick provision at the LUN or filesystem level, there will always be large amounts of unused space until you start to get it highly utilized - unless you start small and keep extending the datastore - which operationally is heavyweight, and general a PITA.
2. when you use thin provisioning techniques at the array level using NFS or VMFS and block storage you always benefit. In vSphere all the default virtual disk types - both Thin and Thick (with the exception of eagerzeroedthick) are “storage thin provisioning friendly” (since they don’t “pre-zero” the files). Deploying from templates and cloning VMs also use Thin and Thick (but not eagerzeroedthick as was the case in prior versions).
3. Thin provisioning also tends to be more efficient the larger the scale of the “thin pool” (i.e. the more oversubscribed objects) - and on an array, this construct (every vendor calls them something slightly different) tends to be broader than a single datastore - and therefore more efficiency factor tends to be higher.
Obviously if your array (or storage team) doesn’t support thin provisioning at the array level – go to town and use Thin at the VMware layer as much as possible.
What if your array DOES support Thin, and you are using it that way - is there a downside to “Thin on Thin”? Not really, and technically it can be the most efficient configuration – but only if you monitor usage. The only risk with “thin on thin” is that you can have an accelerated “out of space condition”.
Zdroj:
Prvy odstavec na strane 11 VMware dokumentu
Performance Study of VMware vStorage Thin Provisioning
www.vmware.com/pdf/vsp_4_thinprov_perf.pdf
Thin on Thin? Where should you do Thin Provisioning – vSphere 4.0 or Array-Level?
http://virtualgeek.typepad.com/virtual_geek/2009/04/thin-on-thin-where-should-you-do-thin-provisioning-vsphere-40-or-array-level.html
Thin disk po alokovani datastore priestoru nema vykonnostnu degradaciu
Zaujimavy postreh: Thin disk format VMDK virtualneho disku po alokovani blokov na podkladovom VMFS datastore nema vykonnostnu degradaciu oproti Thick Zeroed, resp. Thick Eager Zeroed formatom.
Dalsia zaujima vec je nasledovne:
In VMware Infrastructure 3.5, the CLI tools (service console or RCLI) could be used to configure the virtual disk format to any type, but when created via the GUI, certain configurations were the default (with no GUI option to change the type)
* On VMFS datastores, new virtual disks defaulted to Thick (zeroedthick)
* On NFS datastores, new virtual disks defaulted to Thin
* Deploying a VM from a template defaulted to eagerzeroedthick format
* Cloning a VM defaulted to an eagerzeroedthick format
This is why the creation of a new virtual disk has always been very fast, but in VMware Infrastructure 3.x cloning a VM or deploying a VM from a template (even with virtual disks that are nearly empty) took much longer.
Zdroj:
Strana 3, cast Thin Disks vo VMware dokumente Performance Study of VMware vStorage Thin Provisioning
http://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf
Thin on Thin? Where should you do Thin Provisioning – vSphere 4.0 or Array-Level?
http://virtualgeek.typepad.com/virtual_geek/2009/04/thin-on-thin-where-should-you-do-thin-provisioning-vsphere-40-or-array-level.html
Dalsia zaujima vec je nasledovne:
In VMware Infrastructure 3.5, the CLI tools (service console or RCLI) could be used to configure the virtual disk format to any type, but when created via the GUI, certain configurations were the default (with no GUI option to change the type)
* On VMFS datastores, new virtual disks defaulted to Thick (zeroedthick)
* On NFS datastores, new virtual disks defaulted to Thin
* Deploying a VM from a template defaulted to eagerzeroedthick format
* Cloning a VM defaulted to an eagerzeroedthick format
This is why the creation of a new virtual disk has always been very fast, but in VMware Infrastructure 3.x cloning a VM or deploying a VM from a template (even with virtual disks that are nearly empty) took much longer.
Zdroj:
Strana 3, cast Thin Disks vo VMware dokumente Performance Study of VMware vStorage Thin Provisioning
http://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf
Thin on Thin? Where should you do Thin Provisioning – vSphere 4.0 or Array-Level?
http://virtualgeek.typepad.com/virtual_geek/2009/04/thin-on-thin-where-should-you-do-thin-provisioning-vsphere-40-or-array-level.html
Prihlásiť na odber:
Príspevky (Atom)
Príspevky
