(5134,6,'2011-09-28 17:40:18','2011-09-28 17:40:18','<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/SymantecBackupExec2010R3.jpg\"><img class=\"alignleft size-full wp-image-5128\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/SymantecBackupExec2010R3.jpg\" alt=\"\" width=\"260\" height=\"64\" /></a>\n\nSymantec recently released Service Pack 1 for Backup Exec 2010 R3. The service pack is coming out and fixes a number of issues that have been in the works from Symantec. There are a number of items fixed in this release which as usual bundles a number of hotfixes.  Most notably fixes and fine tunes the deduplication service and Devices where some Backup to Disk (B2D) devices used for dedupe would show in-use when in fact they were not.\n\n&nbsp;\n\nThe list of hotfixes included in this release are:\n\nHotfix # 159961\nHotfix # 159967\nHotfix # 160008\nHotfix # 162830\nHotfix # 161720\nHotfix # 161390\nHotfix # 159965\nHotfix # 164220\n\n&nbsp;\n\nIssues resolved in this service pack include updates to the CASO, Core, Deduplication Option, Device &amp; Media, Hadware, IDR, Enterprise Vault Options, SharePoint Agent, and the VMware Agent to name a few.\n\nAs usual, the update can be found via Live Update. In the event your Live Update is not function, please refere to this <strong><a href=\"http://egroup.jasonmangone.com/symantec-live-update-is-not-installed-and-how-to-fix-it\">ARTICLE</a></strong> to resolve it.\n\nHere is a link the Symantec <strong><a href=\"http://www.symantec.com/business/support/index?page=content&amp;id=TECH169846\">RELEASE NOTES</a></strong> on Service Pack 1.\n\nBe sure to update and deploy the latest agents out at your earliest opportunity.','UPDATE YOUR BACKUP EXEC 2010 R3 WITH SERVICE PACK 1','','inherit','open','open','','5124-autosave','','','2011-09-28 17:40:18','2011-09-28 17:40:18','',5124,'http://egroup.jasonmangone.com/5124-autosave',0,'revision','',0),(5135,25,'2011-09-28 23:32:50','2011-09-28 23:32:50','When most companies begin the process of considering an implementation of a virtual desktop infrastructure, they automatically come in with expectations of a pooled VDI scenario.  They desire the benefits of VDI which include centralized management, improved security, and greater total cost savings over a traditional desktop deployment.  What surprises many businesses is that these benefits could be met, and normally exceeded by a Citrix Hosted Shared Desktop deployment.  There are many reasons for this, but I will touch on a few important ones here.\r\n\r\nCitrix Hosted Shared Desktops, once known in the Microsoft community as Terminal Services, offer greater density than a traditional Hosted VDI.  In fact, Citrix Hosted Shared Desktops can support of to 500 users per server.  A traditional Hosted VDI solution can typically only support around 150 users per server.  Obviously, this leads to a much higher return on investment, and lower total cost of ownership.\r\n\r\nAnother important reason to consider Hosted Shared Desktops is the ease of which the desktops can be managed.  The server on which the desktops run can be patched and maintained along with every other server in the data center.  The more desktops deployed in an implementation, the more important this point becomes.  Even a pooled VDI deployment has desktop images or variations that have to be updated on a regular basis.\r\n\r\nThere are many other reasons why Citrix Hosted Shared Desktops may be more advantageous than a traditional VDI deployment, but these two are top of the list.  That\'s not to say that traditional VDI does not have its place in the virtual desktop realm of solutions, but for many companies who are looking to take advantage of all the benefits that a virtual desktop deployment has to offer, Citrix Hosted Shared Desktops will meet or exceed expectations.','Why Hosted Shared Desktops May Be A Better Option For A Business Than Hosted VDI ','','publish','open','open','','why-hosted-shared-desktops-may-make-more-sense-for-a-business-than-hosted-vdi','','','2011-09-28 23:33:20','2011-09-28 23:33:20','',0,'http://egroup.jasonmangone.com/?p=5135',0,'post','',0),(5136,25,'2011-09-28 23:31:10','2011-09-28 23:31:10','When most companies begin the process of considering an implementaiton of a vitrual desktop infastructure, they automatically come in with expectaions of a pooled VDI secnario.  They desire the benefits of VDI which include centralized management, improved security, and greater total cost savings over a traditional desktop deployment.  What surprises many businesses is that these benifits could be met, and normally exceeded by a Citrix Hosted Shared Desktop deployment.  There are many reasons for this, but I will touch on a few important ones here.\n\nCitrix Hosted Shared Desktops, once known in the Microsoft community as Terminal Services, offer greater density than a traditional Hosted VDI.  In fact, Citrix Hosted Shared Desktops can support of to 500 users per server.  A tradional Hosted VDI solution can typically only support around 150 users per server.  Obviously, this leads to a much higher return on investment, and lower total cost of ownership.\n\nAnother important reason to consider Hosted Shared Desktops is the ease of which the desktops can be managed.  The server on which the desktops run can be patched and maintained along with every other server in the datacenter.  The more desktops depolyed in an implementaiton, the more important this point becomes.  Even a pooled VDI deployment has desktop images or variations that have to be updated on a regular basis.\n\nThere are many other reasons why Citrix Hosted Shared Desktops may be more advantagous than a tradional VDI deployment, but these two are top of the list.  That\'s not to say that traditional VDI does not have its place in the virtual desktop realm of solutions, but for many companies who are looking to take advantage of all the benifits that a virtual desktop deployment has to offer, Citrix Hosted Shared Desktops will meet or exceed expectations.','Why Hosted Shared Desktops May Make More Sense For A Business Than Hosted VDI ','','inherit','open','open','','5135-revision','','','2011-09-28 23:31:10','2011-09-28 23:31:10','',5135,'http://egroup.jasonmangone.com/5135-revision',0,'revision','',0),(5137,25,'2011-09-28 23:32:50','2011-09-28 23:32:50','When most companies begin the process of considering an implementation of a virtual desktop infrastructure, they automatically come in with expectations of a pooled VDI scenario.  They desire the benefits of VDI which include centralized management, improved security, and greater total cost savings over a traditional desktop deployment.  What surprises many businesses is that these benefits could be met, and normally exceeded by a Citrix Hosted Shared Desktop deployment.  There are many reasons for this, but I will touch on a few important ones here.\r\n\r\nCitrix Hosted Shared Desktops, once known in the Microsoft community as Terminal Services, offer greater density than a traditional Hosted VDI.  In fact, Citrix Hosted Shared Desktops can support of to 500 users per server.  A traditional Hosted VDI solution can typically only support around 150 users per server.  Obviously, this leads to a much higher return on investment, and lower total cost of ownership.\r\n\r\nAnother important reason to consider Hosted Shared Desktops is the ease of which the desktops can be managed.  The server on which the desktops run can be patched and maintained along with every other server in the data center.  The more desktops deployed in an implementation, the more important this point becomes.  Even a pooled VDI deployment has desktop images or variations that have to be updated on a regular basis.\r\n\r\nThere are many other reasons why Citrix Hosted Shared Desktops may be more advantageous than a traditional VDI deployment, but these two are top of the list.  That\'s not to say that traditional VDI does not have its place in the virtual desktop realm of solutions, but for many companies who are looking to take advantage of all the benefits that a virtual desktop deployment has to offer, Citrix Hosted Shared Desktops will meet or exceed expectations.','Why Hosted Shared Desktops May Make More Sense For A Business Than Hosted VDI ','','inherit','open','open','','5135-revision-2','','','2011-09-28 23:32:50','2011-09-28 23:32:50','',5135,'http://egroup.jasonmangone.com/5135-revision-2',0,'revision','',0),(5138,12,'2011-09-29 12:19:51','2011-09-29 12:19:51','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine that is used as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be stored locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth.\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 90% writes, and only 10% reads. This is the first level of IOPS \"savings\" resulting from the use of PVS. Is this really just \"caching\" for read IO? Yeah, kind of.\n\n&nbsp;\n\n&nbsp;','How','','inherit','open','open','','5112-revision-3','','','2011-09-29 12:19:51','2011-09-29 12:19:51','',5112,'http://egroup.jasonmangone.com/5112-revision-3',0,'revision','',0),(5139,12,'2011-09-29 12:26:35','2011-09-29 12:26:35','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine that is used as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 90% writes, and only 10% reads. This is the first level of IOPS savings resulting from the use of PVS. Is this really just \"caching\" for read IO? Yeah, kind of. Can\'t your storage array do this? Yep.\n\n&nbsp;\n\n&nbsp;','How','','inherit','open','open','','5112-revision-4','','','2011-09-29 12:26:35','2011-09-29 12:26:35','',5112,'http://egroup.jasonmangone.com/5112-revision-4',0,'revision','',0),(5140,12,'2011-09-29 13:56:38','2011-09-29 13:56:38','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine that is used as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\n\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across p','How','','inherit','open','open','','5112-revision-5','','','2011-09-29 13:56:38','2011-09-29 13:56:38','',5112,'http://egroup.jasonmangone.com/5112-revision-5',0,'revision','',0),(5141,12,'2011-09-29 13:57:38','2011-09-29 13:57:38','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine that is used as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\n\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\n\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','How','','inherit','open','open','','5112-revision-6','','','2011-09-29 13:57:38','2011-09-29 13:57:38','',5112,'http://egroup.jasonmangone.com/5112-revision-6',0,'revision','',0),(5142,12,'2011-09-29 13:59:27','2011-09-29 13:59:27','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine that is used as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\n\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\n\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\n\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES ','','inherit','open','open','','5112-revision-7','','','2011-09-29 13:59:27','2011-09-29 13:59:27','',5112,'http://egroup.jasonmangone.com/5112-revision-7',0,'revision','',0),(5145,12,'2011-09-29 14:52:46','2011-09-29 14:52:46','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\n\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\n\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\n\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES IOPS ','','inherit','open','open','','5112-revision-10','','','2011-09-29 14:52:46','2011-09-29 14:52:46','',5112,'http://egroup.jasonmangone.com/5112-revision-10',0,'revision','',0),(5143,12,'2011-09-29 14:00:46','2011-09-29 14:00:46','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine that is used as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\n\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\n\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\n\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES IOPS LOAD','','inherit','open','open','','5112-revision-8','','','2011-09-29 14:00:46','2011-09-29 14:00:46','',5112,'http://egroup.jasonmangone.com/5112-revision-8',0,'revision','',0),(5144,12,'2011-09-29 14:52:13','2011-09-29 14:52:13','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine that is used as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO).\r\n\r\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\r\n\r\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\r\n\r\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\r\n\r\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\r\n\r\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\r\n\r\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\r\n\r\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\r\n\r\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES IOPS ','','inherit','open','open','','5112-revision-9','','','2011-09-29 14:52:13','2011-09-29 14:52:13','',5112,'http://egroup.jasonmangone.com/5112-revision-9',0,'revision','',0),(5146,12,'2011-09-29 14:54:12','2011-09-29 14:54:12','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO from the viewpoint of a storage array).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\n\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\n\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\n\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES IOPS ','','inherit','open','open','','5112-revision-11','','','2011-09-29 14:54:12','2011-09-29 14:54:12','',5112,'http://egroup.jasonmangone.com/5112-revision-11',0,'revision','',0),(5147,12,'2011-09-29 18:37:48','2011-09-29 18:37:48','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO from the viewpoint of a storage array).\n\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\n\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\n\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Citrix\'s internal testing has showed about 120MB of the image is streamed for XP, and about 200MB for Windows 7. Here\'s where things get fun.\n\n<!--more-->\n\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of hitting the underlying disk with a read operation. This means you should be generous with the RAM you put in your PVS servers.\n\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS. UPDATE: I forgot to mention but this is not JUST for VDI, but works to physical target devices as well.\n\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\n\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\n\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES IOPS ','','inherit','open','open','','5112-autosave','','','2011-09-29 18:37:48','2011-09-29 18:37:48','',5112,'http://egroup.jasonmangone.com/5112-autosave',0,'revision','',0),(5148,12,'2011-09-29 15:08:29','2011-09-29 15:08:29','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO from the viewpoint of a storage array).\r\n\r\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\r\n\r\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\r\n\r\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\r\n\r\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of having to hit the underlying disk with a read operation.\r\n\r\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\r\n\r\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\r\n\r\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\r\n\r\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES IOPS ','','inherit','open','open','','5112-revision-12','','','2011-09-29 15:08:29','2011-09-29 15:08:29','',5112,'http://egroup.jasonmangone.com/5112-revision-12',0,'revision','',0),(5149,12,'2011-09-29 15:28:32','2011-09-29 15:28:32','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO from the viewpoint of a storage array).\r\n\r\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\r\n\r\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\r\n\r\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\r\n\r\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of hitting the underlying disk with a read operation. This means you should be generous with the RAM you put in your PVS servers.\r\n\r\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\r\n\r\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\r\n\r\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\r\n\r\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES IOPS ','','inherit','open','open','','5112-revision-13','','','2011-09-29 15:28:32','2011-09-29 15:28:32','',5112,'http://egroup.jasonmangone.com/5112-revision-13',0,'revision','',0),(5150,2,'2011-09-29 15:31:08','2011-09-29 15:31:08','','eGroup Sales Team Techincal Training Outline','','inherit','open','open','','egroup-sales-team-techincal-training-outline','','','2011-09-29 15:31:08','2011-09-29 15:31:08','',0,'http://egroup.jasonmangone.com/wp-content/uploads/2011/09/eGroup-Sales-Team-Techincal-Training-Outline.docx',0,'attachment','application/msword',0),(5388,6,'2011-10-31 15:38:56','2011-10-31 15:38:56','If you are experiencing issues with a Server 2008 R2 Print Server, and the print spooler service is continually going offline and stopping for unknown reasons, then follow this post to troubleshoot and resolve.\r\n\r\nNote: Mileage may vary depending on your environment.\r\n\r\nIn our case, the print spooler is running into Event ID 337:\r\n\r\n&nbsp;\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/printspool1.jpg\"><img class=\"alignleft size-full wp-image-5408\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/printspool1.jpg\" alt=\"\" width=\"444\" height=\"360\" /></a>\r\n\r\n The issue is pointing to Active Directory and a further investigation of the following event log points us to our ultimate destination.\r\n\r\n <a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/printspool2.jpg\"><img class=\"alignleft size-full wp-image-5395\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/printspool2.jpg\" alt=\"\" width=\"444\" height=\"360\" /></a>\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nWith this information in hand, we know that we are specifically dealing with a WSD issue on the Print Server itself.\r\n\r\nLog into the Print Server and review the properties of the Print Server. Be on the lookout specifically for \"WSD\" under the Ports tab.<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/printspooler31.jpg\"><img class=\"alignleft size-full wp-image-5399\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/printspooler31.jpg\" alt=\"\" width=\"444\" height=\"360\" /></a>\r\n\r\n&nbsp;\r\n\r\nIn this case we have one. This is the culprit. If you scan through your printers, you should find a printer that is not configured via an IP address like the others. He’ll be configured to use this port:\r\n\r\n&nbsp;\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/printspooler4.jpg\"><img class=\"alignleft size-full wp-image-5403\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/printspooler4.jpg\" alt=\"\" width=\"444\" height=\"360\" /></a>\r\n\r\nReconfigure the currently configured “WSD Printer” as an IP based Printer. Then circle back and delete the WSD port, and remove the WSD port from the Print Server Properties.\r\n\r\n&nbsp;\r\n\r\nYou should now see your PrintSpooler service run just fine.','SERVER 2008 R2 PRINT SPOOLER ISSUES AND HOW TO FIX','','publish','open','open','','server-2008-r2-print-spooler-issues-and-how-to-fix','','','2011-10-31 15:38:56','2011-10-31 15:38:56','',0,'http://egroup.jasonmangone.com/?p=5388',0,'post','',1),(5389,6,'2011-10-31 15:12:24','2011-10-31 15:12:24','','PrintSpooler1','','inherit','open','open','','printspooler1','','','2011-10-31 15:12:24','2011-10-31 15:12:24','',5388,'http://egroup.jasonmangone.com/wp-content/uploads/2011/10/PrintSpooler1.jpg',0,'attachment','image/jpeg',0),(5153,44,'2011-09-29 17:26:48','2011-09-29 17:26:48','VMware has released an excellent new 8-page FAQ on vSphere vCenter Site Recover Manager 5. The FAQ covers all aspects of the new release including product features, requirements, pricing and licensing. It also has instructions for downloading an evaluation copy of the software.\r\n\r\nThe FAQ can be found <a href=\"http://www.vmware.com/files/pdf/products/SRM/VMware-vCenter-Site-Recovery-Manager-FAQ.pdf\">here</a>.','VMWARE RELEASES NEW SRM 5 FAQ','','publish','open','open','','vmware-releases-new-srm-5-faq','','','2011-09-29 17:30:02','2011-09-29 17:30:02','',0,'http://egroup.jasonmangone.com/?p=5153',0,'post','',0),(5155,12,'2011-09-30 17:16:13','2011-09-30 17:16:13','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash/fingerprint for that file. If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file server type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated. If you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution, and \"fixed\" itself is an antonym for flexible, which is what we all want our technology to be.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size. It provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\n<strong>THE PROCESS</strong>\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\r\n\r\n<!--more-->\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its metadata (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','publish','open','open','','emc-avamar-how-source-global-dedupe-magic-happens','','','2011-09-30 17:16:36','2011-09-30 17:16:36','',0,'http://egroup.jasonmangone.com/?p=5155',0,'post','',0),(5156,12,'2011-09-29 17:12:06','2011-09-29 17:12:06','See my video below which outlines a high level overview of the backup process in an EMC Avamar solution. One thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication.\n\n&nbsp;\n\n&nbsp;\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP PROCESS','','inherit','open','open','','5155-revision','','','2011-09-29 17:12:06','2011-09-29 17:12:06','',5155,'http://egroup.jasonmangone.com/5155-revision',0,'revision','',0),(5157,44,'2011-09-29 17:07:46','2011-09-29 17:07:46','','Auto Draft','','inherit','open','open','','5153-revision','','','2011-09-29 17:07:46','2011-09-29 17:07:46','',5153,'http://egroup.jasonmangone.com/5153-revision',0,'revision','',0),(5159,44,'2011-09-29 17:26:14','2011-09-29 17:26:14','VMware has released an excellent new 8-page FAQ on vSphere vCenter Site Recover Manager 5. The FAQ covers all aspects of the new release, including licensing,\n\nThe FAQ can be found <a href=\"http://www.vmware.com/files/pdf/products/SRM/VMware-vCenter-Site-Recovery-Manager-FAQ.pdf\">here</a>.','VMWARE RELEASES NEW SRM 5 FAQ','','inherit','open','open','','5153-revision-2','','','2011-09-29 17:26:14','2011-09-29 17:26:14','',5153,'http://egroup.jasonmangone.com/5153-revision-2',0,'revision','',0),(5160,44,'2011-09-29 17:31:05','2011-09-29 17:31:05','VMware has released an excellent new 8-page FAQ on vSphere vCenter Site Recover Manager 5. The FAQ covers all aspects of the new release including product features, requirements, pricing and licensing. It also has instructions for downloading an evaluation copy of the software.\n\nThe FAQ can be found <a href=\"http://www.vmware.com/files/pdf/products/SRM/VMware-vCenter-Site-Recovery-Manager-FAQ.pdf\">here</a>.','VMWARE RELEASES NEW SRM 5 FAQ','','inherit','open','open','','5153-autosave','','','2011-09-29 17:31:05','2011-09-29 17:31:05','',5153,'http://egroup.jasonmangone.com/5153-autosave',0,'revision','',0),(5161,44,'2011-09-29 17:26:48','2011-09-29 17:26:48','VMware has released an excellent new 8-page FAQ on vSphere vCenter Site Recover Manager 5. The FAQ covers all aspects of the new release, including key product fetures, requirements and licensing.\r\n\r\nThe FAQ can be found <a href=\"http://www.vmware.com/files/pdf/products/SRM/VMware-vCenter-Site-Recovery-Manager-FAQ.pdf\">here</a>.','VMWARE RELEASES NEW SRM 5 FAQ','','inherit','open','open','','5153-revision-3','','','2011-09-29 17:26:48','2011-09-29 17:26:48','',5153,'http://egroup.jasonmangone.com/5153-revision-3',0,'revision','',0),(5162,12,'2011-09-29 17:28:45','2011-09-29 17:28:45','See my video below which outlines a high level overview of the backup process in an EMC Avamar solution. One thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\n\n&nbsp;\n\n&nbsp;\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP PROCESS','','inherit','open','open','','5155-revision-2','','','2011-09-29 17:28:45','2011-09-29 17:28:45','',5155,'http://egroup.jasonmangone.com/5155-revision-2',0,'revision','',0),(5163,12,'2011-10-14 12:18:04','2011-10-14 12:18:04','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (<a href=\"http://egroup.jasonmangone.com/how-citrix-provisioning-services-reduces-iops\" target=\"_blank\">see link here</a>). One of our Citrix Sales Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\r\n\r\nSo here it goes!\r\n\r\nThe goal here is simple-- minimize the cost of the horsepower needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage specifically for this image. And this is perfectly acceptable; a STRONG and highly available storage environment is critically important here and in all other virtualized environments. But again, the goal is to minimize the COST of the necessary horsepower the deployment.\r\n\r\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which is somewhat similar but specifically for bandwidth and end user experience optimization). The Intellicache technology leverages LOCAL disk drives in a XenServer host to \"offload\" disk operations from the storage array. Once the first virtual machine boots and begins to read against the master image, a XenServer host caches the master image data on the LOCAL hard disks configured for Intellicache, and future reads to the image are then satisfied locally. This tremendously reduces the IOPS load against your shared storage array.\r\n\r\nImagine 10 XenServers each hosting virtual desktops using MCS and leveraging Intellicache.  Instead of having all the disk operations taking place on a single LUN backed by a certain number of spindles, you\'re using the local disk drives in 10 XenServers and only communicating back out to the array when necessary. A huge shift in the workload-- from entirely consolidated, to a \"consolidated while shared\" model.\r\n\r\n<!--more-->\r\n\r\nAnd because the cost of local drives is more affordable than the drives in an Enterprise quality storage array, you can cut the CAPEX cost of your deployment (which is THE GOAL). You can even invest in solid state drives (they rock, by the way) for the local servers and drive the performance that much higher, and stay at a lower price point.\r\n\r\nIntellicache also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3. When a virtual desktop needs to read against the master image, the data is available and presented to it directly from the server its running on, which reduces the latency of that operation, and because it doesn\'t have to go \"out on the wire\", the bandwidth used is minimized.\r\n\r\n<img class=\"aligncenter\" src=\"http://img641.imageshack.us/img641/2762/citrixxenserverintellic.png\" alt=\"\" width=\"873\" height=\"482\" />','Citrix Intellicache FOR MCS - HOW IT REDUCES COST OF VDI DEPLOYMENT','','publish','open','open','','citrix-intellicache-for-mcs-how-it-reduces-cost-of-vdi-deployment','','','2011-10-14 12:18:04','2011-10-14 12:18:04','',0,'http://egroup.jasonmangone.com/?p=5163',0,'post','',0),(5290,23,'2011-10-09 16:48:21','2011-10-09 16:48:21','When you install SQL with Basic Management Tools, the installer does not allow you to go back and install the Complete Management Tools. The option will be grayed out.\n\nIn order to install the Complete Management Tools, insert the installation media for SQL, then open a command prompt and run the following...\n\nsetup.exe /FEATURES=Tools /Q /INDICATEPROGRESS /ACTION=Install /INSTANCENAME=SQLSERVER2008R2Ent /BROWSERSVCSTARTUPTYPE=Automatic /AGTSVCACCOUNT=”NT AUTHORITY\\NETWORK SERVICE” /IACCEPTSQLSERVERLICENSETERMS\n\nNote: Replace \"SQLSERVER2008R2Ent\" with the name of your instance.\nNote 2: The above command is for SQL 2008R2. SQL 2008 does not support the /IACCEPTSQLSERVERLICENSETERMS switch','SQL 2008R2: INSTALL COMPLETE MANAGEMENT TOOLS OVER BASIC','','inherit','open','open','','5256-revision-v1','','','2011-10-09 16:48:21','2011-10-09 16:48:21','',5256,'http://egroup.jasonmangone.com/5256-revision-2',0,'revision','',0),(5165,44,'2011-09-29 17:40:01','2011-09-29 17:40:01','<img title=\"Avamar Icon\" src=\"http://www.vmware.com/appliances/directory/uploaded_files/EMCAvamar/avamar%20icon.png\" alt=\"\" width=\"69\" height=\"68\" />An Avamar NDMP Accelerator node is an awesome way to connect your CIFS or NFS shares to one of the best backup solutions on the market today.\r\n\r\nWith Avamars powerful de-duplication technology coupled with the offloading capabilities of the NDMP accelerator to enable you to pass the data on the an EMC Celerra or NetApp solution through to the Avamar grid for efficient backup of these files.\r\n\r\nImportant note, though....With the NDMP backup solution, there must be some head room in the pool for the backup caching.  20GB is the minimum, but it could be more than that if the pool is really large.\r\n\r\nThe benefits fair out weigh the small size requirement for the backup.  And with Avamar the files are broken down into sub-file level pieces that are de-duplicated at at that level.  Resulting in an awesome ability to take files that are different and only backup the parts of the file that are different.\r\n\r\nFor example....\r\n\r\nIf a file template was used to create a document (say doc1.docx) and the that same template was used for another document (doc2.docx), when those files are backed up, traditionally, both full files would be backed up with no de-duplication since they are different files.  With Avamar, it breaks those two files down and only backs up the parts that are different.  So, you still get a portion of de-duplication on the file even though they are different.\r\n\r\nEfficient and awesome','Avamar and NDMP','','publish','open','open','','avamar-and-ndmp','','','2011-09-30 19:42:23','2011-09-30 19:42:23','',0,'http://egroup.jasonmangone.com/?p=5165',0,'post','',0),(5166,44,'2011-09-29 17:39:49','2011-09-29 17:39:49','','Avamar and NDMP','','inherit','open','open','','5165-revision','','','2011-09-29 17:39:49','2011-09-29 17:39:49','',5165,'http://egroup.jasonmangone.com/5165-revision',0,'revision','',0),(5167,44,'2011-09-29 17:39:53','2011-09-29 17:39:53','<img title=\"Avamar Icon\" src=\"http://www.vmware.com/appliances/directory/uploaded_files/EMCAvamar/avamar%20icon.png\" alt=\"\" width=\"69\" height=\"68\" />An Avamar NDMP Accelerator node is an awesome way to connect your CIFS or NFS shares to one of the best backup solutions on the market today.\r\n\r\nWith Avamars powerful de-duplication technology coupled with the offloading capabilities of the NDMP accelerator to enable you to pass the data on the an EMC Celerra or NetApp solution through to the Avamar grid for efficient backup of these files.\r\n\r\nImportant note, though....With the NDMP backup solution, there must be some head room in the pool for the backup caching.  20GB is the minimum, but it could be more than that if the pool is really large.\r\n\r\nThe benefits fair out weigh the small size requirement for the backup.  And with Avamar the files are broken down into sub-file level pieces that are de-duplicated at at that level.  Resulting in an awesome ability to take files that are different and only backup the parts of the file that are different.\r\n\r\nFor example....\r\n\r\nIf a file template was used to create a document (say doc1.docx) and the that same template was used for another document (doc2.docx), when those files are backed up, traditionally, both full files would be backed up with no de-duplication since they are different files.  With Avamar, it breaks those two files down and only backs up the parts that are different.  So, you still get a portion of de-duplication on the file even though they are different.\r\n\r\nEfficient and awesome','Avamar and NDMP','','inherit','open','open','','5165-revision-2','','','2011-09-29 17:39:53','2011-09-29 17:39:53','',5165,'http://egroup.jasonmangone.com/5165-revision-2',0,'revision','',0),(5168,44,'2011-09-29 17:41:05','2011-09-29 17:41:05','<img title=\"Avamar Icon\" src=\"http://www.vmware.com/appliances/directory/uploaded_files/EMCAvamar/avamar%20icon.png\" alt=\"\" width=\"69\" height=\"68\" />An Avamar NDMP Accelerator node is an awesome way to connect your CIFS or NFS shares to one of the best backup solutions on the market today.\n\nWith Avamars powerful de-duplication technology coupled with the offloading capabilities of the NDMP accelerator to enable you to pass the data on the an EMC Celerra or NetApp solution through to the Avamar grid for efficient backup of these files.\n\nImportant note, though....With the NDMP backup solution, there must be some head room in the pool for the backup caching.  20GB is the minimum, but it could be more than that if the pool is really large.\n\nThe benefits fair out weigh the small size requirement for the backup.  And with Avamar the files are broken down into sub-file level pieces that are de-duplicated at at that level.  Resulting in an awesome ability to take files that are different and only backup the parts of the file that are different.\n\nFor example....\n\nIf a file template was used to create a document (say doc1.docx) and the that same template was used for another document (doc2.docx), when those files are backed up, traditionally, both full files would be backed up with no de-duplication since they are different files.  With Avamar, it breaks those two files down and only backs up the parts that are different.  So, you still get a portion of de-duplication on the file even though they are different.\n\nEfficient and awesome','Avamar and NDMP','','inherit','open','open','','5165-autosave','','','2011-09-29 17:41:05','2011-09-29 17:41:05','',5165,'http://egroup.jasonmangone.com/5165-autosave',0,'revision','',0),(5169,12,'2011-09-29 17:49:14','2011-09-29 17:49:14','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\".\n\nSo here it goes!\n\nIt\'s important to understand the goal here-- to minimize the amount of horsepower and cost needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work around this, lots of environments invest heavily in their underlying storage. And this is absolutely acceptable, and a STRONG/SOLID storage environment is STILL critically important here and in all other virtualized environments. But again, the goal is to minimize the amount of horsepower and cost to support this particular deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which does operate similarly but specifically for bandwidth and end user experience optimization). This technology leverages the LOCAL drives in the XenServer host itself to help \"offload\" disk operations.\n\n&nbsp;','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS','','inherit','open','open','','5163-revision','','','2011-09-29 17:49:14','2011-09-29 17:49:14','',5163,'http://egroup.jasonmangone.com/5163-revision',0,'revision','',0),(5170,12,'2011-09-29 18:07:12','2011-09-29 18:07:12','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\".\n\nSo here it goes!\n\nIt\'s important to understand the goal here-- to minimize the amount of horsepower and cost needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work around this, lots of environments invest heavily in their underlying storage. And this is absolutely acceptable, and a STRONG/SOLID storage environment is STILL critically important here and in all other virtualized environments. But again, the goal is to minimize the amount of horsepower and cost to support this particular deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which does operate similarly but specifically for bandwidth and end user experience optimization). This technology leverages the LOCAL drives in the XenServer host itself to help \"offload\" disk operations. Once the first virtual machine boots, XenServer caches the virtual machine on the local disks configured for Intellicache, and future reads to the image are then satisfied locally, which tremendously reduces the IOPS load against your shared storage array. It also offloads and reduces the use of bandwidth on the storage network, which in an NFSv3 environment can be\n\n&nbsp;','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-2','','','2011-09-29 18:07:12','2011-09-29 18:07:12','',5163,'http://egroup.jasonmangone.com/5163-revision-2',0,'revision','',0),(5171,12,'2011-09-29 18:08:23','2011-09-29 18:08:23','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\".\n\nSo here it goes!\n\nIt\'s important to understand the goal here-- to minimize the amount of horsepower and cost needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work around this, lots of environments invest heavily in their underlying storage. And this is absolutely acceptable, and a STRONG/SOLID storage environment is STILL critically important here and in all other virtualized environments. But again, the goal is to minimize the amount of horsepower and cost to support this particular deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which does operate similarly but specifically for bandwidth and end user experience optimization). This technology leverages the LOCAL drives in the XenServer host itself to help \"offload\" disk operations. Once the first virtual machine boots, XenServer caches the virtual machine on the local disks configured for Intellicache, and future reads to the image are then satisfied locally, which tremendously reduces the IOPS load against your shared storage array. It also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFS 3\n\n&nbsp;','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-3','','','2011-09-29 18:08:23','2011-09-29 18:08:23','',5163,'http://egroup.jasonmangone.com/5163-revision-3',0,'revision','',0),(5172,12,'2011-09-29 15:28:52','2011-09-29 15:28:52','During a whiteboard session laying out the Citrix Flexcast models, someone asked how Provisioning Server reduces the amount of IOPS that the underlying disks or storage array sustain as part of a VDI deployment. This is usually to compare it against things like Citrix\'s MCS or VMware\'s Linked Clone technology, which use a \"master image\" machine as the base image of additional machines, and thus receives high levels of disk activity (very read intensive especially during provisioning, see<a href=\"http://egroup.jasonmangone.com/emc-vnx-fast-cache-ten-10k-drives-17000-iops\" target=\"_blank\"> this post </a>which shows the breakdown of IO from the viewpoint of a storage array).\r\n\r\nFirst, it\'s important to understand that the PVS server streams a virtual hard disk over the network to a target device, and the virtual hard disk itself is stored in a single file, which can be locally, on a file share on a file server, on a storage array, etc. We commonly find this on a CIFS share, where the data resides on a highly redundant system that provides the necessary level of availability/redundancy and bandwidth (something like an EMC VNX or Celerra).\r\n\r\nIn a XenDesktop VDI deployment, the target device is a virtual machine running on your hypervisor of choice (Citrix supports hypervisors from Microsoft and VMware in addition to their own). So we\'ll start from here.\r\n\r\nWithout going into the details of the process-- A virtual machine turns on, PXE boots and based on its vDisk assignment on the PVS Server itself, a vDisk is mounted on the PVS Server. The virtual machine then boots, and <strong>only the data needed</strong> is streamed to it in real-time (as opposed to streaming the entire disk itself). Here\'s where things get fun.\r\n\r\n<!--more-->\r\n\r\nAs much of the vDisk as possible (and I imagine based on what\'s actually used/pulled from the vDisk actively) get stored in RAM on the PVS server itself. When a virtual machine needs something else from the virtual hard disk, the PVS streams is down over the network, and as best as possible, delivers this through RAM instead of hitting the underlying disk with a read operation. This means you should be generous with the RAM you put in your PVS servers.\r\n\r\nBecause of this, it\'s common to find IO profiles in PVS environments that are 80% writes, and only 20% reads, sometimes even higher (90/10). This is the first level of IOPS savings resulting from the use of PVS.\r\n\r\nHere\'s a visual layout of how this works. Notice the light blue sections are possible locations for the write cache, which allows you to spread the remaining \"write\" workload across possible VMFS data stores, local to the PVS server itself, or even in the target device\'s RAM (which in our case is a virtual machine).\r\n\r\nThe purple looking color shows locations where you could store the virtual hard disks themselves (keep in mind that you want these on something highly available).\r\n\r\n<img class=\"aligncenter\" src=\"http://img855.imageshack.us/img855/707/citrixpvs.png\" alt=\"\" width=\"867\" height=\"510\" />','HOW Citrix Provisioning Services REDUCES IOPS ','','inherit','open','open','','5112-revision-14','','','2011-09-29 15:28:52','2011-09-29 15:28:52','',5112,'http://egroup.jasonmangone.com/5112-revision-14',0,'revision','',0),(5173,12,'2011-09-29 18:44:56','2011-09-29 18:44:56','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\".\n\nSo here it goes!\n\nIt\'s important to understand the goal here-- to minimize the amount of horsepower and cost needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work around this, lots of environments invest heavily in their underlying storage. And this is absolutely acceptable, and a STRONG/SOLID storage environment is STILL critically important here and in all other virtualized environments. But again, the goal is to minimize the amount of horsepower and cost to support this particular deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which does operate similarly but specifically for bandwidth and end user experience optimization). This technology leverages the LOCAL drives in the XenServer host itself to help \"offload\" disk operations. Once the first virtual machine boots and begins to read against the master image, XenServer caches the master image data on the local disks configured for Intellicache, and future reads to the image are then satisfied locally, which tremendously reduces the IOPS load against your shared storage array. It also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFS 3, this can help you overcome the \"single TCP\n\n&nbsp;','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-4','','','2011-09-29 18:44:56','2011-09-29 18:44:56','',5163,'http://egroup.jasonmangone.com/5163-revision-4',0,'revision','',0),(5174,12,'2011-09-29 18:46:09','2011-09-29 18:46:09','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\".\n\nSo here it goes!\n\nIt\'s important to understand the goal here-- to minimize the amount of horsepower and cost needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work around this, lots of environments invest heavily in their underlying storage. And this is absolutely acceptable, and a STRONG/SOLID storage environment is STILL critically important here and in all other virtualized environments. But again, the goal is to minimize the amount of horsepower and cost to support this particular deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which does operate similarly but specifically for bandwidth and end user experience optimization). This technology leverages the LOCAL drives in the XenServer host itself to help \"offload\" disk operations. Once the first virtual machine boots and begins to read against the master image, XenServer caches the master image data on the local disks configured for Intellicache, and future reads to the image are then satisfied locally, which tremendously reduces the IOPS load against your shared storage array. It also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3.\n\n&nbsp;','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-5','','','2011-09-29 18:46:09','2011-09-29 18:46:09','',5163,'http://egroup.jasonmangone.com/5163-revision-5',0,'revision','',0),(5175,12,'2011-09-29 17:33:09','2011-09-29 17:33:09','See my video below which outlines a high level overview of the backup process in an EMC Avamar solution. One thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP PROCESS','','inherit','open','open','','5155-revision-3','','','2011-09-29 17:33:09','2011-09-29 17:33:09','',5155,'http://egroup.jasonmangone.com/5155-revision-3',0,'revision','',0),(5176,44,'2011-09-29 20:14:28','2011-09-29 20:14:28','Many times this has been a sticking point for ASA code upgrades, but the time is coming where the 8.3 code update is going to be a requirement (as I have found with the AIP modules).\r\n\r\n&nbsp;\r\n\r\nHUGE reminder that the upgrade from 8.2 to 8.3 is not an easy or simple upgrade.\r\n\r\n&nbsp;\r\n\r\nThere is also no skipping ahead.  You have to go from 8.2 to 8.3, you can\'t jump over 8.2, you have to upgrade to 8.2 first if you aren\'t already there.\r\n\r\n&nbsp;\r\n\r\nThere are a lot of changes to the code, but none as noticeable as the new NAT statements.\r\n\r\n&nbsp;\r\n\r\nAnother big reminder is to disable nat-control BEFORE you perform the upgrade.  This is the feature that made it so that you had to configure NAT statements between the different interfaces.\r\n\r\n&nbsp;\r\n\r\nBelow is a chart comparing the configuration steps from 8.2 to 8.3 for NAT statements.\r\n\r\n&nbsp;\r\n<table cellspacing=\"0\" cellpadding=\"0\">\r\n<tbody>\r\n<tr>\r\n<td valign=\"middle\"><strong>NAT Feature</strong></td>\r\n<td valign=\"middle\"><strong>pre-8.3 Configuration</strong></td>\r\n<td valign=\"middle\"><strong>8.3 Configuration</strong></td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Static NAT</td>\r\n<td valign=\"middle\">static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255</td>\r\n<td valign=\"middle\"><strong>Option 1 (Preferred)</strong>object network obj-10.1.1.6host 10.1.1.6\r\n\r\nnat (inside,outside) static 209.165.201.15\r\n\r\n&nbsp;\r\n\r\n<strong>Option 2\r\n</strong>\r\n\r\nobject network server_real\r\n\r\nhost 10.1.1.6\r\n\r\nobject network server_global\r\n\r\nhost 209.165.201.15\r\n\r\n!\r\n\r\nnat (inside,outside) source static server_real server_global</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Dynamic PAT</td>\r\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0global (outside) 1 209.165.201.254</td>\r\n<td valign=\"middle\">object network internal_netsubnet 10.1.1.0 255.255.255.0!\r\n\r\nobject network internal_net\r\n\r\n&nbsp;\r\n\r\nnat (inside,outside) dynamic 209.165.201.254</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Dynamic NAT with Interface Overload</td>\r\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0global (outside) 1 interface\r\n\r\n&nbsp;\r\n\r\nglobal (outside) 1 209.165.201.1-209.165.201.2</td>\r\n<td valign=\"middle\">object network NAT_Poolrange 209.165.201.2 209.165.201.50object network internal_net\r\n\r\nsubnet 10.1.1.0 255.255.255.0\r\n\r\n!\r\n\r\nobject network internal_net\r\n\r\nnat (inside,outside) dynamic NAT_Pool interface</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n&nbsp;\r\n\r\n<!--more-->\r\n\r\nThe next big one is ACLs (Access Control Lists).  The command syntax hasn\'t changed much for these, just the IP that is used for the rule.\r\n\r\n&nbsp;\r\n\r\nIn the past when you were allowing traffic to a server you would configure it to point to the public IP that the server was NAT\'d to.  Now it is configured to the internal address.  For example....\r\n\r\n&nbsp;\r\n\r\nBelow is the way you would normally configure an ACL\r\n\r\n&nbsp;\r\n\r\nstatic (inside,outside) 208.268.11.17 10.100.1.11 netmask 255.255.255.255\r\n\r\n!\r\n\r\naccess-list outside_in extended permit tcp any host 208.268.11.17\r\n\r\naccess-group outside_in in interface outside\r\n\r\n&nbsp;\r\n\r\nWith 8.3 you use network objects, like below.\r\n\r\n&nbsp;\r\n\r\nobject network obj-10.100.1.11\r\n\r\nhost 10.100.1.11\r\n\r\nnat (inside,outside) static 208.268.11.17\r\n\r\n!\r\n\r\naccess-list outside_in extended permit tcp any host 10.100.1.11\r\n\r\naccess-group outside_in in interface outside\r\n\r\n&nbsp;\r\n\r\nYou can see the difference.\r\n\r\n&nbsp;\r\n\r\nThe big caveat with the upgrade is that the process is supposed to make the adjustments automatically.  I have found that is not always the case.  All the static NATs tend to need some tweaking, as well as a lot of the Access Rules.\r\n\r\n&nbsp;\r\n\r\nBest bet is to make sure that you have a good understanding of the changes before diving into the upgrade.\r\n\r\n&nbsp;\r\n\r\nThanks to <a title=\"Cisco Support Forums\" href=\"https://supportforums.cisco.com/docs/DOC-12690\" target=\"_blank\">Cisco Support Forums</a> for the information.','Cisco ASA 8.3 Upgrade - Lessons Learned','','publish','open','open','','cisco-asa-8-3-upgrade-lessons-learned','','','2011-09-30 19:40:58','2011-09-30 19:40:58','',0,'http://egroup.jasonmangone.com/?p=5176',0,'post','',0),(5177,44,'2011-09-29 20:08:39','2011-09-29 20:08:39','Many times this has been a sticking point for ASA code upgrades, but the time is coming where the 8.3 code update is going to be a requirement (as I have found with the AIP modules).\n\n&nbsp;\n\nHUGE reminder that the upgrade from 8.2 to 8.3 is not an easy or simple upgrade.\n\n&nbsp;\n\nThere is also no skipping ahead.  You have to go from 8.2 to 8.3, you can\'t jump over 8.2, you have to upgrade to 8.2 first if you aren\'t already there.\n\n&nbsp;\n\nThere are a lot of changes to the code, but none as noticeable as the new NAT statements.\n\n&nbsp;\n\nAnother big reminder is to disable nat-control BEFORE you perform the upgrade.  This is the feature that made it so that you had to configure NAT statements between the different interfaces.\n\n&nbsp;\n\nBelow is a chart comparing the configuration steps from 8.2 to 8.3 for NAT statements.\n\n&nbsp;\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td valign=\"middle\"><strong>NAT Feature</strong>\n\n&nbsp;</td>\n<td valign=\"middle\"><strong>pre-8.3 Configuration</strong>\n\n&nbsp;</td>\n<td valign=\"middle\"><strong>8.3 Configuration</strong>\n\n&nbsp;</td>\n</tr>\n<tr>\n<td valign=\"middle\">Static NAT</td>\n<td valign=\"middle\">static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255</td>\n<td valign=\"middle\"><strong>Option 1 (Preferred)</strong>\n\nobject network obj-10.1.1.6\n\nhost 10.1.1.6\n\nnat (inside,outside) static 209.165.201.15\n\n&nbsp;\n\n<strong>Option 2\n</strong>\n\nobject network server_real\n\nhost 10.1.1.6\n\nobject network server_global\n\nhost 209.165.201.15\n\n!\n\nnat (inside,outside) source static server_real server_global</td>\n</tr>\n<tr>\n<td valign=\"middle\">Dynamic PAT</td>\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0\n\n&nbsp;\n\nglobal (outside) 1 209.165.201.254</td>\n<td valign=\"middle\">object network internal_net\n\nsubnet 10.1.1.0 255.255.255.0\n\n!\n\nobject network internal_net\n\n&nbsp;\n\nnat (inside,outside) dynamic 209.165.201.254</td>\n</tr>\n<tr>\n<td valign=\"middle\">Dynamic NAT with Interface Overload</td>\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0\n\n&nbsp;\n\nglobal (outside) 1 interface\n\n&nbsp;\n\nglobal (outside) 1 209.165.201.1-209.165.201.2</td>\n<td valign=\"middle\">object network NAT_Pool\n\nrange 209.165.201.2 209.165.201.50\n\nobject network internal_net\n\nsubnet 10.1.1.0 255.255.255.0\n\n!\n\nobject network internal_net\n\nnat (inside,outside) dynamic NAT_Pool interface</td>\n</tr>\n</tbody>\n</table>\n&nbsp;\n\n&nbsp;\n\nThe next big one is ACLs (Access Control Lists).  The command syntax hasn\'t changed much for these, just the IP that is used for the rule.\n\n&nbsp;\n\nIn the past when you were allowing traffic to a server you would configure it to point to the public IP that the server was NAT\'d to.  Now it is configured to the internal address.  For example....\n\n&nbsp;\n\nBelow is the way you would normally configure an ACL\n\n&nbsp;\n\nstatic (inside,outside) 208.268.11.17 10.100.1.11 netmask 255.255.255.255\n\n!\n\naccess-list outside_in extended permit tcp any host 208.268.11.17\n\naccess-group outside_in in interface outside\n\n&nbsp;\n\nWith 8.3 you use network objects, like below.\n\n&nbsp;\n\nobject network obj-10.100.1.11\n\nhost 10.100.1.11\n\nnat (inside,outside) static 208.268.11.17\n\n!\n\naccess-list outside_in extended permit tcp any host 10.100.1.11\n\naccess-group outside_in in interface outside\n\n&nbsp;\n\nYou can see the difference.\n\n&nbsp;\n\nThe big caveat with the upgrade is that the process is supposed to make the adjustments automatically.  I have found that is not always the case.  All the static NATs tend to need some tweaking, as well as a lot of the Access Rules.\n\n&nbsp;\n\nBest bet is to make sure that you have a good understanding of the changes before diving into the upgrade.','Cisco ASA 8.3 Upgrade - Lessons Learned','','inherit','open','open','','5176-revision','','','2011-09-29 20:08:39','2011-09-29 20:08:39','',5176,'http://egroup.jasonmangone.com/5176-revision',0,'revision','',0),(5178,44,'2011-09-29 20:13:05','2011-09-29 20:13:05','Many times this has been a sticking point for ASA code upgrades, but the time is coming where the 8.3 code update is going to be a requirement (as I have found with the AIP modules).\n\n&nbsp;\n\nHUGE reminder that the upgrade from 8.2 to 8.3 is not an easy or simple upgrade.\n\n&nbsp;\n\nThere is also no skipping ahead.  You have to go from 8.2 to 8.3, you can\'t jump over 8.2, you have to upgrade to 8.2 first if you aren\'t already there.\n\n&nbsp;\n\nThere are a lot of changes to the code, but none as noticeable as the new NAT statements.\n\n&nbsp;\n\nAnother big reminder is to disable nat-control BEFORE you perform the upgrade.  This is the feature that made it so that you had to configure NAT statements between the different interfaces.\n\n&nbsp;\n\nBelow is a chart comparing the configuration steps from 8.2 to 8.3 for NAT statements.\n\n&nbsp;\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td valign=\"middle\"><strong>NAT Feature</strong>\n\n&nbsp;</td>\n<td valign=\"middle\"><strong>pre-8.3 Configuration</strong>\n\n&nbsp;</td>\n<td valign=\"middle\"><strong>8.3 Configuration</strong>\n\n&nbsp;</td>\n</tr>\n<tr>\n<td valign=\"middle\">Static NAT</td>\n<td valign=\"middle\">static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255</td>\n<td valign=\"middle\"><strong>Option 1 (Preferred)</strong>\n\nobject network obj-10.1.1.6\n\nhost 10.1.1.6\n\nnat (inside,outside) static 209.165.201.15\n\n&nbsp;\n\n<strong>Option 2\n</strong>\n\nobject network server_real\n\nhost 10.1.1.6\n\nobject network server_global\n\nhost 209.165.201.15\n\n!\n\nnat (inside,outside) source static server_real server_global</td>\n</tr>\n<tr>\n<td valign=\"middle\">Dynamic PAT</td>\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0\n\n&nbsp;\n\nglobal (outside) 1 209.165.201.254</td>\n<td valign=\"middle\">object network internal_net\n\nsubnet 10.1.1.0 255.255.255.0\n\n!\n\nobject network internal_net\n\n&nbsp;\n\nnat (inside,outside) dynamic 209.165.201.254</td>\n</tr>\n<tr>\n<td valign=\"middle\">Dynamic NAT with Interface Overload</td>\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0\n\n&nbsp;\n\nglobal (outside) 1 interface\n\n&nbsp;\n\nglobal (outside) 1 209.165.201.1-209.165.201.2</td>\n<td valign=\"middle\">object network NAT_Pool\n\nrange 209.165.201.2 209.165.201.50\n\nobject network internal_net\n\nsubnet 10.1.1.0 255.255.255.0\n\n!\n\nobject network internal_net\n\nnat (inside,outside) dynamic NAT_Pool interface</td>\n</tr>\n</tbody>\n</table>\n&nbsp;\n\n&nbsp;\n\nThe next big one is ACLs (Access Control Lists).  The command syntax hasn\'t changed much for these, just the IP that is used for the rule.\n\n&nbsp;\n\nIn the past when you were allowing traffic to a server you would configure it to point to the public IP that the server was NAT\'d to.  Now it is configured to the internal address.  For example....\n\n&nbsp;\n\nBelow is the way you would normally configure an ACL\n\n&nbsp;\n\nstatic (inside,outside) 208.268.11.17 10.100.1.11 netmask 255.255.255.255\n\n!\n\naccess-list outside_in extended permit tcp any host 208.268.11.17\n\naccess-group outside_in in interface outside\n\n&nbsp;\n\nWith 8.3 you use network objects, like below.\n\n&nbsp;\n\nobject network obj-10.100.1.11\n\nhost 10.100.1.11\n\nnat (inside,outside) static 208.268.11.17\n\n!\n\naccess-list outside_in extended permit tcp any host 10.100.1.11\n\naccess-group outside_in in interface outside\n\n&nbsp;\n\nYou can see the difference.\n\n&nbsp;\n\nThe big caveat with the upgrade is that the process is supposed to make the adjustments automatically.  I have found that is not always the case.  All the static NATs tend to need some tweaking, as well as a lot of the Access Rules.\n\n&nbsp;\n\nBest bet is to make sure that you have a good understanding of the changes before diving into the upgrade.','Cisco ASA 8.3 Upgrade - Lessons Learned','','inherit','open','open','','5176-revision-2','','','2011-09-29 20:13:05','2011-09-29 20:13:05','',5176,'http://egroup.jasonmangone.com/5176-revision-2',0,'revision','',0),(5179,44,'2011-09-29 20:13:41','2011-09-29 20:13:41','Many times this has been a sticking point for ASA code upgrades, but the time is coming where the 8.3 code update is going to be a requirement (as I have found with the AIP modules).\r\n\r\n&nbsp;\r\n\r\nHUGE reminder that the upgrade from 8.2 to 8.3 is not an easy or simple upgrade.\r\n\r\n&nbsp;\r\n\r\nThere is also no skipping ahead.  You have to go from 8.2 to 8.3, you can\'t jump over 8.2, you have to upgrade to 8.2 first if you aren\'t already there.\r\n\r\n&nbsp;\r\n\r\nThere are a lot of changes to the code, but none as noticeable as the new NAT statements.\r\n\r\n&nbsp;\r\n\r\nAnother big reminder is to disable nat-control BEFORE you perform the upgrade.  This is the feature that made it so that you had to configure NAT statements between the different interfaces.\r\n\r\n&nbsp;\r\n\r\nBelow is a chart comparing the configuration steps from 8.2 to 8.3 for NAT statements.\r\n\r\n&nbsp;\r\n<table cellspacing=\"0\" cellpadding=\"0\">\r\n<tbody>\r\n<tr>\r\n<td valign=\"middle\"><strong>NAT Feature</strong>\r\n\r\n&nbsp;</td>\r\n<td valign=\"middle\"><strong>pre-8.3 Configuration</strong>\r\n\r\n&nbsp;</td>\r\n<td valign=\"middle\"><strong>8.3 Configuration</strong>\r\n\r\n&nbsp;</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Static NAT</td>\r\n<td valign=\"middle\">static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255</td>\r\n<td valign=\"middle\"><strong>Option 1 (Preferred)</strong>\r\n\r\nobject network obj-10.1.1.6\r\n\r\nhost 10.1.1.6\r\n\r\nnat (inside,outside) static 209.165.201.15\r\n\r\n&nbsp;\r\n\r\n<strong>Option 2\r\n</strong>\r\n\r\nobject network server_real\r\n\r\nhost 10.1.1.6\r\n\r\nobject network server_global\r\n\r\nhost 209.165.201.15\r\n\r\n!\r\n\r\nnat (inside,outside) source static server_real server_global</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Dynamic PAT</td>\r\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0\r\n\r\n&nbsp;\r\n\r\nglobal (outside) 1 209.165.201.254</td>\r\n<td valign=\"middle\">object network internal_net\r\n\r\nsubnet 10.1.1.0 255.255.255.0\r\n\r\n!\r\n\r\nobject network internal_net\r\n\r\n&nbsp;\r\n\r\nnat (inside,outside) dynamic 209.165.201.254</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Dynamic NAT with Interface Overload</td>\r\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0\r\n\r\n&nbsp;\r\n\r\nglobal (outside) 1 interface\r\n\r\n&nbsp;\r\n\r\nglobal (outside) 1 209.165.201.1-209.165.201.2</td>\r\n<td valign=\"middle\">object network NAT_Pool\r\n\r\nrange 209.165.201.2 209.165.201.50\r\n\r\nobject network internal_net\r\n\r\nsubnet 10.1.1.0 255.255.255.0\r\n\r\n!\r\n\r\nobject network internal_net\r\n\r\nnat (inside,outside) dynamic NAT_Pool interface</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nThe next big one is ACLs (Access Control Lists).  The command syntax hasn\'t changed much for these, just the IP that is used for the rule.\r\n\r\n&nbsp;\r\n\r\nIn the past when you were allowing traffic to a server you would configure it to point to the public IP that the server was NAT\'d to.  Now it is configured to the internal address.  For example....\r\n\r\n&nbsp;\r\n\r\nBelow is the way you would normally configure an ACL\r\n\r\n&nbsp;\r\n\r\nstatic (inside,outside) 208.268.11.17 10.100.1.11 netmask 255.255.255.255\r\n\r\n!\r\n\r\naccess-list outside_in extended permit tcp any host 208.268.11.17\r\n\r\naccess-group outside_in in interface outside\r\n\r\n&nbsp;\r\n\r\nWith 8.3 you use network objects, like below.\r\n\r\n&nbsp;\r\n\r\nobject network obj-10.100.1.11\r\n\r\nhost 10.100.1.11\r\n\r\nnat (inside,outside) static 208.268.11.17\r\n\r\n!\r\n\r\naccess-list outside_in extended permit tcp any host 10.100.1.11\r\n\r\naccess-group outside_in in interface outside\r\n\r\n&nbsp;\r\n\r\nYou can see the difference.\r\n\r\n&nbsp;\r\n\r\nThe big caveat with the upgrade is that the process is supposed to make the adjustments automatically.  I have found that is not always the case.  All the static NATs tend to need some tweaking, as well as a lot of the Access Rules.\r\n\r\n&nbsp;\r\n\r\nBest bet is to make sure that you have a good understanding of the changes before diving into the upgrade.\r\n\r\n&nbsp;\r\n\r\nThanks to <a title=\"Cisco Support Forums\" href=\"https://supportforums.cisco.com/docs/DOC-12690\" target=\"_blank\">Cisco Support Forums</a> for the information.','Cisco ASA 8.3 Upgrade - Lessons Learned','','inherit','open','open','','5176-revision-3','','','2011-09-29 20:13:41','2011-09-29 20:13:41','',5176,'http://egroup.jasonmangone.com/5176-revision-3',0,'revision','',0),(5180,44,'2011-09-29 20:13:44','2011-09-29 20:13:44','Many times this has been a sticking point for ASA code upgrades, but the time is coming where the 8.3 code update is going to be a requirement (as I have found with the AIP modules).\r\n\r\n&nbsp;\r\n\r\nHUGE reminder that the upgrade from 8.2 to 8.3 is not an easy or simple upgrade.\r\n\r\n&nbsp;\r\n\r\nThere is also no skipping ahead.  You have to go from 8.2 to 8.3, you can\'t jump over 8.2, you have to upgrade to 8.2 first if you aren\'t already there.\r\n\r\n&nbsp;\r\n\r\nThere are a lot of changes to the code, but none as noticeable as the new NAT statements.\r\n\r\n&nbsp;\r\n\r\nAnother big reminder is to disable nat-control BEFORE you perform the upgrade.  This is the feature that made it so that you had to configure NAT statements between the different interfaces.\r\n\r\n&nbsp;\r\n\r\nBelow is a chart comparing the configuration steps from 8.2 to 8.3 for NAT statements.\r\n\r\n&nbsp;\r\n<table cellspacing=\"0\" cellpadding=\"0\">\r\n<tbody>\r\n<tr>\r\n<td valign=\"middle\"><strong>NAT Feature</strong>&nbsp;</td>\r\n<td valign=\"middle\"><strong>pre-8.3 Configuration</strong>&nbsp;</td>\r\n<td valign=\"middle\"><strong>8.3 Configuration</strong>&nbsp;</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Static NAT</td>\r\n<td valign=\"middle\">static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255</td>\r\n<td valign=\"middle\"><strong>Option 1 (Preferred)</strong>object network obj-10.1.1.6\r\n\r\nhost 10.1.1.6\r\n\r\nnat (inside,outside) static 209.165.201.15\r\n\r\n&nbsp;\r\n\r\n<strong>Option 2\r\n</strong>\r\n\r\nobject network server_real\r\n\r\nhost 10.1.1.6\r\n\r\nobject network server_global\r\n\r\nhost 209.165.201.15\r\n\r\n!\r\n\r\nnat (inside,outside) source static server_real server_global</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Dynamic PAT</td>\r\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0&nbsp;\r\n\r\nglobal (outside) 1 209.165.201.254</td>\r\n<td valign=\"middle\">object network internal_netsubnet 10.1.1.0 255.255.255.0\r\n\r\n!\r\n\r\nobject network internal_net\r\n\r\n&nbsp;\r\n\r\nnat (inside,outside) dynamic 209.165.201.254</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Dynamic NAT with Interface Overload</td>\r\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0&nbsp;\r\n\r\nglobal (outside) 1 interface\r\n\r\n&nbsp;\r\n\r\nglobal (outside) 1 209.165.201.1-209.165.201.2</td>\r\n<td valign=\"middle\">object network NAT_Poolrange 209.165.201.2 209.165.201.50\r\n\r\nobject network internal_net\r\n\r\nsubnet 10.1.1.0 255.255.255.0\r\n\r\n!\r\n\r\nobject network internal_net\r\n\r\nnat (inside,outside) dynamic NAT_Pool interface</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nThe next big one is ACLs (Access Control Lists).  The command syntax hasn\'t changed much for these, just the IP that is used for the rule.\r\n\r\n&nbsp;\r\n\r\nIn the past when you were allowing traffic to a server you would configure it to point to the public IP that the server was NAT\'d to.  Now it is configured to the internal address.  For example....\r\n\r\n&nbsp;\r\n\r\nBelow is the way you would normally configure an ACL\r\n\r\n&nbsp;\r\n\r\nstatic (inside,outside) 208.268.11.17 10.100.1.11 netmask 255.255.255.255\r\n\r\n!\r\n\r\naccess-list outside_in extended permit tcp any host 208.268.11.17\r\n\r\naccess-group outside_in in interface outside\r\n\r\n&nbsp;\r\n\r\nWith 8.3 you use network objects, like below.\r\n\r\n&nbsp;\r\n\r\nobject network obj-10.100.1.11\r\n\r\nhost 10.100.1.11\r\n\r\nnat (inside,outside) static 208.268.11.17\r\n\r\n!\r\n\r\naccess-list outside_in extended permit tcp any host 10.100.1.11\r\n\r\naccess-group outside_in in interface outside\r\n\r\n&nbsp;\r\n\r\nYou can see the difference.\r\n\r\n&nbsp;\r\n\r\nThe big caveat with the upgrade is that the process is supposed to make the adjustments automatically.  I have found that is not always the case.  All the static NATs tend to need some tweaking, as well as a lot of the Access Rules.\r\n\r\n&nbsp;\r\n\r\nBest bet is to make sure that you have a good understanding of the changes before diving into the upgrade.\r\n\r\n&nbsp;\r\n\r\nThanks to <a title=\"Cisco Support Forums\" href=\"https://supportforums.cisco.com/docs/DOC-12690\" target=\"_blank\">Cisco Support Forums</a> for the information.','Cisco ASA 8.3 Upgrade - Lessons Learned','','inherit','open','open','','5176-revision-4','','','2011-09-29 20:13:44','2011-09-29 20:13:44','',5176,'http://egroup.jasonmangone.com/5176-revision-4',0,'revision','',0),(5240,44,'2011-09-29 17:40:01','2011-09-29 17:40:01','<img title=\"Avamar Icon\" src=\"http://www.vmware.com/appliances/directory/uploaded_files/EMCAvamar/avamar%20icon.png\" alt=\"\" width=\"69\" height=\"68\" />An Avamar NDMP Accelerator node is an awesome way to connect your CIFS or NFS shares to one of the best backup solutions on the market today.\r\n\r\nWith Avamars powerful de-duplication technology coupled with the offloading capabilities of the NDMP accelerator to enable you to pass the data on the an EMC Celerra or NetApp solution through to the Avamar grid for efficient backup of these files.\r\n\r\nImportant note, though....With the NDMP backup solution, there must be some head room in the pool for the backup caching.  20GB is the minimum, but it could be more than that if the pool is really large.\r\n\r\nThe benefits fair out weigh the small size requirement for the backup.  And with Avamar the files are broken down into sub-file level pieces that are de-duplicated at at that level.  Resulting in an awesome ability to take files that are different and only backup the parts of the file that are different.\r\n\r\nFor example....\r\n\r\nIf a file template was used to create a document (say doc1.docx) and the that same template was used for another document (doc2.docx), when those files are backed up, traditionally, both full files would be backed up with no de-duplication since they are different files.  With Avamar, it breaks those two files down and only backs up the parts that are different.  So, you still get a portion of de-duplication on the file even though they are different.\r\n\r\nEfficient and awesome','Avamar and NDMP','','inherit','open','open','','5165-revision-3','','','2011-09-29 17:40:01','2011-09-29 17:40:01','',5165,'http://egroup.jasonmangone.com/5165-revision-3',0,'revision','',0),(5181,44,'2011-09-30 19:43:54','2011-09-30 19:43:54','Many times this has been a sticking point for ASA code upgrades, but the time is coming where the 8.3 code update is going to be a requirement (as I have found with the AIP modules).\n\n&nbsp;\n\nHUGE reminder that the upgrade from 8.2 to 8.3 is not an easy or simple upgrade.\n\n&nbsp;\n\nThere is also no skipping ahead.  You have to go from 8.2 to 8.3, you can\'t jump over 8.2, you have to upgrade to 8.2 first if you aren\'t already there.\n\n&nbsp;\n\nThere are a lot of changes to the code, but none as noticeable as the new NAT statements.\n\n&nbsp;\n\nAnother big reminder is to disable nat-control BEFORE you perform the upgrade.  This is the feature that made it so that you had to configure NAT statements between the different interfaces.\n\n&nbsp;\n\nBelow is a chart comparing the configuration steps from 8.2 to 8.3 for NAT statements.\n\n&nbsp;\n<table cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td valign=\"middle\"><strong>NAT Feature</strong></td>\n<td valign=\"middle\"><strong>pre-8.3 Configuration</strong></td>\n<td valign=\"middle\"><strong>8.3 Configuration</strong></td>\n</tr>\n<tr>\n<td valign=\"middle\">Static NAT</td>\n<td valign=\"middle\">static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255</td>\n<td valign=\"middle\"><strong>Option 1 (Preferred)</strong>object network obj-10.1.1.6host 10.1.1.6nat (inside,outside) static 209.165.201.15\n\n&nbsp;\n\n<strong>Option 2\n</strong>\n\nobject network server_real\n\nhost 10.1.1.6\n\nobject network server_global\n\nhost 209.165.201.15\n\n!\n\nnat (inside,outside) source static server_real server_global</td>\n</tr>\n<tr>\n<td valign=\"middle\">Dynamic PAT</td>\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0global (outside) 1 209.165.201.254</td>\n<td valign=\"middle\">object network internal_netsubnet 10.1.1.0 255.255.255.0!object network internal_net\n\n&nbsp;\n\nnat (inside,outside) dynamic 209.165.201.254</td>\n</tr>\n<tr>\n<td valign=\"middle\">Dynamic NAT with Interface Overload</td>\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0global (outside) 1 interface&nbsp;\n\nglobal (outside) 1 209.165.201.1-209.165.201.2</td>\n<td valign=\"middle\">object network NAT_Poolrange 209.165.201.2 209.165.201.50object network internal_netsubnet 10.1.1.0 255.255.255.0\n\n!\n\nobject network internal_net\n\nnat (inside,outside) dynamic NAT_Pool interface</td>\n</tr>\n</tbody>\n</table>\n&nbsp;\n\n<!--more-->\n\nThe next big one is ACLs (Access Control Lists).  The command syntax hasn\'t changed much for these, just the IP that is used for the rule.\n\n&nbsp;\n\nIn the past when you were allowing traffic to a server you would configure it to point to the public IP that the server was NAT\'d to.  Now it is configured to the internal address.  For example....\n\n&nbsp;\n\nBelow is the way you would normally configure an ACL\n\n&nbsp;\n\nstatic (inside,outside) 208.268.11.17 10.100.1.11 netmask 255.255.255.255\n\n!\n\naccess-list outside_in extended permit tcp any host 208.268.11.17\n\naccess-group outside_in in interface outside\n\n&nbsp;\n\nWith 8.3 you use network objects, like below.\n\n&nbsp;\n\nobject network obj-10.100.1.11\n\nhost 10.100.1.11\n\nnat (inside,outside) static 208.268.11.17\n\n!\n\naccess-list outside_in extended permit tcp any host 10.100.1.11\n\naccess-group outside_in in interface outside\n\n&nbsp;\n\nYou can see the difference.\n\n&nbsp;\n\nThe big caveat with the upgrade is that the process is supposed to make the adjustments automatically.  I have found that is not always the case.  All the static NATs tend to need some tweaking, as well as a lot of the Access Rules.\n\n&nbsp;\n\nBest bet is to make sure that you have a good understanding of the changes before diving into the upgrade.\n\n&nbsp;\n\nThanks to <a title=\"Cisco Support Forums\" href=\"https://supportforums.cisco.com/docs/DOC-12690\" target=\"_blank\">Cisco Support Forums</a> for the information.','Cisco ASA 8.3 Upgrade - Lessons Learned','','inherit','open','open','','5176-autosave','','','2011-09-30 19:43:54','2011-09-30 19:43:54','',5176,'http://egroup.jasonmangone.com/5176-autosave',0,'revision','',0),(5182,12,'2011-09-29 19:03:06','2011-09-29 19:03:06','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\n\nSo here it goes!\n\nIt\'s important to understand the goal-- to minimize the amount of horsepower and cost needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage. And this is absolutely acceptable, and a STRONG/SOLID storage environment is still critically important here and in all other virtualized environments. But again, the goal is to minimize the amount of horsepower and cost to support this particular deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which does operate similarly but specifically for bandwidth and end user experience optimization). This technology leverages the LOCAL drives in a XenServer host itself to help \"offload\" disk operations. Once the first virtual machine boots and begins to read against the master image, XenServer caches the master image data on the local disks configured for Intellicache, and future reads to the image are then satisfied locally, which tremendously reduces the IOPS load against your shared storage array. It also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3.\n\n&nbsp;','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-6','','','2011-09-29 19:03:06','2011-09-29 19:03:06','',5163,'http://egroup.jasonmangone.com/5163-revision-6',0,'revision','',0),(5183,12,'2011-09-29 23:23:09','2011-09-29 23:23:09','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution. One thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP PROCESS','','inherit','open','open','','5155-revision-4','','','2011-09-29 23:23:09','2011-09-29 23:23:09','',5155,'http://egroup.jasonmangone.com/5155-revision-4',0,'revision','',0),(5184,12,'2011-09-29 23:26:56','2011-09-29 23:26:56','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\n\nHere are the different / common types of data deduplication found in the marketplace today.\n\n&nbsp;\n\nEMC Avamar uses variable block length deduplication, compression, and hashing to achieve the incredibly high levels of efficiency we see customers happily enjoying every day.\n\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-5','','','2011-09-29 23:26:56','2011-09-29 23:26:56','',5155,'http://egroup.jasonmangone.com/5155-revision-5',0,'revision','',0),(5191,12,'2011-09-29 23:31:57','2011-09-29 23:31:57','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\nVariable block level (what Avamar uses)\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-12','','','2011-09-29 23:31:57','2011-09-29 23:31:57','',5155,'http://egroup.jasonmangone.com/5155-revision-12',0,'revision','',0),(5188,12,'2011-09-29 23:29:59','2011-09-29 23:29:59','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\nFile-level (the most common)\r\n<ul>\r\n	<li>File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.</li>\r\n	<li>If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.</li>\r\n</ul>\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\nFixed Block Level (also called fixed length)\r\n<ul>\r\n	<li>Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated</li>\r\n</ul>\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\nVariable block level (what Avamar uses)\r\n<ul>\r\n	<li>• This uses an intelligent method to determine segment size based on the data itself to determine length size.</li>\r\n	<li>• Provides much greater granularity in finding duplicate data</li>\r\n</ul>\r\n&nbsp;\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is a X type of file, so I’m going to break it into these variable segments”.\r\n\r\n&nbsp;\r\n\r\nThis provides the greatest level of deduplication.\r\n\r\nEMC Avamar uses variable block length deduplication, compression, and hashing to achieve the incredibly high levels of efficiency we see customers happily enjoying every day.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-9','','','2011-09-29 23:29:59','2011-09-29 23:29:59','',5155,'http://egroup.jasonmangone.com/5155-revision-9',0,'revision','',0),(5185,12,'2011-09-29 23:27:56','2011-09-29 23:27:56','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\n\nHere are the different / common types of data deduplication found in the marketplace today.\n\nFile-level – The most common\n<ul>\n	<li>• File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.</li>\n	<li>• If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.</li>\n</ul>\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good and simple for environments with TB of storage and users that tend to share data between them, using multiple copies instead of referencing a single file in a shared location.\n\nOur customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\nFixed Block Level (also called fixed length)\n<ul>\n	<li>• Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated</li>\n</ul>\nIf you have two files that break down into the following bits, the RED sections would be de-duplicated.\n\n&nbsp;\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001\n\n<span style=\"color: #ff0000\">1111</span> 1110 0000\n\n&nbsp;\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\n\n&nbsp;\n\nVariable block level (what Avamar uses)\n<ul>\n	<li>• This uses an intelligent method to determine segment size based on the data itself to determine length size.</li>\n	<li>• Provides much greater granularity in finding duplicate data</li>\n</ul>\n&nbsp;\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is a X type of file, so I’m going to break it into these variable segments”.\n\n&nbsp;\n\nThis provides the greatest level of deduplication.\n\nEMC Avamar uses variable block length deduplication, compression, and hashing to achieve the incredibly high levels of efficiency we see customers happily enjoying every day.\n\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-6','','','2011-09-29 23:27:56','2011-09-29 23:27:56','',5155,'http://egroup.jasonmangone.com/5155-revision-6',0,'revision','',0),(5186,12,'2011-09-29 23:29:11','2011-09-29 23:29:11','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\nFile-level (the most common)\r\n<ul>\r\n	<li>File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.</li>\r\n	<li>If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.</li>\r\n</ul>\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\nFixed Block Level (also called fixed length)\r\n<ul>\r\n	<li>Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated</li>\r\n</ul>\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\n&nbsp;\r\n\r\nVariable block level (what Avamar uses)\r\n<ul>\r\n	<li>• This uses an intelligent method to determine segment size based on the data itself to determine length size.</li>\r\n	<li>• Provides much greater granularity in finding duplicate data</li>\r\n</ul>\r\n&nbsp;\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is a X type of file, so I’m going to break it into these variable segments”.\r\n\r\n&nbsp;\r\n\r\nThis provides the greatest level of deduplication.\r\n\r\nEMC Avamar uses variable block length deduplication, compression, and hashing to achieve the incredibly high levels of efficiency we see customers happily enjoying every day.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-7','','','2011-09-29 23:29:11','2011-09-29 23:29:11','',5155,'http://egroup.jasonmangone.com/5155-revision-7',0,'revision','',0),(5187,12,'2011-09-29 23:29:35','2011-09-29 23:29:35','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\nFile-level (the most common)\r\n<ul>\r\n	<li>File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.</li>\r\n	<li>If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.</li>\r\n</ul>\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\nFixed Block Level (also called fixed length)\r\n<ul>\r\n	<li>Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated</li>\r\n</ul>\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\n&nbsp;\r\n\r\nVariable block level (what Avamar uses)\r\n<ul>\r\n	<li>• This uses an intelligent method to determine segment size based on the data itself to determine length size.</li>\r\n	<li>• Provides much greater granularity in finding duplicate data</li>\r\n</ul>\r\n&nbsp;\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is a X type of file, so I’m going to break it into these variable segments”.\r\n\r\n&nbsp;\r\n\r\nThis provides the greatest level of deduplication.\r\n\r\nEMC Avamar uses variable block length deduplication, compression, and hashing to achieve the incredibly high levels of efficiency we see customers happily enjoying every day.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-8','','','2011-09-29 23:29:35','2011-09-29 23:29:35','',5155,'http://egroup.jasonmangone.com/5155-revision-8',0,'revision','',0),(5189,12,'2011-09-29 23:30:36','2011-09-29 23:30:36','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\nFile-level (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\nFixed Block Level (also called fixed length)\r\n<ul>\r\n	<li>Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated</li>\r\n</ul>\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\nVariable block level (what Avamar uses)\r\n<ul>\r\n	<li>• This uses an intelligent method to determine segment size based on the data itself to determine length size.</li>\r\n	<li>• Provides much greater granularity in finding duplicate data</li>\r\n</ul>\r\n&nbsp;\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is a X type of file, so I’m going to break it into these variable segments”.\r\n\r\n&nbsp;\r\n\r\nThis provides the greatest level of deduplication.\r\n\r\nEMC Avamar uses variable block length deduplication, compression, and hashing to achieve the incredibly high levels of efficiency we see customers happily enjoying every day.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-10','','','2011-09-29 23:30:36','2011-09-29 23:30:36','',5155,'http://egroup.jasonmangone.com/5155-revision-10',0,'revision','',0),(5190,12,'2011-09-29 23:30:47','2011-09-29 23:30:47','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\nFixed Block Level (also called fixed length)\r\n<ul>\r\n	<li>Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated</li>\r\n</ul>\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\nVariable block level (what Avamar uses)\r\n<ul>\r\n	<li>• This uses an intelligent method to determine segment size based on the data itself to determine length size.</li>\r\n	<li>• Provides much greater granularity in finding duplicate data</li>\r\n</ul>\r\n&nbsp;\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is a X type of file, so I’m going to break it into these variable segments”.\r\n\r\n&nbsp;\r\n\r\nThis provides the greatest level of deduplication.\r\n\r\nEMC Avamar uses variable block length deduplication, compression, and hashing to achieve the incredibly high levels of efficiency we see customers happily enjoying every day.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-11','','','2011-09-29 23:30:47','2011-09-29 23:30:47','',5155,'http://egroup.jasonmangone.com/5155-revision-11',0,'revision','',0),(5192,12,'2011-09-29 23:32:00','2011-09-29 23:32:00','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\nVariable block level (what Avamar uses)\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-13','','','2011-09-29 23:32:00','2011-09-29 23:32:00','',5155,'http://egroup.jasonmangone.com/5155-revision-13',0,'revision','',0),(5193,12,'2011-09-29 23:32:33','2011-09-29 23:32:33','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-14','','','2011-09-29 23:32:33','2011-09-29 23:32:33','',5155,'http://egroup.jasonmangone.com/5155-revision-14',0,'revision','',0),(5194,12,'2011-09-29 23:33:16','2011-09-29 23:33:16','See my video below which outlines a high level overview of the backup process and how the variable segment length, source and global deduplication works in an EMC Avamar solution.\r\n\r\nHere are the different / common types of data deduplication found in the marketplace today.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-15','','','2011-09-29 23:33:16','2011-09-29 23:33:16','',5155,'http://egroup.jasonmangone.com/5155-revision-15',0,'revision','',0),(5195,12,'2011-09-30 00:18:03','2011-09-30 00:18:03','Here are the different / common types of data deduplication found in the marketplace today.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data in the future, this file is loaded in RAM, and each file is then hashed, and compared to the hashes in the\n\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-16','','','2011-09-30 00:18:03','2011-09-30 00:18:03','',5155,'http://egroup.jasonmangone.com/5155-revision-16',0,'revision','',0),(5196,12,'2011-09-30 11:50:46','2011-09-30 11:50:46','To understand how Here are the different / common types of data deduplication found in the marketplace today.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data in the future, this file is loaded in RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is process. Because this is done in memory, it happens VERY quickly.\n\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-17','','','2011-09-30 11:50:46','2011-09-30 11:50:46','',5155,'http://egroup.jasonmangone.com/5155-revision-17',0,'revision','',0),(5197,12,'2011-09-30 11:52:35','2011-09-30 11:52:35','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data in the future, this file is loaded in RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is process. Because this is done in memory, it happens VERY quickly.\n\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-18','','','2011-09-30 11:52:35','2011-09-30 11:52:35','',5155,'http://egroup.jasonmangone.com/5155-revision-18',0,'revision','',0),(5198,12,'2011-09-30 11:58:22','2011-09-30 11:58:22','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data in the future, this file is loaded in RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is process. Because this is done in memory, it happens VERY quickly.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-19','','','2011-09-30 11:58:22','2011-09-30 11:58:22','',5155,'http://egroup.jasonmangone.com/5155-revision-19',0,'revision','',0),(5199,12,'2011-09-30 11:59:45','2011-09-30 11:59:45','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data in the future, this file is loaded in RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-20','','','2011-09-30 11:59:45','2011-09-30 11:59:45','',5155,'http://egroup.jasonmangone.com/5155-revision-20',0,'revision','',0),(5200,12,'2011-09-30 11:59:49','2011-09-30 11:59:49','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data in the future, this file is loaded in RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nOne thing I forgot to mention in the video is when the process gets to the point where it checks to see if the hash of the data exists on the Avamar server (step 6), this is the \"global\" part of the global deduplication magic that is EMC Avamar.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-21','','','2011-09-30 11:59:49','2011-09-30 11:59:49','',5155,'http://egroup.jasonmangone.com/5155-revision-21',0,'revision','',0),(5201,12,'2011-09-30 12:14:42','2011-09-30 12:14:42','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\n\nNote: Most of the following process all happens on the CLIENT itself, which is where \"source dedupe\" ha\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-22','','','2011-09-30 12:14:42','2011-09-30 12:14:42','',5155,'http://egroup.jasonmangone.com/5155-revision-22',0,'revision','',0),(5202,12,'2011-09-30 12:16:01','2011-09-30 12:16:01','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\n\nNote: Most of the following process all happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-23','','','2011-09-30 12:16:01','2011-09-30 12:16:01','',5155,'http://egroup.jasonmangone.com/5155-revision-23',0,'revision','',0),(5203,12,'2011-09-30 12:16:46','2011-09-30 12:16:46','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nNote: Most of the following process all happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-24','','','2011-09-30 12:16:46','2011-09-30 12:16:46','',5155,'http://egroup.jasonmangone.com/5155-revision-24',0,'revision','',0),(5204,12,'2011-09-30 12:17:14','2011-09-30 12:17:14','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nNote: Most of the following process all happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-25','','','2011-09-30 12:17:14','2011-09-30 12:17:14','',5155,'http://egroup.jasonmangone.com/5155-revision-25',0,'revision','',0),(5205,12,'2011-09-30 12:18:16','2011-09-30 12:18:16','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - OVERVIEW OF BACKUP/DEDUPE PROCESS','','inherit','open','open','','5155-revision-26','','','2011-09-30 12:18:16','2011-09-30 12:18:16','',5155,'http://egroup.jasonmangone.com/5155-revision-26',0,'revision','',0),(5208,12,'2011-09-30 12:32:53','2011-09-30 12:32:53','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE WORKS','','inherit','open','open','','5155-revision-29','','','2011-09-30 12:32:53','2011-09-30 12:32:53','',5155,'http://egroup.jasonmangone.com/5155-revision-29',0,'revision','',0),(5206,12,'2011-09-30 12:29:17','2011-09-30 12:29:17','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE WORKS','','inherit','open','open','','5155-revision-27','','','2011-09-30 12:29:17','2011-09-30 12:29:17','',5155,'http://egroup.jasonmangone.com/5155-revision-27',0,'revision','',0),(5207,12,'2011-09-30 12:29:26','2011-09-30 12:29:26','To understand how dedupe works in an EMC Avamar server, you must first understand the types of data deduplication methods commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE WORKS','','inherit','open','open','','5155-revision-28','','','2011-09-30 12:29:26','2011-09-30 12:29:26','',5155,'http://egroup.jasonmangone.com/5155-revision-28',0,'revision','',0),(5210,12,'2011-09-30 12:34:45','2011-09-30 12:34:45','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE WORKS','','inherit','open','open','','5155-revision-31','','','2011-09-30 12:34:45','2011-09-30 12:34:45','',5155,'http://egroup.jasonmangone.com/5155-revision-31',0,'revision','',0),(5209,12,'2011-09-30 12:33:12','2011-09-30 12:33:12','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is then hashed, and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will then take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE WORKS','','inherit','open','open','','5155-revision-30','','','2011-09-30 12:33:12','2011-09-30 12:33:12','',5155,'http://egroup.jasonmangone.com/5155-revision-30',0,'revision','',0),(5211,12,'2011-09-30 12:35:34','2011-09-30 12:35:34','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens.\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE WORKS','','inherit','open','open','','5155-revision-32','','','2011-09-30 12:35:34','2011-09-30 12:35:34','',5155,'http://egroup.jasonmangone.com/5155-revision-32',0,'revision','',0),(5212,12,'2011-09-30 12:37:28','2011-09-30 12:37:28','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE WORKS','','inherit','open','open','','5155-revision-33','','','2011-09-30 12:37:28','2011-09-30 12:37:28','',5155,'http://egroup.jasonmangone.com/5155-revision-33',0,'revision','',0),(5213,12,'2011-09-13 23:45:29','2011-09-13 23:45:29','Having put in several Avamar solutions in the past few months, I wanted to share some comments and statistics from real customer environments that are now happily globally (and source) de-duplicating their backups with EMC Avamar.\r\n\r\nBelow are comments from our most recent Avamar victory.\r\n\r\n\"At this point I have calculated an approximate 72% de-duplication rate for all servers. Our backup windows for daily backups has shrunk from 8 hours to 1.5 hours. <strong>Our weekend backup has shrunk from 48 hours to 1.5 hours.</strong> \"\r\n\r\n48 hours to 1.5 hours. That\'s kind of a big deal. Going from almost NOT getting the backups completed over the weekend, to getting them done before kickoff of the early Saturday game. Makes for a relaxing football season.\r\n\r\nBelow is a screenshot from a different customer environment running Avamar. I cut off their client names to protect the innocent.\r\n\r\nThe \"on demand backup\" jobs in the screenshot were first time backups that had the benefit of global de-duplication. Only a small percentage of their data was NOT already on the Avamar grid from another client, so Avamar did not need to send that duplicate data (that\'s the GLOBAL de-dupe action).\r\n\r\nA good example to illustrate what this means: Consider the Operating System files in the following scenario. Client A runs Server 2008 R2 and has already been backed up. Client B also runs Server 2008 R2. Same OS.\r\n\r\nThe initial backup for Client B will NOT send any duplicate OS files over the network to be backed up, because the data is already on the Avamar grid (that\'s what duplicate means, right?).  In the event that a restore is needed, Avamar knows how to get that data out and back to the client. It\'s like magic. And it\'s all done with variable length data segments; not at an entire file level, and not with a fixed block size.\r\n\r\nCheck out that 971.5GB backup that completed (and REALLY completed, not that \"Completed with exceptions\" nonsense) in 2 hours. That\'s almost 500GB an hour.\r\n\r\nAh, the power of Avamar. Can your backup system do that?\r\n\r\n<img class=\"aligncenter\" src=\"http://img823.imageshack.us/img823/8791/avamarsnap.png\" alt=\"\" width=\"384\" height=\"301\" />','EMC Avamar - CUSTOMER SUCCESS','','inherit','open','open','','5019-revision-16','','','2011-09-13 23:45:29','2011-09-13 23:45:29','',5019,'http://egroup.jasonmangone.com/5019-revision-16',0,'revision','',0),(5214,12,'2011-09-30 12:41:56','2011-09-30 12:41:56','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up. If Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE WORKS','','inherit','open','open','','5155-revision-34','','','2011-09-30 12:41:56','2011-09-30 12:41:56','',5155,'http://egroup.jasonmangone.com/5155-revision-34',0,'revision','',0),(5215,12,'2011-09-30 12:42:56','2011-09-30 12:42:56','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\n\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-35','','','2011-09-30 12:42:56','2011-09-30 12:42:56','',5155,'http://egroup.jasonmangone.com/5155-revision-35',0,'revision','',0);
INSERT INTO `wp_posts` VALUES (5216,12,'2011-09-30 12:47:27','2011-09-30 12:47:27','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-36','','','2011-09-30 12:47:27','2011-09-30 12:47:27','',5155,'http://egroup.jasonmangone.com/5155-revision-36',0,'revision','',0),(5217,2,'2011-09-26 14:13:40','2011-09-26 14:13:40','Contacts\r\n\r\nScott Regan\r\nEverything Channel\r\n<a href=\"mailto:scott.regan@ec.ubm.com\">scott.regan@ec.ubm.com</a>\r\n508.416.1186\r\n\r\nLiz Wilmes\r\neGroup, Inc.\r\n<a href=\"mailto:Elizabeth.Wilmes@eGroup-us.com\">Elizabeth.Wilmes@eGroup-us.com</a>\r\n843.284.0146\r\n\r\n<strong>eGroup, Inc. Recognized on the CRN Fast Growth 100 List</strong>\r\n\r\nMount Pleasant, SC, September 26, 2011 – eGroup, Inc., providing technology solutions for Serious Competitors, today announced that it has been recognized by Everything Channel on the CRN Fast Growth 100 list. The list recognizes the fastest growing solution providers in North America. Companies on the Fast Growth 100 list average a two-year revenue growth of 130 percent and average annual sales of products and services of $172 million. The ranking is based on two years’ growth of net sales from calendar year 2008 to calendar year 2010.\r\n\r\n\"We are thrilled to be recognized for our growth over the past several years,\" said eGroup Principal Mike Carter. \"Our goal is to continue to deliver exceptional customer service while helping our clients understand that technology is a competitive advantage for their business. This is a proven methodology that generates sustained growth for both eGroup and our customers, and we could not be more pleased with the outcome.\"\r\n\r\n“This year’s Fast Growth 100 list reflects the high growth potential for solution providers offering innovative products, solutions and services,” said Kelley Damore, Vice President and Editorial Director for Everything Channel. “Despite an uncertain market, VARs investing in new technologies and services are still growing at a significant rate - a testament to their hard work and ability to truly understand their customers\' needs. We congratulate eGroup on their well-earned success.”\r\n\r\nA sample of the 2011 Fast Growth list can be found at <a href=\"http://www.crn.com\">www.crn.com</a>. <!--more-->\r\n\r\n<strong>CRN 2011 Fast Growth Conference &amp; Awards\r\n</strong><em>Achieving Superior Growth in Uncertain Times</em>\r\n\r\nThe 2011 CRN Fast Growth category and special awards will be presented during the annual conference, taking place October 5-6 at the Doral Resort in Miami. At the event, relationships will be formed and business opportunities will take place as channel executives gather together in an intimate setting with North America’s fastest growing solution providers. The event will honor leading-edge solution providers who are setting the agenda in today\'s channel. To learn more about the event, go to <a href=\"http://everythingchannelevents.com/crnfg_11\">http://everythingchannelevents.com/crnfg_11</a>\r\n\r\n<strong>About eGroup</strong>\r\n\r\nProviding customers across the southeast with a distinct competitive advantage since 1999, eGroup is a visionary technology solutions and services firm with the ability to execute swiftly in a rapidly changing information technology landscape. eGroup’s solutions drive customers’ cost containment, revenue growth, and service objectives by addressing challenges associated with mobility, access to critical applications and data, and security. eGroup’s expertise and core competency is focused in three distinct areas: Cloud Services (public and private), Application Services, and End-User Computing. To deliver these solutions, eGroup has strategic partnerships with industry leaders that include VMware, Cisco, and EMC, along with Citrix, Microsoft, and Trend Micro, and a highly-skilled workforce trained in all of the latest developments in information technology. To learn more, visit <a href=\"http://www.eGroup-us.com\">www.eGroup-us.com</a>.\r\n\r\n<strong>About Everything Channel</strong>\r\n\r\nEverything Channel is the premier provider of IT channel-focused events, media, research, consulting, and sales and marketing services. With over 30 years of experience and engagement, Everything Channel has the unmatched channel expertise to execute integrated solutions for technology executives managing partner recruitment, enablement and go-to-market strategy in order to accelerate technology sales. Everything Channel is a UBM company.\r\n\r\nTo learn more about Everything Channel, visit us at <a href=\"http://www.everythingchannel.com/\">http://www.everythingchannel.com</a>. Follow us on Twitter at <a href=\"http://twitter.com/everythingchnl\">http://twitter.com/everythingchnl</a>.\r\n\r\n<strong>About UBM plc</strong>\r\n\r\nUBM plc is a leading global business media company. We inform markets and bring the world’s buyers and sellers together at events, online, in print and provide them with the information they need to do business successfully. We focus on serving professional commercial communities, from doctors to game developers, from journalists to jewellery traders, from farmers to pharmacists around the world. Our 6,000 staff in more than 30 countries are organised into specialist teams that serve these communities, helping them to do business and their markets to work effectively and efficiently.\r\n\r\nFor more information, go to <a href=\"http://www.ubm.com\">www.ubm.com</a>\r\n\r\n###','eGROUP NAMED TO CRN FAST GROWTH 100 LIST','','inherit','open','open','','4994-revision-5','','','2011-09-26 14:13:40','2011-09-26 14:13:40','',4994,'http://egroup.jasonmangone.com/4994-revision-5',0,'revision','',0),(5218,2,'2011-09-30 13:33:37','2011-09-30 13:33:37','Contacts\r\n\r\nScott Regan\r\nEverything Channel\r\n<a href=\"mailto:scott.regan@ec.ubm.com\">scott.regan@ec.ubm.com</a>\r\n508.416.1186\r\n\r\nLiz Wilmes\r\neGroup, Inc.\r\n<a href=\"mailto:Elizabeth.Wilmes@eGroup-us.com\">Elizabeth.Wilmes@eGroup-us.com</a>\r\n843.284.0146\r\n\r\n<strong>eGroup, Inc. Only SC-Based Company Recognized on the CRN Fast Growth 100 List</strong>\r\n\r\nMount Pleasant, SC, September 26, 2011 – eGroup, Inc., providing technology solutions for Serious Competitors, today announced that it has been recognized by Everything Channel on the CRN Fast Growth 100 list. The list recognizes the fastest growing solution providers in North America. Companies on the Fast Growth 100 list average a two-year revenue growth of 130 percent and average annual sales of products and services of $172 million. The ranking is based on two years’ growth of net sales from calendar year 2008 to calendar year 2010.  eGroup was the only South Carolina based company to make this elite list.\r\n\r\n\"We are thrilled to be recognized for our growth over the past several years,\" said eGroup Principal Mike Carter. \"Our goal is to continue to deliver exceptional customer service while helping our clients understand that technology is a competitive advantage for their business. This is a proven methodology that generates sustained growth for both eGroup and our customers, and we could not be more pleased with the outcome.\"\r\n\r\n“This year’s Fast Growth 100 list reflects the high growth potential for solution providers offering innovative products, solutions and services,” said Kelley Damore, Vice President and Editorial Director for Everything Channel. “Despite an uncertain market, VARs investing in new technologies and services are still growing at a significant rate - a testament to their hard work and ability to truly understand their customers\' needs. We congratulate eGroup on their well-earned success.”\r\n\r\nA sample of the 2011 Fast Growth list can be found at <a href=\"http://www.crn.com\">www.crn.com</a>. <!--more-->\r\n\r\n<strong>CRN 2011 Fast Growth Conference &amp; Awards\r\n</strong><em>Achieving Superior Growth in Uncertain Times</em>\r\n\r\nThe 2011 CRN Fast Growth category and special awards will be presented during the annual conference, taking place October 5-6 at the Doral Resort in Miami. At the event, relationships will be formed and business opportunities will take place as channel executives gather together in an intimate setting with North America’s fastest growing solution providers. The event will honor leading-edge solution providers who are setting the agenda in today\'s channel. To learn more about the event, go to <a href=\"http://everythingchannelevents.com/crnfg_11\">http://everythingchannelevents.com/crnfg_11</a>\r\n\r\n<strong>About eGroup</strong>\r\n\r\nProviding customers across the southeast with a distinct competitive advantage since 1999, eGroup is a visionary technology solutions and services firm with the ability to execute swiftly in a rapidly changing information technology landscape. eGroup’s solutions drive customers’ cost containment, revenue growth, and service objectives by addressing challenges associated with mobility, access to critical applications and data, and security. eGroup’s expertise and core competency is focused in three distinct areas: Cloud Services (public and private), Application Services, and End-User Computing. To deliver these solutions, eGroup has strategic partnerships with industry leaders that include VMware, Cisco, and EMC, along with Citrix, Microsoft, and Trend Micro, and a highly-skilled workforce trained in all of the latest developments in information technology. To learn more, visit <a href=\"http://www.eGroup-us.com\">www.eGroup-us.com</a>.\r\n\r\n<strong>About Everything Channel</strong>\r\n\r\nEverything Channel is the premier provider of IT channel-focused events, media, research, consulting, and sales and marketing services. With over 30 years of experience and engagement, Everything Channel has the unmatched channel expertise to execute integrated solutions for technology executives managing partner recruitment, enablement and go-to-market strategy in order to accelerate technology sales. Everything Channel is a UBM company.\r\n\r\nTo learn more about Everything Channel, visit us at <a href=\"http://www.everythingchannel.com/\">http://www.everythingchannel.com</a>. Follow us on Twitter at <a href=\"http://twitter.com/everythingchnl\">http://twitter.com/everythingchnl</a>.\r\n\r\n<strong>About UBM plc</strong>\r\n\r\nUBM plc is a leading global business media company. We inform markets and bring the world’s buyers and sellers together at events, online, in print and provide them with the information they need to do business successfully. We focus on serving professional commercial communities, from doctors to game developers, from journalists to jewellery traders, from farmers to pharmacists around the world. Our 6,000 staff in more than 30 countries are organised into specialist teams that serve these communities, helping them to do business and their markets to work effectively and efficiently.\r\n\r\nFor more information, go to <a href=\"http://www.ubm.com\">www.ubm.com</a>\r\n\r\n###','eGROUP ONLY SOUTH CAROLINA BASED COMPANY NAMED TO CRN FAST GROWTH 100 LIST','','inherit','open','open','','4994-revision-6','','','2011-09-30 13:33:37','2011-09-30 13:33:37','',4994,'http://egroup.jasonmangone.com/4994-revision-6',0,'revision','',0),(5219,2,'2011-09-30 13:36:32','2011-09-30 13:36:32','Contacts\r\n\r\nScott Regan\r\nEverything Channel\r\n<a href=\"mailto:scott.regan@ec.ubm.com\">scott.regan@ec.ubm.com</a>\r\n508.416.1186\r\n\r\nLiz Wilmes\r\neGroup, Inc.\r\n<a href=\"mailto:Elizabeth.Wilmes@eGroup-us.com\">Elizabeth.Wilmes@eGroup-us.com</a>\r\n843.284.0146\r\n\r\n<strong>eGroup, Inc. Only SC-Based Company Recognized on the CRN Fast Growth 100 List</strong>\r\n\r\nMount Pleasant, SC, September 26, 2011 – eGroup, Inc., providing technology solutions for Serious Competitors, today announced that it has been recognized by Everything Channel on the CRN Fast Growth 100 list. The list recognizes the fastest growing solution providers in North America. Companies on the Fast Growth 100 list average a two-year revenue growth of 130 percent and average annual sales of products and services of $172 million. The ranking is based on two years’ growth of net sales from calendar year 2008 to calendar year 2010.  eGroup was the only South Carolina-based company named to the elite list. \r\n\r\n\"We are thrilled to be recognized for our growth over the past several years,\" said eGroup Principal Mike Carter. \"Our goal is to continue to deliver exceptional customer service while helping our clients understand that technology is a competitive advantage for their business. This is a proven methodology that generates sustained growth for both eGroup and our customers, and we could not be more pleased with the outcome.\"\r\n\r\n“This year’s Fast Growth 100 list reflects the high growth potential for solution providers offering innovative products, solutions and services,” said Kelley Damore, Vice President and Editorial Director for Everything Channel. “Despite an uncertain market, VARs investing in new technologies and services are still growing at a significant rate - a testament to their hard work and ability to truly understand their customers\' needs. We congratulate eGroup on their well-earned success.”\r\n\r\nA sample of the 2011 Fast Growth list can be found at <a href=\"http://www.crn.com\">www.crn.com</a>. <!--more-->\r\n\r\n<strong>CRN 2011 Fast Growth Conference &amp; Awards\r\n</strong><em>Achieving Superior Growth in Uncertain Times</em>\r\n\r\nThe 2011 CRN Fast Growth category and special awards will be presented during the annual conference, taking place October 5-6 at the Doral Resort in Miami. At the event, relationships will be formed and business opportunities will take place as channel executives gather together in an intimate setting with North America’s fastest growing solution providers. The event will honor leading-edge solution providers who are setting the agenda in today\'s channel. To learn more about the event, go to <a href=\"http://everythingchannelevents.com/crnfg_11\">http://everythingchannelevents.com/crnfg_11</a>\r\n\r\n<strong>About eGroup</strong>\r\n\r\nProviding customers across the southeast with a distinct competitive advantage since 1999, eGroup is a visionary technology solutions and services firm with the ability to execute swiftly in a rapidly changing information technology landscape. eGroup’s solutions drive customers’ cost containment, revenue growth, and service objectives by addressing challenges associated with mobility, access to critical applications and data, and security. eGroup’s expertise and core competency is focused in three distinct areas: Cloud Services (public and private), Application Services, and End-User Computing. To deliver these solutions, eGroup has strategic partnerships with industry leaders that include VMware, Cisco, and EMC, along with Citrix, Microsoft, and Trend Micro, and a highly-skilled workforce trained in all of the latest developments in information technology. To learn more, visit <a href=\"http://www.eGroup-us.com\">www.eGroup-us.com</a>.\r\n\r\n<strong>About Everything Channel</strong>\r\n\r\nEverything Channel is the premier provider of IT channel-focused events, media, research, consulting, and sales and marketing services. With over 30 years of experience and engagement, Everything Channel has the unmatched channel expertise to execute integrated solutions for technology executives managing partner recruitment, enablement and go-to-market strategy in order to accelerate technology sales. Everything Channel is a UBM company.\r\n\r\nTo learn more about Everything Channel, visit us at <a href=\"http://www.everythingchannel.com/\">http://www.everythingchannel.com</a>. Follow us on Twitter at <a href=\"http://twitter.com/everythingchnl\">http://twitter.com/everythingchnl</a>.\r\n\r\n<strong>About UBM plc</strong>\r\n\r\nUBM plc is a leading global business media company. We inform markets and bring the world’s buyers and sellers together at events, online, in print and provide them with the information they need to do business successfully. We focus on serving professional commercial communities, from doctors to game developers, from journalists to jewellery traders, from farmers to pharmacists around the world. Our 6,000 staff in more than 30 countries are organised into specialist teams that serve these communities, helping them to do business and their markets to work effectively and efficiently.\r\n\r\nFor more information, go to <a href=\"http://www.ubm.com\">www.ubm.com</a>\r\n\r\n###','eGROUP, INC. ONLY SOUTH CAROLINA-BASED COMPANY NAMED TO CRN FAST GROWTH 100 LIST','','inherit','open','open','','4994-revision-7','','','2011-09-30 13:36:32','2011-09-30 13:36:32','',4994,'http://egroup.jasonmangone.com/4994-revision-7',0,'revision','',0),(5220,12,'2011-09-30 12:55:44','2011-09-30 12:55:44','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-37','','','2011-09-30 12:55:44','2011-09-30 12:55:44','',5155,'http://egroup.jasonmangone.com/5155-revision-37',0,'revision','',0),(5221,12,'2011-09-30 14:00:09','2011-09-30 14:00:09','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\n\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on w','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-38','','','2011-09-30 14:00:09','2011-09-30 14:00:09','',5155,'http://egroup.jasonmangone.com/5155-revision-38',0,'revision','',0),(5222,12,'2011-09-30 14:01:33','2011-09-30 14:01:33','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this is faster backups. and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\n\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-39','','','2011-09-30 14:01:33','2011-09-30 14:01:33','',5155,'http://egroup.jasonmangone.com/5155-revision-39',0,'revision','',0),(5223,12,'2011-09-30 15:59:27','2011-09-30 15:59:27','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\n\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-40','','','2011-09-30 15:59:27','2011-09-30 15:59:27','',5155,'http://egroup.jasonmangone.com/5155-revision-40',0,'revision','',0),(5224,12,'2011-09-30 16:44:54','2011-09-30 16:44:54','To understand how dedupe works in an EMC Avamar server, you must first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-41','','','2011-09-30 16:44:54','2011-09-30 16:44:54','',5155,'http://egroup.jasonmangone.com/5155-revision-41',0,'revision','',0),(5225,12,'2011-09-30 17:07:00','2011-09-30 17:07:00','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\n\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-42','','','2011-09-30 17:07:00','2011-09-30 17:07:00','',5155,'http://egroup.jasonmangone.com/5155-revision-42',0,'revision','',0),(5226,12,'2011-09-30 17:11:21','2011-09-30 17:11:21','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\r\n\r\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\r\n\r\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\r\n\r\n- Provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-43','','','2011-09-30 17:11:21','2011-09-30 17:11:21','',5155,'http://egroup.jasonmangone.com/5155-revision-43',0,'revision','',0),(5227,12,'2011-09-30 17:12:00','2011-09-30 17:12:00','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash for that file.\n\n- If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file system type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated\n\nIf you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\n<strong>THE PROCESS</strong>\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its meta data (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\n\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-44','','','2011-09-30 17:12:00','2011-09-30 17:12:00','',5155,'http://egroup.jasonmangone.com/5155-revision-44',0,'revision','',0),(5229,12,'2011-09-30 17:15:08','2011-09-30 17:15:08','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash/fingerprint for that file. If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file server type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated. If you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution, and \"fixed\" itself is\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size.\n\n- Provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\n<strong>THE PROCESS</strong>\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\n\nWhen a file is backed up to an Avamar server, the file is hashed using its metadata (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\n\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-45','','','2011-09-30 17:15:08','2011-09-30 17:15:08','',5155,'http://egroup.jasonmangone.com/5155-revision-45',0,'revision','',0),(5230,12,'2011-09-30 17:15:44','2011-09-30 17:15:44','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash/fingerprint for that file. If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file server type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated. If you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution, and \"fixed\" itself is an antonym for flexible, which is what we all want our technology to be.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size. It provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\n<strong>THE PROCESS</strong>\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its metadata (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-46','','','2011-09-30 17:15:44','2011-09-30 17:15:44','',5155,'http://egroup.jasonmangone.com/5155-revision-46',0,'revision','',0),(5231,12,'2011-09-30 17:15:45','2011-09-30 17:15:45','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash/fingerprint for that file. If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file server type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated. If you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution, and \"fixed\" itself is an antonym for flexible, which is what we all want our technology to be.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size. It provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\n<strong>THE PROCESS</strong>\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its metadata (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-47','','','2011-09-30 17:15:45','2011-09-30 17:15:45','',5155,'http://egroup.jasonmangone.com/5155-revision-47',0,'revision','',0),(5232,12,'2011-09-30 17:15:48','2011-09-30 17:15:48','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash/fingerprint for that file. If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file server type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated. If you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution, and \"fixed\" itself is an antonym for flexible, which is what we all want our technology to be.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size. It provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\n<strong>THE PROCESS</strong>\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its metadata (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-48','','','2011-09-30 17:15:48','2011-09-30 17:15:48','',5155,'http://egroup.jasonmangone.com/5155-revision-48',0,'revision','',0),(5233,12,'2011-09-30 17:16:13','2011-09-30 17:16:13','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\r\n\r\n<strong>File-level</strong> (the most common)\r\n\r\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash/fingerprint for that file. If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\r\n\r\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file server type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\r\n\r\n<strong>Fixed Block Level</strong> (also called fixed length)\r\n\r\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated. If you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\r\n\r\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\r\n\r\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution, and \"fixed\" itself is an antonym for flexible, which is what we all want our technology to be.\r\n\r\n<strong>Variable block level (what Avamar uses)</strong>\r\n\r\n- This uses an intelligent method to determine segment size based on the data itself to determine length size. It provides much greater granularity in finding duplicate data\r\n\r\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\r\n\r\n<strong>THE PROCESS</strong>\r\n\r\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\r\n\r\nWhen a file is backed up to an Avamar server, the file is hashed using its metadata (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\r\n\r\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\r\n\r\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\r\n\r\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\r\n\r\nhttp://www.youtube.com/watch?v=EbqW_016nVM\r\n\r\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-revision-49','','','2011-09-30 17:16:13','2011-09-30 17:16:13','',5155,'http://egroup.jasonmangone.com/5155-revision-49',0,'revision','',0),(5234,12,'2011-09-30 17:17:38','2011-09-30 17:17:38','EMC Avamar is magical-- and if you don\'t believe me, <a href=\"http://egroup.jasonmangone.com/emc-avamar-customer-success\">read this first</a>. To understand how the dedupe magic works in an EMC Avamar solution, it\'s helpful to first understand the methods of data deduplication commonly found today. Below is a brief explanation of the top 3.\n\n<strong>File-level</strong> (the most common)\n\n- File level identifies duplicate files within a volume, and commonly uses a hashing technique to take the file name, size, last modified date, and other similar metadata information to make a unique hash/fingerprint for that file. If two copies of this exist, and a user opens and changes a single letter or adds a period to it, the hash becomes unique, and this file will not be de-duplicated.\n\nThis is what you’d find on an EMC Celerra or VNX CIFS share. This is good for environments with lots of file server type data and users that tend to share data between them. Our customers seem to be in the 20-25% space savings range using this technology on their VNX / Celerra CIFS shares, but your mileage may vary.\n\n<strong>Fixed Block Level</strong> (also called fixed length)\n\n- Common in snapshot/replication technologies, it breaks a file into a fixed number of bits, and if they’re the same, that segment is de-duplicated. If you have two files that break down into the following bits, the <span style=\"color: #ff0000\">RED</span> sections would be de-duplicated based on a 4-bit block length.\n\n<span style=\"color: #ff0000\">1111</span> 1111 0001 / <span style=\"color: #ff0000\">1111</span> 1110 0000\n\nThis will usually have a higher deduplication perecentage than File level, as files of different types that have identical segments (sub-file level) will still see some level of deduplication. But this isn\'t the best solution, and \"fixed\" itself is an antonym for flexible, which is what we all want our technology to be.\n\n<strong>Variable block level (what Avamar uses)</strong>\n\n- This uses an intelligent method to determine segment size based on the data itself to determine length size. It provides much greater granularity in finding duplicate data\n\nAvamar’s intelligence allows it to look at a file, read the header and say “this is an X type of file, so I’m going to break it into these variable segments”. This provides the greatest level of deduplication. So with that foundation, we\'ll move into more details as to the process Avamar uses to dedupe at the source, and also globally across all clients.\n\n<strong>THE PROCESS</strong>\n\nNote: Most of the following process happens on the CLIENT itself, which is where \"source dedupe\" happens. Keep this in mind when reading through this post and watching the video at the bottom. The benefit of this are faster backups, and substantially less consumption of bandwidth, which is ideal in environments that have smaller WAN pipes between offices or backups that run past their backup windows.\n\n<!--more-->\n\nWhen a file is backed up to an Avamar server, the file is hashed using its metadata (file size, date modified, etc.), and this 20-byte SHA1 hash is stored in the \"file cache\" file locally on the client. When this client goes to backup its data, this file is loaded into RAM, and each file is hashed and compared to the hashes in the file. If it matches, it means the file has already been backed up and has not been modified, so the next file is processed. Because this is done in memory, it happens VERY quickly, and it\'s common to see 95-98% of data on a traditional file system be satisfied against the file cache.\n\nAssume the file HAS been changed, and therefore the hash of the file no longer matches the hash in the file cache. From here, the data will be broken into variable segment lengths through Avamar\'s <a href=\"http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6810398\">patented sticky byte factoring process</a>. These segments are then compressed and hashed, and the resulting hash is written to a HASH CACHE file locally on the client. This file is also loaded into RAM when a backup is initiated.\n\nWhen the client begins it backup, each of these segments will be compared against hashes in the hash cache, and if it matches any hash (which could be from a different file), it will not send the data to the Avamar system, because it knows that specific piece of data has already been backed up.\n\nIf Avamar finds the specific segment has not been backed up (the hash doesn\'t exist in the hash cache), it will take that hash and send ONLY the hash to the Avamar grid itself, and check to see if that segment has been backed up by ANY OTHER client in the environment. This reduces bandwidth, as only the hash gets transmitted, not the data itself, and is where the \"global\" dedupe magic happens. If some other client has already backed up that segment, Avamar adds it into the hash cache and marks it as backed up without having to send the data across the wire. Magic!\n\nhttp://www.youtube.com/watch?v=EbqW_016nVM\n\nFor the record, my Macbook Air keeps autocorrecting \"deduplication\" into \"reduplication\" in case you see that in any of these posts. And as always, questions/comments/complaints/insults are welcome-- @Rattacasa on Twitter.','EMC Avamar - HOW SOURCE &amp; GLOBAL DEDUPE MAGIC HAPPENS','','inherit','open','open','','5155-autosave','','','2011-09-30 17:17:38','2011-09-30 17:17:38','',5155,'http://egroup.jasonmangone.com/5155-autosave',0,'revision','',0),(5235,24,'2011-09-30 17:14:00','2011-09-30 17:14:00','','Auto Draft','','inherit','open','open','','5228-revision','','','2011-09-30 17:14:00','2011-09-30 17:14:00','',5228,'http://egroup.jasonmangone.com/5228-revision',0,'revision','',0),(5237,24,'2011-09-30 17:38:51','2011-09-30 17:38:51','Many documents say that you can use an SVI as a vPC keepalive link, but they don’t show how to accomplish this.  Usually they show the keepalive link using the MGMT0 port.  Here is an example of using an SVI for the vPC keepalive link.\r\nThe keepalive link will be a physically different port and connection between the Nexus5k’s than the peer link.  So for example if you are using interface e1/1 and e1/2 on both sides of the Nexus5k’s for the peer link, then you would use e1/3 for the keepalive link.\r\n\r\n \r\nConfiguration Nexus 5596 Switch 1\r\nvlan 80\r\nname VLAN-KeepAlive\r\nexit\r\n!\r\ninterface Vlan900\r\n  ip address 1.1.1.1/30\r\n  no shutdown\r\n!\r\nvpc domain 1\r\npeer-keepalive destination 1.1.1.2  source 1.1.1.1 vrf default\r\nexit\r\n!\r\ninterface Ethernet1/3\r\ndescription To-5596-Eth1/3-VPC-KeepAlive\r\nswitchport mode trunk\r\nswitchport trunk allowed vlan 80\r\nno shut\r\nexit\r\n!\r\n\r\n\r\nConfiguration Nexus 5596 Switch 2\r\n\r\nvlan 80\r\nname VLAN-KeepAlive\r\n  exit\r\n!\r\ninterface Vlan80\r\n   ip address 1.1.1.2/30\r\n  no shutdown\r\n!\r\nvpc domain 1\r\n  peer-keepalive destination 1.1.1.1 source 1.1.1.2 vrf default\r\n  exit\r\n!\r\ninterface Ethernet1/3\r\n  description To-5596-Eth1/3-VPC-KeepAlive\r\n  switchport mode trunk\r\n  switchport trunk allowed vlan 80\r\n  no shut\r\n  exit\r\n!\r\n\r\n\r\nNotes\r\n\r\nYou must make sure that the vPC peer link does not allow your vPC keepalive VLAN over its trunk.  You cannot have the “heartbeats” going over two different links.  If you have your peer link trunk set to allow all VLANS, the keepalive link will never come up which will keep the peer link from coming up.\r\n','Using SVI for vPC Keepalive Link','','inherit','open','open','','5228-revision-2','','','2011-09-30 17:38:51','2011-09-30 17:38:51','',5228,'http://egroup.jasonmangone.com/5228-revision-2',0,'revision','',0),(5238,24,'2012-03-31 15:01:10','2012-03-31 15:01:10','Many documents say that you can use an SVI as a vPC keepalive link, but they don’t show how to accomplish this. Usually they show the keepalive link using the MGMT0 port. Here is an example of using an SVI for the vPC keepalive link.\r\nThe keepalive link will be a physically different port and connection between the Nexus5k’s than the peer link. So for example if you are using interface e1/1 and e1/2 on both sides of the Nexus5k’s for the peer link, then you would use e1/3 for the keepalive link.\r\n\r\n<!--more-->\r\n\r\n<strong>Configuration Nexus 5596 Switch 1</strong>\r\nvlan 80\r\nname VLAN-KeepAlive\r\nexit\r\n!\r\ninterface Vlan900\r\nip address 1.1.1.1/30\r\nno shutdown\r\n!\r\nvpc domain 1\r\npeer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf default\r\nexit\r\n!\r\ninterface Ethernet1/3\r\ndescription To-5596-Eth1/3-VPC-KeepAlive\r\nswitchport mode trunk\r\nswitchport trunk allowed vlan 80\r\nno shut\r\nexit\r\n!\r\n\r\n<strong>Configuration Nexus 5596 Switch 2</strong>\r\n\r\nvlan 80\r\nname VLAN-KeepAlive\r\nexit\r\n!\r\ninterface Vlan80\r\nip address 1.1.1.2/30\r\nno shutdown\r\n!\r\nvpc domain 1\r\npeer-keepalive destination 1.1.1.1 source 1.1.1.2 vrf default\r\nexit\r\n!\r\ninterface Ethernet1/3\r\ndescription To-5596-Eth1/3-VPC-KeepAlive\r\nswitchport mode trunk\r\nswitchport trunk allowed vlan 80\r\nno shut\r\nexit\r\n!\r\n\r\n<strong>Note</strong>\r\n\r\nYou must make sure that the vPC peer link does not allow your vPC keepalive VLAN over its trunk. You cannot have the “heartbeats” going over two different links. If you have your peer link trunk set to allow all VLANS, the keepalive link will never come up which will keep the peer link from coming up.','Using SVI for vPC Keepalive Link','','inherit','open','open','','5228-autosave','','','2012-03-31 15:01:10','2012-03-31 15:01:10','',5228,'http://egroup.jasonmangone.com/5228-autosave',0,'revision','',0),(5239,44,'2011-09-29 20:14:28','2011-09-29 20:14:28','Many times this has been a sticking point for ASA code upgrades, but the time is coming where the 8.3 code update is going to be a requirement (as I have found with the AIP modules).\r\n\r\n&nbsp;\r\n\r\nHUGE reminder that the upgrade from 8.2 to 8.3 is not an easy or simple upgrade.\r\n\r\n&nbsp;\r\n\r\nThere is also no skipping ahead.  You have to go from 8.2 to 8.3, you can\'t jump over 8.2, you have to upgrade to 8.2 first if you aren\'t already there.\r\n\r\n&nbsp;\r\n\r\nThere are a lot of changes to the code, but none as noticeable as the new NAT statements.\r\n\r\n&nbsp;\r\n\r\nAnother big reminder is to disable nat-control BEFORE you perform the upgrade.  This is the feature that made it so that you had to configure NAT statements between the different interfaces.\r\n\r\n&nbsp;\r\n\r\nBelow is a chart comparing the configuration steps from 8.2 to 8.3 for NAT statements.\r\n\r\n&nbsp;\r\n<table cellspacing=\"0\" cellpadding=\"0\">\r\n<tbody>\r\n<tr>\r\n<td valign=\"middle\"><strong>NAT Feature</strong>&nbsp;</td>\r\n<td valign=\"middle\"><strong>pre-8.3 Configuration</strong>&nbsp;</td>\r\n<td valign=\"middle\"><strong>8.3 Configuration</strong>&nbsp;</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Static NAT</td>\r\n<td valign=\"middle\">static (inside,outside) 209.165.201.15 10.1.1.6 netmask 255.255.255.255</td>\r\n<td valign=\"middle\"><strong>Option 1 (Preferred)</strong>object network obj-10.1.1.6\r\n\r\nhost 10.1.1.6\r\n\r\nnat (inside,outside) static 209.165.201.15\r\n\r\n&nbsp;\r\n\r\n<strong>Option 2\r\n</strong>\r\n\r\nobject network server_real\r\n\r\nhost 10.1.1.6\r\n\r\nobject network server_global\r\n\r\nhost 209.165.201.15\r\n\r\n!\r\n\r\nnat (inside,outside) source static server_real server_global</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Dynamic PAT</td>\r\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0&nbsp;\r\n\r\nglobal (outside) 1 209.165.201.254</td>\r\n<td valign=\"middle\">object network internal_netsubnet 10.1.1.0 255.255.255.0\r\n\r\n!\r\n\r\nobject network internal_net\r\n\r\n&nbsp;\r\n\r\nnat (inside,outside) dynamic 209.165.201.254</td>\r\n</tr>\r\n<tr>\r\n<td valign=\"middle\">Dynamic NAT with Interface Overload</td>\r\n<td valign=\"middle\">nat (inside) 1 10.1.1.0 255.255.255.0&nbsp;\r\n\r\nglobal (outside) 1 interface\r\n\r\n&nbsp;\r\n\r\nglobal (outside) 1 209.165.201.1-209.165.201.2</td>\r\n<td valign=\"middle\">object network NAT_Poolrange 209.165.201.2 209.165.201.50\r\n\r\nobject network internal_net\r\n\r\nsubnet 10.1.1.0 255.255.255.0\r\n\r\n!\r\n\r\nobject network internal_net\r\n\r\nnat (inside,outside) dynamic NAT_Pool interface</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nThe next big one is ACLs (Access Control Lists).  The command syntax hasn\'t changed much for these, just the IP that is used for the rule.\r\n\r\n&nbsp;\r\n\r\nIn the past when you were allowing traffic to a server you would configure it to point to the public IP that the server was NAT\'d to.  Now it is configured to the internal address.  For example....\r\n\r\n&nbsp;\r\n\r\nBelow is the way you would normally configure an ACL\r\n\r\n&nbsp;\r\n\r\nstatic (inside,outside) 208.268.11.17 10.100.1.11 netmask 255.255.255.255\r\n\r\n!\r\n\r\naccess-list outside_in extended permit tcp any host 208.268.11.17\r\n\r\naccess-group outside_in in interface outside\r\n\r\n&nbsp;\r\n\r\nWith 8.3 you use network objects, like below.\r\n\r\n&nbsp;\r\n\r\nobject network obj-10.100.1.11\r\n\r\nhost 10.100.1.11\r\n\r\nnat (inside,outside) static 208.268.11.17\r\n\r\n!\r\n\r\naccess-list outside_in extended permit tcp any host 10.100.1.11\r\n\r\naccess-group outside_in in interface outside\r\n\r\n&nbsp;\r\n\r\nYou can see the difference.\r\n\r\n&nbsp;\r\n\r\nThe big caveat with the upgrade is that the process is supposed to make the adjustments automatically.  I have found that is not always the case.  All the static NATs tend to need some tweaking, as well as a lot of the Access Rules.\r\n\r\n&nbsp;\r\n\r\nBest bet is to make sure that you have a good understanding of the changes before diving into the upgrade.\r\n\r\n&nbsp;\r\n\r\nThanks to <a title=\"Cisco Support Forums\" href=\"https://supportforums.cisco.com/docs/DOC-12690\" target=\"_blank\">Cisco Support Forums</a> for the information.','Cisco ASA 8.3 Upgrade - Lessons Learned','','inherit','open','open','','5176-revision-5','','','2011-09-29 20:14:28','2011-09-29 20:14:28','',5176,'http://egroup.jasonmangone.com/5176-revision-5',0,'revision','',0),(5241,24,'2011-09-30 17:39:37','2011-09-30 17:39:37','Many documents say that you can use an SVI as a vPC keepalive link, but they don’t show how to accomplish this. Usually they show the keepalive link using the MGMT0 port. Here is an example of using an SVI for the vPC keepalive link.\r\nThe keepalive link will be a physically different port and connection between the Nexus5k’s than the peer link. So for example if you are using interface e1/1 and e1/2 on both sides of the Nexus5k’s for the peer link, then you would use e1/3 for the keepalive link.\r\n\r\n<strong>Configuration Nexus 5596 Switch 1</strong>\r\nvlan 80\r\nname VLAN-KeepAlive\r\nexit\r\n!\r\ninterface Vlan900\r\nip address 1.1.1.1/30\r\nno shutdown\r\n!\r\nvpc domain 1\r\npeer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf default\r\nexit\r\n!\r\ninterface Ethernet1/3\r\ndescription To-5596-Eth1/3-VPC-KeepAlive\r\nswitchport mode trunk\r\nswitchport trunk allowed vlan 80\r\nno shut\r\nexit\r\n!\r\n\r\n<strong>Configuration Nexus 5596 Switch 2</strong>\r\n\r\nvlan 80\r\nname VLAN-KeepAlive\r\nexit\r\n!\r\ninterface Vlan80\r\nip address 1.1.1.2/30\r\nno shutdown\r\n!\r\nvpc domain 1\r\npeer-keepalive destination 1.1.1.1 source 1.1.1.2 vrf default\r\nexit\r\n!\r\ninterface Ethernet1/3\r\ndescription To-5596-Eth1/3-VPC-KeepAlive\r\nswitchport mode trunk\r\nswitchport trunk allowed vlan 80\r\nno shut\r\nexit\r\n!\r\n\r\n<strong>Note</strong>\r\n\r\nYou must make sure that the vPC peer link does not allow your vPC keepalive VLAN over its trunk. You cannot have the “heartbeats” going over two different links. If you have your peer link trunk set to allow all VLANS, the keepalive link will never come up which will keep the peer link from coming up.','Using SVI for vPC Keepalive Link','','inherit','open','open','','5228-revision-3','','','2011-09-30 17:39:37','2011-09-30 17:39:37','',5228,'http://egroup.jasonmangone.com/5228-revision-3',0,'revision','',0),(5242,24,'2011-09-30 19:54:30','2011-09-30 19:54:30','Many documents say that you can use an SVI as a vPC keepalive link, but they don’t show how to accomplish this. Usually they show the keepalive link using the MGMT0 port. Here is an example of using an SVI for the vPC keepalive link.\r\nThe keepalive link will be a physically different port and connection between the Nexus5k’s than the peer link. So for example if you are using interface e1/1 and e1/2 on both sides of the Nexus5k’s for the peer link, then you would use e1/3 for the keepalive link.\r\n\r\n<!--more-->\r\n\r\n<strong>Configuration Nexus 5596 Switch 1</strong>\r\nvlan 80\r\nname VLAN-KeepAlive\r\nexit\r\n!\r\ninterface Vlan900\r\nip address 1.1.1.1/30\r\nno shutdown\r\n!\r\nvpc domain 1\r\npeer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf default\r\nexit\r\n!\r\ninterface Ethernet1/3\r\ndescription To-5596-Eth1/3-VPC-KeepAlive\r\nswitchport mode trunk\r\nswitchport trunk allowed vlan 80\r\nno shut\r\nexit\r\n!\r\n\r\n<strong>Configuration Nexus 5596 Switch 2</strong>\r\n\r\nvlan 80\r\nname VLAN-KeepAlive\r\nexit\r\n!\r\ninterface Vlan80\r\nip address 1.1.1.2/30\r\nno shutdown\r\n!\r\nvpc domain 1\r\npeer-keepalive destination 1.1.1.1 source 1.1.1.2 vrf default\r\nexit\r\n!\r\ninterface Ethernet1/3\r\ndescription To-5596-Eth1/3-VPC-KeepAlive\r\nswitchport mode trunk\r\nswitchport trunk allowed vlan 80\r\nno shut\r\nexit\r\n!\r\n\r\n<strong>Note</strong>\r\n\r\nYou must make sure that the vPC peer link does not allow your vPC keepalive VLAN over its trunk. You cannot have the “heartbeats” going over two different links. If you have your peer link trunk set to allow all VLANS, the keepalive link will never come up which will keep the peer link from coming up.','Using SVI for vPC Keepalive Link','','inherit','open','open','','5228-revision-4','','','2011-09-30 19:54:30','2011-09-30 19:54:30','',5228,'http://egroup.jasonmangone.com/5228-revision-4',0,'revision','',0),(5243,24,'2011-09-30 20:04:30','2011-09-30 20:04:30','It appears that there is an issue with tacacs and software version 5.2(1) for the Nexus 7010.  When you set up tacacs it lets you authenticate to the tacacs server, but it also lets you authenticate using the local database as well.  Normal behavior would be to use only tacacs except when the tacacs servers are unreachable.  Then you would use the local database for authentication.','Tacacs issue Nexus 7010','','publish','open','open','','tacacs-issue-nexus-7010','','','2011-09-30 20:04:30','2011-09-30 20:04:30','',0,'http://egroup.jasonmangone.com/?p=5243',0,'post','',0),(5244,24,'2011-09-30 20:03:40','2011-09-30 20:03:40','It appears that there is an issue with tacacs and software version 5.2(1) for the Nexus 7010.  When you set up tacacs it lets you authenticate to the tacacs server, but it also lets you use the local database as well.  Normal behavior would be to use only tacacs except when the tacacs servers are unreachable.  Then you would use the local database for authentication.','Tacacs issue Nexus 7010','','inherit','open','open','','5243-revision','','','2011-09-30 20:03:40','2011-09-30 20:03:40','',5243,'http://egroup.jasonmangone.com/5243-revision',0,'revision','',0),(5245,6,'2011-09-30 20:36:02','2011-09-30 20:36:02','In this case were are running EMC\'s Networker 7.6 SP2 on Server 2008 R2 with IE9, and running into the following issues resulting in an inability to log into the Networker Management Console:\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\"><img class=\"aligncenter size-full wp-image-5246\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\" alt=\"\" width=\"521\" height=\"630\" /></a>\r\n\r\n&nbsp;\r\n\r\nFrom reading the error log \"<strong>UNEXPECTED EXCEPTION java.lang.reflect.InvocationTargetException</strong>\" it looks like a first glance that the issue might be with Java, but it is actually an IE9 incompatability issue.\r\n\r\n&nbsp;\r\n\r\nYou have 2 options:\r\n\r\n1. Uninstall IE9 and downgrade to IE8\r\n\r\n2. Install the Networker Management Console on server with IE8.\r\n\r\n&nbsp;','NETWORKER ERROR: UNEXPECTED EXCEPTION java.lang.reflect.InvocationTargetException AND HOW TO FIX IT','','publish','open','open','','networker-error-unexpected-exception-java-lang-refliect-invocationtargetexception-and-how-to-fix-it','','','2011-09-30 20:37:46','2011-09-30 20:37:46','',0,'http://egroup.jasonmangone.com/?p=5245',0,'post','',1),(5246,6,'2011-09-30 20:18:00','2011-09-30 20:18:00','','networkererror','','inherit','open','open','','networkererror','','','2011-09-30 20:18:00','2011-09-30 20:18:00','',5245,'http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg',0,'attachment','image/jpeg',0),(5247,6,'2011-09-30 20:34:12','2011-09-30 20:34:12','In this case were are running EMC\'s Networker 7.6 SP2 on Server 2008 R2 with IE9, and running into the following issues resulting in an inability to log into the Networker Management Console:\n\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\"><img class=\"aligncenter size-full wp-image-5246\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\" alt=\"\" width=\"521\" height=\"630\" /></a>\n\n&nbsp;\n\nYou have 2 options:\n\n1. Uninstall IE9 and downgrade to IE8\n\n2. Install the Networker Management Console on server with IE8.\n\n&nbsp;','NETWORKER ERROR: UNEXPECTED EXCEPTION java.lang.refliect.InvocationTargetException AND HOW TO FIX IT','','inherit','open','open','','5245-revision','','','2011-09-30 20:34:12','2011-09-30 20:34:12','',5245,'http://egroup.jasonmangone.com/5245-revision',0,'revision','',0),(5248,6,'2011-09-30 20:35:13','2011-09-30 20:35:13','In this case were are running EMC\'s Networker 7.6 SP2 on Server 2008 R2 with IE9, and running into the following issues resulting in an inability to log into the Networker Management Console:\n\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\"><img class=\"aligncenter size-full wp-image-5246\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\" alt=\"\" width=\"521\" height=\"630\" /></a>\n\n&nbsp;\n\nFrom reading the error log, it looks like a first glance that the issue might be with Java, but it is actually an IE9 incompatability issue.\n\n&nbsp;\n\nYou have 2 options:\n\n1. Uninstall IE9 and downgrade to IE8\n\n2. Install the Networker Management Console on server with IE8.\n\n&nbsp;','NETWORKER ERROR: UNEXPECTED EXCEPTION java.lang.refliect.InvocationTargetException AND HOW TO FIX IT','','inherit','open','open','','5245-revision-2','','','2011-09-30 20:35:13','2011-09-30 20:35:13','',5245,'http://egroup.jasonmangone.com/5245-revision-2',0,'revision','',0),(5249,6,'2011-09-30 20:36:02','2011-09-30 20:36:02','In this case were are running EMC\'s Networker 7.6 SP2 on Server 2008 R2 with IE9, and running into the following issues resulting in an inability to log into the Networker Management Console:\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\"><img class=\"aligncenter size-full wp-image-5246\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\" alt=\"\" width=\"521\" height=\"630\" /></a>\r\n\r\n&nbsp;\r\n\r\nFrom reading the error log, it looks like a first glance that the issue might be with Java, but it is actually an IE9 incompatability issue.\r\n\r\n&nbsp;\r\n\r\nYou have 2 options:\r\n\r\n1. Uninstall IE9 and downgrade to IE8\r\n\r\n2. Install the Networker Management Console on server with IE8.\r\n\r\n&nbsp;','NETWORKER ERROR: UNEXPECTED EXCEPTION java.lang.refliect.InvocationTargetException AND HOW TO FIX IT','','inherit','open','open','','5245-revision-3','','','2011-09-30 20:36:02','2011-09-30 20:36:02','',5245,'http://egroup.jasonmangone.com/5245-revision-3',0,'revision','',0),(5250,6,'2011-09-30 20:37:03','2011-09-30 20:37:03','In this case were are running EMC\'s Networker 7.6 SP2 on Server 2008 R2 with IE9, and running into the following issues resulting in an inability to log into the Networker Management Console:\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\"><img class=\"aligncenter size-full wp-image-5246\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\" alt=\"\" width=\"521\" height=\"630\" /></a>\r\n\r\n&nbsp;\r\n\r\nFrom reading the error log, it looks like a first glance that the issue might be with Java, but it is actually an IE9 incompatability issue.\r\n\r\n&nbsp;\r\n\r\nYou have 2 options:\r\n\r\n1. Uninstall IE9 and downgrade to IE8\r\n\r\n2. Install the Networker Management Console on server with IE8.\r\n\r\n&nbsp;','NETWORKER ERROR: UNEXPECTED EXCEPTION java.lang.reflect.InvocationTargetException AND HOW TO FIX IT','','inherit','open','open','','5245-revision-4','','','2011-09-30 20:37:03','2011-09-30 20:37:03','',5245,'http://egroup.jasonmangone.com/5245-revision-4',0,'revision','',0),(5251,6,'2011-09-30 20:37:18','2011-09-30 20:37:18','In this case were are running EMC\'s Networker 7.6 SP2 on Server 2008 R2 with IE9, and running into the following issues resulting in an inability to log into the Networker Management Console:\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\"><img class=\"aligncenter size-full wp-image-5246\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\" alt=\"\" width=\"521\" height=\"630\" /></a>\r\n\r\n&nbsp;\r\n\r\nFrom reading the error log, it looks like a first glance that the issue might be with Java, but it is actually an IE9 incompatability issue.\r\n\r\n&nbsp;\r\n\r\nYou have 2 options:\r\n\r\n1. Uninstall IE9 and downgrade to IE8\r\n\r\n2. Install the Networker Management Console on server with IE8.\r\n\r\n&nbsp;','NETWORKER ERROR: UNEXPECTED EXCEPTION java.lang.reflect.InvocationTargetException AND HOW TO FIX IT','','inherit','open','open','','5245-revision-5','','','2011-09-30 20:37:18','2011-09-30 20:37:18','',5245,'http://egroup.jasonmangone.com/5245-revision-5',0,'revision','',0),(5252,6,'2011-09-30 20:38:48','2011-09-30 20:38:48','In this case were are running EMC\'s Networker 7.6 SP2 on Server 2008 R2 with IE9, and running into the following issues resulting in an inability to log into the Networker Management Console:\n\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\"><img class=\"aligncenter size-full wp-image-5246\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/09/networkererror.jpg\" alt=\"\" width=\"521\" height=\"630\" /></a>\n\n&nbsp;\n\nFrom reading the error log \"<strong>UNEXPECTED EXCEPTION java.lang.reflect.InvocationTargetException</strong>\" it looks like a first glance that the issue might be with Java, but it is actually an IE9 incompatability issue.\n\n&nbsp;\n\nYou have 2 options:\n\n1. Uninstall IE9 and downgrade to IE8\n\n2. Install the Networker Management Console on server with IE8.\n\n&nbsp;','NETWORKER ERROR: UNEXPECTED EXCEPTION java.lang.reflect.InvocationTargetException AND HOW TO FIX IT','','inherit','open','open','','5245-autosave','','','2011-09-30 20:38:48','2011-09-30 20:38:48','',5245,'http://egroup.jasonmangone.com/5245-autosave',0,'revision','',0),(5256,23,'2011-10-09 16:49:00','2011-10-09 16:49:00','When you install SQL with Basic Management Tools, the installer does not allow you to go back and install the Complete Management Tools. The option will be grayed out.\r\n\r\nIn order to install the Complete Management Tools, insert the installation media for SQL, then open a command prompt and run the following...\r\n\r\n<strong>setup.exe\r\n/FEATURES=Tools /Q\r\n/INDICATEPROGRESS\r\n/ACTION=Install\r\n/INSTANCENAME=SQLSERVER2008R2Ent\r\n</strong><strong>/BROWSERSVCSTARTUPTYPE=Automatic\r\n/AGTSVCACCOUNT=”NT AUTHORITY\\NETWORK SERVICE”\r\n/IACCEPTSQLSERVERLICENSETERMS</strong>\r\n\r\nNote: Replace \"SQLSERVER2008R2Ent\" with the name of your instance.\r\nNote 2: The above command is for SQL 2008R2. SQL 2008 does not support the /IACCEPTSQLSERVERLICENSETERMS switch','SQL 2008 R2: INSTALL COMPLETE MANAGEMENT TOOLS OVER BASIC','','publish','open','open','','sql-2008-r2-install-complete-management-tools-over-basic','','','2011-10-10 18:15:46','2011-10-10 18:15:46','',0,'http://egroup.jasonmangone.com/?p=5256',0,'post','',0),(5258,12,'2011-10-05 02:20:32','2011-10-05 02:20:32','Storage pools provide the storage administrator a lot of flexibility, including the ability to truly \"pool\" their storage, be able to tier between different drive types and performance characteristics, mix and match drives of different sizes, etc.\n\nAll of the above helps to simplify, where you can set your storage configuration and let it rock and roll. But before you start using Storage Pools as the end all be all, and completely replace the use of RAID Groups, there are several things you should be aware of.\n\nFirst, under the covers of the pool there are certain \"Private RAID Groups\" being carved in certain multiples depending on the RAID type. This is very important to know, especially as you look to add more drives into the pool, to help maintain the valid number of performance, etc. I posted what these PRGs are in <a href=\"http://egroup.jasonmangone.com/emc-vnx-storage-pools-private-raid-groups\">this post </a>\n\nSecond, there is a \"guideline\" I\'ve found in several documents that states you should expand the pool by the same number of drives you\'ve originally added into it. I\'ve reached out to some internal contacts at EMC for clarification of the \"why\" on this, but haven\'t heard back just yet. In the meantime, I assume this is to maintain performance characteristics and possibly play better with some future capabilities (like rebalancing workloads across added drives).\n\nThird, and one of the other VERY common Storage Pool questions we are asked/answer and deal with is if the pool can contain different RAID types per disk type. Meaning, if I have NL-SAS drives at 2TB each, I want to use RAID 6 for them, but if there are 600GB SAS Drives, I\'d prefer RAID 5-- can I do that in the same pool?\n\nToday, the answer is no, you can\'t. Futures are futures, so I can\'t say with certainty that you will this year (but you might be able to!).\n\nSo what does this mean? Well, we mostly see people creating Storage Pools with different drive tiers based on the desired RAID Group-- so a Storage Pool with EFDs and SAS drives would be RAID 5, and there would be a SEPARATE Storage Pool for the NL-SAS drives for RAID 6. This gives you the desired RAID groups for the disk types without causing you to lose additional disk space on the EFDs/SAS drives if you had them using RAID 6 also.\n\n&nbsp;','EMC - STORAGE POOL CONSIDERATIONS ','','inherit','open','open','','5057-revision-2','','','2011-10-05 02:20:32','2011-10-05 02:20:32','',5057,'http://egroup.jasonmangone.com/5057-revision-2',0,'revision','',0),(5259,12,'2011-10-05 02:20:42','2011-10-05 02:20:42','Storage pools provide the storage administrator a lot of flexibility, including the ability to truly \"pool\" their storage, be able to tier between different drive types and performance characteristics, mix and match drives of different sizes, etc.\r\n\r\nAll of the above helps to simplify, where you can set your storage configuration and let it rock and roll. But before you start using Storage Pools as the end all be all, and completely replace the use of RAID Groups, there are several things you should be aware of.\r\n\r\nFirst, under the covers of the pool there are certain \"Private RAID Groups\" being carved in certain multiples depending on the RAID type. This is very important to know, especially as you look to add more drives into the pool, to help maintain the valid number of performance, etc. I posted what these PRGs are in <a href=\"http://egroup.jasonmangone.com/emc-vnx-storage-pools-private-raid-groups\">this post </a>\r\n\r\nSecond, there is a \"guideline\" I\'ve found in several documents that states you should expand the pool by the same number of drives you\'ve originally added into it. I\'ve reached out to some internal contacts at EMC for clarification of the \"why\" on this, but haven\'t heard back just yet. In the meantime, I assume this is to maintain performance characteristics and possibly play better with some future capabilities (like rebalancing workloads across added drives).\r\n\r\nThird, and one of the other VERY common Storage Pool questions we are asked/answer and deal with is if the pool can contain different RAID types per disk type. Meaning, if I have NL-SAS drives at 2TB each, I want to use RAID 6 for them, but if there are 600GB SAS Drives, I\'d prefer RAID 5-- can I do that in the same pool?\r\n\r\nToday, the answer is no, you can\'t. Futures are futures, so I can\'t say with certainty that you will this year (but you might be able to!).\r\n\r\nSo what does this mean? Well, we mostly see people creating Storage Pools with different drive tiers based on the desired RAID Group-- so a Storage Pool with EFDs and SAS drives would be RAID 5, and there would be a SEPARATE Storage Pool for the NL-SAS drives for RAID 6. This gives you the desired RAID groups for the disk types without causing you to lose additional disk space on the EFDs/SAS drives if you had them using RAID 6 also.\r\n\r\n&nbsp;','EMC - STORAGE POOL CONSIDERATIONS ','','inherit','open','open','','5057-revision-3','','','2011-10-05 02:20:42','2011-10-05 02:20:42','',5057,'http://egroup.jasonmangone.com/5057-revision-3',0,'revision','',0),(5260,12,'2011-10-05 02:20:51','2011-10-05 02:20:51','Storage pools provide the storage administrator a lot of flexibility, including the ability to truly \"pool\" their storage, be able to tier between different drive types and performance characteristics, mix and match drives of different sizes, etc.\r\n\r\nAll of the above helps to simplify, where you can set your storage configuration and let it rock and roll. But before you start using Storage Pools as the end all be all, and completely replace the use of RAID Groups, there are several things you should be aware of.\r\n\r\nFirst, under the covers of the pool there are certain \"Private RAID Groups\" being carved in certain multiples depending on the RAID type. This is very important to know, especially as you look to add more drives into the pool, to help maintain the valid number of performance, etc. I posted what these PRGs are in <a href=\"http://egroup.jasonmangone.com/emc-vnx-storage-pools-private-raid-groups\">this post </a>\r\n\r\nSecond, there is a \"guideline\" I\'ve found in several documents that states you should expand the pool by the same number of drives you\'ve originally added into it. I\'ve reached out to some internal contacts at EMC for clarification of the \"why\" on this, but haven\'t heard back just yet. In the meantime, I assume this is to maintain performance characteristics and possibly play better with some future capabilities (like rebalancing workloads across added drives).\r\n\r\nThird, and one of the other VERY common Storage Pool questions we are asked/answer and deal with is if the pool can contain different RAID types per disk type. Meaning, if I have NL-SAS drives at 2TB each, I want to use RAID 6 for them, but if there are 600GB SAS Drives, I\'d prefer RAID 5-- can I do that in the same pool?\r\n\r\nToday, the answer is no, you can\'t. Futures are futures, so I can\'t say with certainty that you will this year (but you might be able to!).\r\n\r\nSo what does this mean? Well, we mostly see people creating Storage Pools with different drive tiers based on the desired RAID Group-- so a Storage Pool with EFDs and SAS drives would be RAID 5, and there would be a SEPARATE Storage Pool for the NL-SAS drives for RAID 6. This gives you the desired RAID groups for the disk types without causing you to lose additional disk space on the EFDs/SAS drives if you had them using RAID 6 also.\r\n\r\n&nbsp;','EMC - STORAGE POOL CONSIDERATIONS ','','inherit','open','open','','5057-revision-4','','','2011-10-05 02:20:51','2011-10-05 02:20:51','',5057,'http://egroup.jasonmangone.com/5057-revision-4',0,'revision','',0),(5261,12,'2011-10-05 02:21:46','2011-10-05 02:21:46','Storage pools provide the storage administrator a lot of flexibility, including the ability to truly \"pool\" their storage, be able to tier between different drive types and performance characteristics, mix and match drives of different sizes, etc.\r\n\r\nAll of the above helps to simplify, where you can set your storage configuration and let it rock and roll. But before you start using Storage Pools as the end all be all, and completely replace the use of RAID Groups, there are several things you should be aware of.\r\n\r\nFirst, under the covers of the pool there are certain \"Private RAID Groups\" being carved in certain multiples depending on the RAID type. This is very important to know, especially as you look to add more drives into the pool, to help maintain the valid number of performance, etc. I posted what these PRGs are in <a href=\"http://egroup.jasonmangone.com/emc-vnx-storage-pools-private-raid-groups\">this post </a>\r\n\r\nSecond, there is a \"guideline\" I\'ve found in several documents that states you should expand the pool by the same number of drives you\'ve originally added into it. I\'ve reached out to some internal contacts at EMC for clarification of the \"why\" on this, but haven\'t heard back just yet. In the meantime, I assume this is to maintain performance characteristics and possibly play better with some future capabilities (like rebalancing workloads across added drives).\r\n\r\nThird, and one of the other VERY common Storage Pool questions we are asked/answer and deal with is if the pool can contain different RAID types per disk type. Meaning, if I have NL-SAS drives at 2TB each, I want to use RAID 6 for them, but if there are 600GB SAS Drives, I\'d prefer RAID 5-- can I do that in the same pool?\r\n\r\nToday, the answer is no, you can\'t. Futures are futures, so I can\'t say with certainty that you will this year (but you might be able to!).\r\n\r\nSo what does this mean? Well, we mostly see people creating Storage Pools with different drive tiers based on the desired RAID Group-- so a Storage Pool with EFDs and SAS drives would be RAID 5, and there would be a SEPARATE Storage Pool for the NL-SAS drives for RAID 6. This gives you the desired RAID groups for the disk types without causing you to lose additional disk space on the EFDs/SAS drives if you had them using RAID 6 also.\r\n\r\n&nbsp;','EMC - STORAGE POOL CONSIDERATIONS ','','inherit','open','open','','5057-revision-5','','','2011-10-05 02:21:46','2011-10-05 02:21:46','',5057,'http://egroup.jasonmangone.com/5057-revision-5',0,'revision','',0),(5262,12,'2011-10-05 02:23:07','2011-10-05 02:23:07','Storage pools provide the storage administrator a lot of flexibility, including the ability to truly \"pool\" their storage, be able to tier between different drive types and performance characteristics, mix and match drives of different sizes, etc.\n\nAll of the above helps to simplify, where you can set your storage configuration and let it rock and roll. But before you start using Storage Pools as the end all be all, and completely replace the use of RAID Groups, there are several things you should be aware of.\n\nFirst, under the covers of the pool there are certain \"Private RAID Groups\" being carved in certain multiples depending on the RAID type. This is very important to know, especially as you look to add more drives into the pool, to help maintain the valid number of performance, etc. I posted what these PRGs are in <a href=\"http://egroup.jasonmangone.com/emc-vnx-storage-pools-private-raid-groups\">this post </a>\n\nSecond, there is a \"guideline\" I\'ve found in several documents that states you should expand the pool by the same number of drives you\'ve originally added into it. I\'ve reached out to some internal contacts at EMC for clarification of the \"why\" on this, but haven\'t heard back just yet. In the meantime, I assume this is to maintain performance characteristics and possibly play better with some future capabilities (like rebalancing workloads across added drives).\n\n<!--more-->\n\nThird, and one of the other VERY common Storage Pool questions we are asked/answer and deal with is if the pool can contain different RAID types per disk type. Meaning, if I have NL-SAS drives at 2TB each, I want to use RAID 6 for them, but if there are 600GB SAS Drives, I\'d prefer RAID 5-- can I do that in the same pool?\n\nToday, the answer is no, you can\'t. Futures are futures, so I can\'t say with certainty that you will this year (but you might be able to!).\n\nSo what does this mean? Well, we mostly see people creating Storage Pools with different drive tiers based on the desired RAID Group-- so a Storage Pool with EFDs and SAS drives would be RAID 5, and there would be a SEPARATE Storage Pool for the NL-SAS drives for RAID 6. This gives you the desired RAID groups for the disk types without causing you to lose additional disk space on the EFDs/SAS drives if you had them using RAID 6 also.\n\n&nbsp;','EMC - STORAGE POOL CONSIDERATIONS ','','inherit','open','open','','5057-autosave','','','2011-10-05 02:23:07','2011-10-05 02:23:07','',5057,'http://egroup.jasonmangone.com/5057-autosave',0,'revision','',0),(8336,2,'2013-07-16 10:07:04','2013-07-16 14:07:04','<div class=\"col1\">\r\n<p>Your Name (required)<br />\r\n    [text* your-name] </p>\r\n\r\n<p>Your Email (required)<br />\r\n    [text* your-email] </p>\r\n\r\n<p>Company<br />\r\n    [text company] </p>\r\n<p>[captchac captcha-547 size:s]\r\ntype the characters in the image above</p>\r\n<p>[captchar captcha-547]</p>\r\n<p>[submit \"Send\"]</p>\r\n</div>\neGroup-us.com ::::: Newsletter Sign Up\n[your-name] <[your-email]>\nFrom: [your-name] <[your-email]>\r\nSubject: [your-subject]\r\n\r\nMessage Body:\r\n [your-name] <[your-email]>\r\n[company]\r\n\r\n--\r\nThis e-mail was sent from a contact form on eGroup (http://egroup.jasonmangone.com)\nrich.young@eGroup-us.com\n\n\n1\n\n[your-subject]\n[your-name] <[your-email]>\nMessage Body:\r\n[your-message]\r\n\r\n--\r\nThis e-mail was sent from a contact form on eGroup (http://egroup.jasonmangone.com)\n[your-email]\n\n\n\nYour message was sent successfully. Thanks.\nFailed to send your message. Please try later or contact the administrator by another method.\nValidation errors occurred. Please confirm the fields and submit it again.\nFailed to send your message. Please try later or contact the administrator by another method.\nPlease accept the terms to proceed.\nPlease fill the required field.\nYour entered code is incorrect.\nFailed to upload file.\nThis file type is not allowed.\nThis file is too large.\nFailed to upload file. Error occurred.\nYour answer is not correct.\nNumber format seems invalid.\nThis number is too small.\nThis number is too large.\nEmail address seems invalid.\nURL seems invalid.\nTelephone number seems invalid.\nDate format seems invalid.\nThis date is too early.\nThis date is too late.','Newsletter','','publish','open','open','','newsletter','','','2013-07-16 10:14:50','2013-07-16 14:14:50','',0,'http://egroup.jasonmangone.com/?post_type=wpcf7_contact_form&#038;p=8336',0,'wpcf7_contact_form','',0),(5266,27,'2011-10-05 18:22:23','2011-10-05 18:22:23','','Events','','trash','open','open','','events-2','','','2012-08-22 14:56:02','2012-08-22 18:56:02','',0,'http://egroup.jasonmangone.com/events-2',0,'page','',0),(5269,29,'2011-10-06 15:38:43','2011-10-06 15:38:43','','Auto Draft','','inherit','open','open','','5268-revision','','','2011-10-06 15:38:43','2011-10-06 15:38:43','',5268,'http://egroup.jasonmangone.com/5268-revision',0,'revision','',0),(5271,29,'2011-10-06 16:35:15','2011-10-06 16:35:15','','AvarmarDDCap1','','inherit','open','open','','avarmarddcap1','','','2011-10-06 16:35:15','2011-10-06 16:35:15','',5268,'http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap1.png',0,'attachment','image/png',0),(5272,29,'2011-10-06 16:35:24','2011-10-06 16:35:24','The question is often asked: “Which is better Target or Source based deduplicaiton?”\n\nThe answer: Both.\n\nWatch the video below to find out more.\n\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\n\n&nbsp;\n\n&nbsp;\n\n&nbsp;\n\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-2','','','2011-10-06 16:35:24','2011-10-06 16:35:24','',5268,'http://egroup.jasonmangone.com/5268-revision-2',0,'revision','',0),(5276,29,'2011-10-06 16:50:55','2011-10-06 16:50:55','The question is often asked: “Which is better Target or Source based deduplicaiton?”\n\nThe answer: Both.\n\nWatch the video below to find out more.\n\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\n\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-6','','','2011-10-06 16:50:55','2011-10-06 16:50:55','',5268,'http://egroup.jasonmangone.com/5268-revision-6',0,'revision','',0),(5274,29,'2011-10-06 16:48:44','2011-10-06 16:48:44','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-4','','','2011-10-06 16:48:44','2011-10-06 16:48:44','',5268,'http://egroup.jasonmangone.com/5268-revision-4',0,'revision','',0),(5273,29,'2011-10-06 16:47:40','2011-10-06 16:47:40','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n<p><a href=\"http://vimeo.com/30139705\">Source or Target Based Deduplication</a> from <a href=\"http://vimeo.com/user8807339\">John Flisher</a> on <a href=\"http://vimeo.com\">Vimeo</a>.</p>\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-3','','','2011-10-06 16:47:40','2011-10-06 16:47:40','',5268,'http://egroup.jasonmangone.com/5268-revision-3',0,'revision','',0),(5275,29,'2011-10-06 16:49:40','2011-10-06 16:49:40','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n&nbsp;\r\n\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-5','','','2011-10-06 16:49:40','2011-10-06 16:49:40','',5268,'http://egroup.jasonmangone.com/5268-revision-5',0,'revision','',0),(5277,29,'2011-10-06 16:51:21','2011-10-06 16:51:21','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\nWatch the video below to find out more.\r\n\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-7','','','2011-10-06 16:51:21','2011-10-06 16:51:21','',5268,'http://egroup.jasonmangone.com/5268-revision-7',0,'revision','',0),(5278,29,'2011-10-06 16:51:33','2011-10-06 16:51:33','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\nWatch the video below to find out more.\r\n\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-8','','','2011-10-06 16:51:33','2011-10-06 16:51:33','',5268,'http://egroup.jasonmangone.com/5268-revision-8',0,'revision','',0),(5309,29,'2011-10-14 19:46:21','2011-10-14 19:46:21','We ran into some trouble on a few VMs in our LAB after we upgarded to vSphere 5.   For some reason once powered on  the VM NICs were not showing as connected. And ergo, the VMs were without network connectivity.\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected.jpg\"><img class=\"aligncenter size-medium wp-image-5310\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected-300x65.jpg\" alt=\"\" width=\"300\" height=\"65\" /></a>\r\n\r\nSo the next step of course was to click connected and apply.  But to no avail this did not work.  The virtual NICs still would not connect and the device status did not change.  So the quick fix was to add a new vNIC and then reapply the IP settings at the OS level.  This worked fine for a few severs but would not scale well if we had to role out massive amounts of new VMs.  Which of course we  do for the up coming <a title=\"Carolina Technology Conference \" href=\"http://www.carolinatechnologyconference.com/\">Carolina Technology Conference</a>.\r\n\r\nSo, knowing we needed to change our core base image VM for our <a title=\"VMware View 5\" href=\"http://www.vmware.com/products/view/features.html\">VMware View 5</a> deployment, I started to do some digging.  It turns out that <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> is the culpret here and the problem was solved by excluding the following line in the .vmx file for the VM in question with a \"#\".\r\n\r\n#ethernet0.filter0.name = \"vshield-dvfilter-module\"\r\n\r\nNow of course comes the challenge of figuring how and why <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> managed to go hay wire during the upgrade.....','vSPHERE 5 UPGRADE QUIRKINESS. ','','publish','open','open','','vsphere-5-upgrade-quirkiness','','','2011-10-14 20:18:19','2011-10-14 20:18:19','',0,'http://egroup.jasonmangone.com/?p=5309',0,'post','',1),(5280,29,'2011-10-06 16:52:28','2011-10-06 16:52:28','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\nWatch the video below to find out more.\r\n\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-9','','','2011-10-06 16:52:28','2011-10-06 16:52:28','',5268,'http://egroup.jasonmangone.com/5268-revision-9',0,'revision','',0),(5283,29,'2011-10-06 16:58:43','2011-10-06 16:58:43','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\n\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-12','','','2011-10-06 16:58:43','2011-10-06 16:58:43','',5268,'http://egroup.jasonmangone.com/5268-revision-12',0,'revision','',0),(5281,29,'2011-10-06 16:57:20','2011-10-06 16:57:20','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n<p><a href=\"http://vimeo.com/30139705\">Source or Target Based Deduplication</a> from <a href=\"http://vimeo.com/user8807339\">John Flisher</a> on <a href=\"http://vimeo.com\">Vimeo</a>.</p>\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-10','','','2011-10-06 16:57:20','2011-10-06 16:57:20','',5268,'http://egroup.jasonmangone.com/5268-revision-10',0,'revision','',0),(5282,29,'2011-10-06 16:57:26','2011-10-06 16:57:26','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n<p><a href=\"http://vimeo.com/30139705\">Source or Target Based Deduplication</a> from <a href=\"http://vimeo.com/user8807339\">John Flisher</a> on <a href=\"http://vimeo.com\">Vimeo</a>.</p>\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-11','','','2011-10-06 16:57:26','2011-10-06 16:57:26','',5268,'http://egroup.jasonmangone.com/5268-revision-11',0,'revision','',0),(5284,29,'2011-10-06 19:12:36','2011-10-06 19:12:36','','AvarmarDDCap1','','inherit','open','open','','avarmarddcap1-2','','','2011-10-06 19:12:36','2011-10-06 19:12:36','',5268,'http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png',0,'attachment','image/png',0),(5285,29,'2011-10-06 19:20:54','2011-10-06 19:20:54','The question is often asked: “Which is better Target or Source based deduplicaiton?”\n\nThe answer: Both.\n\nWatch the video below to find out more.\nhttp://vimeo.com/30139705\n\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\n\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\"><img class=\"aligncenter size-medium wp-image-5284\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11-245x300.png\" alt=\"\" width=\"245\" height=\"300\" /></a><a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\">\n</a>\n\n&nbsp;\n\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-13','','','2011-10-06 19:20:54','2011-10-06 19:20:54','',5268,'http://egroup.jasonmangone.com/5268-revision-13',0,'revision','',0),(5286,29,'2011-10-06 19:20:59','2011-10-06 19:20:59','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\nhttp://vimeo.com/30139705\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\"><img class=\"aligncenter size-medium wp-image-5284\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11-245x300.png\" alt=\"\" width=\"245\" height=\"300\" /></a><a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\">\r\n</a>\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore the process is automated straight off the data domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-14','','','2011-10-06 19:20:59','2011-10-06 19:20:59','',5268,'http://egroup.jasonmangone.com/5268-revision-14',0,'revision','',0),(5287,29,'2011-10-17 19:41:55','2011-10-17 19:41:55','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\n\r\nhttp://vimeo.com/30139705\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\"><img class=\"aligncenter size-medium wp-image-5284\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11-245x300.png\" alt=\"\" width=\"245\" height=\"300\" /></a><a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\">\r\n</a>\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore, the process is automated straight off the Data Domain system without going through the Avamar Server.','SOURCE VS TARGET BASED DEDUPLICATION','','inherit','open','open','','5268-autosave','','','2011-10-17 19:41:55','2011-10-17 19:41:55','',5268,'http://egroup.jasonmangone.com/5268-autosave',0,'revision','',0),(5288,23,'2011-10-04 12:36:32','2011-10-04 12:36:32','','Auto Draft','','inherit','open','open','','5256-revision-v1','','','2011-10-04 12:36:32','2011-10-04 12:36:32','',5256,'http://egroup.jasonmangone.com/5256-revision',0,'revision','',0),(5318,12,'2011-12-16 14:27:58','0000-00-00 00:00:00','The \"journey to the cloud\" is a great tagline for helping customers go from a pure \"private cloud\" environment to a public or hybrid cloud solution.\r\n\r\n1. One of the first steps that most customers today are already at, is to virtualize the majority (if not all) of your workloads. Because of how common it is to find this already in place, I won\'t go into detail here.\r\n\r\n2. The second step once the systems are virtualized is to quantify the cost of the virtual machines and hardware powering them to establish a baseline and help determine the desired pricing to beat for a public cloud provider.\r\n\r\n3. Now here\'s where the nerd fun begins. At this step an important decision must be made to determine how you will deliver access to your data/applications to end users. This can be done through a simple VPN connection, in which the user accesses the data over an encrypted tunnel (though this is a really limited model). It can be done through a web portal or similar Content Management System-- something along the lines of SharePoint can suffice for basic office documents and the like. But where the real power/flexibility comes in is when you start delivering either the application itself, or a desktop that contains the desired application, to the user through a portal or client application. The biggest players here are Citrix, who can deliver the desktop and/or the application and VMware, who can deliver the desktop (worth pointing out that VMware requires ESXi as the hypervisor for this, Citrix supports ESXi, XenServer, and Hyper-V).\r\n\r\nThese solutions allow users to get to their data / applications securely and remotely (if allowed by your company) without issue, and offer a near native experience for most use cases. And depending on which solution you go with, you can provide your users with a desktop or application on many different devices-- including Macs, iPads, iPhones, Android phones, Blackberry phones, Android tablets, ChromeBooks, etc.\r\n\r\n4. So the users in the company can now access their applications and do their work remotely with limited reduction in efficiency or capability. What\'s next? Well at this point, you essentially have a \"private cloud\" and lots of capabilities. This step is optional, but when followed can provide the best level of education and lead to easier / better decisions when looking outside the company for cloud resources.\r\n\r\nThis step is all about cost reporting and monitoring. VMware offers their product, vCenter Chargeback, but any similar product will suffice here. The goal is to accurately calculate the cost for your environment to provide compute resources on your private cloud. When you have this information you can easily see what individual machines cost, how much an entire department costs if your company allows for departmental chargeback, and even help you forecast out what you\'ll need to spend to grow your environment. But more importantly, this helps you line up cost for YOUR resources so you can directly compare them against the cost of cloud resources.\r\n\r\n5. Using your calculated price for resources, start to identify cloud partners you can leverage for compute resources needed to grow or scale your environment.','A DIFFERENT JOURNEY TO THE HYBRID CLOUD ','','draft','open','open','','','','','2011-12-16 14:27:58','2011-12-16 14:27:58','',0,'http://egroup.jasonmangone.com/?p=5318',0,'post','',0),(5292,12,'2011-10-10 16:42:19','2011-10-10 16:42:19','One of the hot new features in XenApp 6.5 is Session Pre-launch, which aims to drastically reduce application load time in the eyes of the user (and I say it this way because it doesn\'t \"technically\" load them faster... well, read on).\r\n\r\nIn order to configure session pre-launch, you first publish an application like any other, with certain users, servers, etc. From here, you right click that application and choose \"Pre-Launch Application\", which automatically creates and enables pre-launch capabilities for that specific app. In the console, it creates a new application object with the prefix \"Pre-Launch\", and inherits the same settings you\'ve configured on the original application.\r\n\r\nWhen a user logs in to the Citrix Receiver, the configured application is automatically loaded up in the background, which successfully completes the process of logging in, running scripts, redirecting or roaming profiles, etc. This is all transparent to the user-- they don\'t even see the application. But if they click on the application that was originally created, it opens in the pre-launch session and in what appears to the user to be record time.\r\n\r\n<!--more-->\r\n\r\nAdditionally, if the user launches a different application, but one that is available on the same server that the pre-luanch session started, that application will also appear to be loaded in record time, as the session sharing functionality will use the existing pre-launch session and simply fire up a different application (but the scripts, profiles, etc. have already been loaded up).\r\n\r\nThe only real downside to this is that it immediately claims a license until the pre-launch sessions is closed out, which is configured via Citrix User Policies.\r\n\r\nOne policy, the Pre-Launch Disconnect Timer Interval, will disconnect the pre-launch session after the specified amount of time in minutes. The other policy, the Pre-Launch Terminate Timer Interval, will terminate the session after the specified time.\r\n\r\n&nbsp;','Citrix XenApp 6.5 - SESSION PRE-LAUNCH','','publish','open','open','','citrix-xenapp-6-5-session-pre-launch','','','2011-10-11 15:12:02','2011-10-11 15:12:02','',0,'http://egroup.jasonmangone.com/?p=5292',0,'post','',0),(5293,12,'2011-10-10 02:30:06','2011-10-10 02:30:06','One of the hot new features in XenApp 6.5 is Session Pre-launch, which aims to drastically reduce application load time in the eyes of the user.\n\nIn order to configure the session pre-launch, you first publish an application like any other, with certain users, servers, etc. From here, you can right click that application and go to \"Pre-Launch APplication\", which automatically creates and enables pre-launch capabilities for that specific app. In the console, it create a new application object with the prefix \"Pre-Launch\", and inherits the same settings you\'ve configured on the original application.\n\nWhen a user logs in to the Citrix farm, this application is automatically loaded up in the background, which successfully completes the process of logging in, running scripts, redirecting or roaming profiles ,etc. This is all transparent to the user-- they don\'t even see the application. But if they click on the application that was originally created, it opens within the pre-launch session and in what appears to the user to be record time.\n\nAdditionally, if the user launches a different application, but one that is available on the same server that the pre-luanch session started , that application will also be loaded in record time, as the session sharing functionality will use the existing session and simply launch a different application (but the scripts, profiles, etc. have already been loaded up).\n\nThe only real downside to this is that it immediately claims a license until the pre-luanch sessions is closed out, which is configured via Citrix User Policies.\n\nOne policy, the Pre-Launch Disconnect Timer Interval, will disconnect the pre-launch session after the specified amount of time in minutes. The other policy, the Pre-Launch Terminate Timer Interval,\n\n&nbsp;','XenApp 6.5 - SESSION PRE-LAUNCH','','inherit','open','open','','5292-revision','','','2011-10-10 02:30:06','2011-10-10 02:30:06','',5292,'http://egroup.jasonmangone.com/5292-revision',0,'revision','',0),(5294,12,'2011-10-10 02:31:52','2011-10-10 02:31:52','One of the hot new features in XenApp 6.5 is Session Pre-launch, which aims to drastically reduce application load time in the eyes of the user (and I say it this way because it doesn\'t load them any faster... well, read on).\n\nIn order to configure the session pre-launch, you first publish an application like any other, with certain users, servers, etc. From here, you can right click that application and go to \"Pre-Launch APplication\", which automatically creates and enables pre-launch capabilities for that specific app. In the console, it create a new application object with the prefix \"Pre-Launch\", and inherits the same settings you\'ve configured on the original application.\n\nWhen a user logs in to the Citrix farm, this application is automatically loaded up in the background, which successfully completes the process of logging in, running scripts, redirecting or roaming profiles ,etc. This is all transparent to the user-- they don\'t even see the application. But if they click on the application that was originally created, it opens within the pre-launch session and in what appears to the user to be record time.\n\nAdditionally, if the user launches a different application, but one that is available on the same server that the pre-luanch session started , that application will also be loaded in record time, as the session sharing functionality will use the existing session and simply launch a different application (but the scripts, profiles, etc. have already been loaded up).\n\nThe only real downside to this is that it immediately claims a license until the pre-luanch sessions is closed out, which is configured via Citrix User Policies.\n\nOne policy, the Pre-Launch Disconnect Timer Interval, will disconnect the pre-launch session after the specified amount of time in minutes. The other policy, the Pre-Launch Terminate Timer Interval, will terminate the session after the specified time.\n\n&nbsp;','Citrix XenApp 6.5 - SESSION PRE-LAUNCH','','inherit','open','open','','5292-revision-2','','','2011-10-10 02:31:52','2011-10-10 02:31:52','',5292,'http://egroup.jasonmangone.com/5292-revision-2',0,'revision','',0),(5295,12,'2011-10-10 02:33:05','2011-10-10 02:33:05','One of the hot new features in XenApp 6.5 is Session Pre-launch, which aims to drastically reduce application load time in the eyes of the user (and I say it this way because it doesn\'t load them any faster... well, read on).\n\nIn order to configure the session pre-launch, you first publish an application like any other, with certain users, servers, etc. From here, you can right click that application and go to \"Pre-Launch APplication\", which automatically creates and enables pre-launch capabilities for that specific app. In the console, it create a new application object with the prefix \"Pre-Launch\", and inherits the same settings you\'ve configured on the original application.\n\nWhen a user logs in to the Citrix farm, this application is automatically loaded up in the background, which successfully completes the process of logging in, running scripts, redirecting or roaming profiles ,etc. This is all transparent to the user-- they don\'t even see the application. But if they click on the application that was originally created, it opens within the pre-launch session and in what appears to the user to be record time.\n\nAdditionally, if the user launches a different application, but one that is available on the same server that the pre-luanch session started , that application will also be loaded in record time, as the session sharing functionality will use the existing session and simply launch a different application (but the scripts, profiles, etc. have already been loaded up).\n\nThe only real downside to this is that it immediately claims a license until the pre-luanch sessions is closed out, which is configured via Citrix User Policies.\n\nOne policy, the Pre-Launch Disconnect Timer Interval, will disconnect the pre-launch session after the specified amount of time in minutes. The other policy, the Pre-Launch Terminate Timer Interval, will terminate the session after the specified time.\n\n&nbsp;','Citrix XenApp 6.5 - SESSION PRE-LAUNCH','','inherit','open','open','','5292-revision-3','','','2011-10-10 02:33:05','2011-10-10 02:33:05','',5292,'http://egroup.jasonmangone.com/5292-revision-3',0,'revision','',0),(5296,12,'2011-10-10 16:41:35','2011-10-10 16:41:35','One of the hot new features in XenApp 6.5 is Session Pre-launch, which aims to drastically reduce application load time in the eyes of the user (and I say it this way because it doesn\'t load them any faster... well, read on).\n\nIn order to configure session pre-launch, you first publish an application like any other, with certain users, servers, etc. From here, you right click that application and choose \"Pre-Launch Application\", which automatically creates and enables pre-launch capabilities for that specific app. In the console, it creates a new application object with the prefix \"Pre-Launch\", and inherits the same settings you\'ve configured on the original application.\n\nWhen a user logs in to the Citrix Receiver, the configured application is automatically loaded up in the background, which successfully completes the process of logging in, running scripts, redirecting or roaming profiles, etc. This is all transparent to the user-- they don\'t even see the application. But if they click on the application that was originally created, it opens in the pre-launch session and in what appears to the user to be record time.\n\n<!--more-->\n\nAdditionally, if the user launches a different application, but one that is available on the same server that the pre-luanch session started, that application will also appear to be loaded in record time, as the session sharing functionality will use the existing pre-launch session and simply fire up a different application (but the scripts, profiles, etc. have already been loaded up).\n\nThe only real downside to this is that it immediately claims a license until the pre-luanch sessions is closed out, which is configured via Citrix User Policies.\n\nOne policy, the Pre-Launch Disconnect Timer Interval, will disconnect the pre-launch session after the specified amount of time in minutes. The other policy, the Pre-Launch Terminate Timer Interval, will terminate the session after the specified time.\n\n&nbsp;','Citrix XenApp 6.5 - SESSION PRE-LAUNCH','','inherit','open','open','','5292-revision-4','','','2011-10-10 16:41:35','2011-10-10 16:41:35','',5292,'http://egroup.jasonmangone.com/5292-revision-4',0,'revision','',0),(5297,23,'2011-10-10 18:15:36','2011-10-10 18:15:36','When you install SQL with Basic Management Tools, the installer does not allow you to go back and install the Complete Management Tools. The option will be grayed out.\r\n\r\nIn order to install the Complete Management Tools, insert the installation media for SQL, then open a command prompt and run the following...\r\n\r\n<strong>setup.exe\r\n/FEATURES=Tools /Q\r\n/INDICATEPROGRESS\r\n/ACTION=Install\r\n/INSTANCENAME=SQLSERVER2008R2Ent\r\n</strong><strong>/BROWSERSVCSTARTUPTYPE=Automatic\r\n/AGTSVCACCOUNT=”NT AUTHORITY\\NETWORK SERVICE”\r\n/IACCEPTSQLSERVERLICENSETERMS</strong>\r\n\r\nNote: Replace \"SQLSERVER2008R2Ent\" with the name of your instance.\r\nNote 2: The above command is for SQL 2008R2. SQL 2008 does not support the /IACCEPTSQLSERVERLICENSETERMS switch','SQL 2008 R2: INSTALL COMPLETE MANAGEMENT TOOLS OVER BASIC','','inherit','open','open','','5256-autosave-v1','','','2011-10-10 18:15:36','2011-10-10 18:15:36','',5256,'http://egroup.jasonmangone.com/5256-autosave',0,'revision','',0),(5298,23,'2011-10-09 16:49:00','2011-10-09 16:49:00','When you install SQL with Basic Management Tools, the installer does not allow you to go back and install the Complete Management Tools. The option will be grayed out.\r\n\r\nIn order to install the Complete Management Tools, insert the installation media for SQL, then open a command prompt and run the following...\r\n\r\n<strong>setup.exe /FEATURES=Tools /Q /INDICATEPROGRESS /ACTION=Install /INSTANCENAME=SQLSERVER2008R2Ent /BROWSERSVCSTARTUPTYPE=Automatic /AGTSVCACCOUNT=”NT AUTHORITY\\NETWORK SERVICE” /IACCEPTSQLSERVERLICENSETERMS</strong>\r\n\r\nNote: Replace \"SQLSERVER2008R2Ent\" with the name of your instance.\r\nNote 2: The above command is for SQL 2008R2. SQL 2008 does not support the /IACCEPTSQLSERVERLICENSETERMS switch','SQL 2008 R2: INSTALL COMPLETE MANAGEMENT TOOLS OVER BASIC','','inherit','open','open','','5256-revision-v1','','','2011-10-09 16:49:00','2011-10-09 16:49:00','',5256,'http://egroup.jasonmangone.com/5256-revision-3',0,'revision','',0),(5301,12,'2011-10-11 15:43:20','2011-10-11 15:43:20','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\n\nSo here it goes!\n\nThe goal here is simple-- minimize the cost of the horsepower needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage specifically for this image. And this is absolutely acceptable; a STRONG and highly available storage environment is critically important here and in all other virtualized environments. But again, the goal is to minimize the COST of the necessary horsepower the deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which is somewhat similar but specifically for bandwidth and end user experience optimization). The Intellicache technology leverages LOCAL disk drives in a XenServer host to \"offload\" disk operations from the storage array. Once the first virtual machine boots and begins to read against the master image, XenServer caches the master image data on the local disks configured for Intellicache, and future reads to the image are then satisfied locally. This tremendously reduces the IOPS load against your shared storage array.\n\nImagine 10 XenServers each hosting virtual desktops using MCS and leveraging Intellicache.  Instead of having all the disk operations taking place on a single LUN backed by a certain number of spindles, you\'re using the local disk drives in 10 XenServers and only communicating back out to the array when necessary. A huge shift in the workload-- from entirely consolidated, to a \"consolidated while shared\" model.\n\nAnd because the cost of local drives is more affordable than the drives in an Enterprise quality storage array, you can cut the CAPEX cost of your deployment (which is THE GOAL). You can even invest in solid state drives (they rock, by the way) for the local server and drive the performance that much higher, at a lower price point.\n\nIntellicache also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3. When a virtual desktop needs to read against the master image, the data is available and presented to it directly from the server its running on, which reduces the latency of that operation.\n\n&nbsp;','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-8','','','2011-10-11 15:43:20','2011-10-11 15:43:20','',5163,'http://egroup.jasonmangone.com/5163-revision-8',0,'revision','',0),(5302,12,'2011-10-11 15:44:31','2011-10-11 15:44:31','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\n\nSo here it goes!\n\nThe goal here is simple-- minimize the cost of the horsepower needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage specifically for this image. And this is absolutely acceptable; a STRONG and highly available storage environment is critically important here and in all other virtualized environments. But again, the goal is to minimize the COST of the necessary horsepower the deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which is somewhat similar but specifically for bandwidth and end user experience optimization). The Intellicache technology leverages LOCAL disk drives in a XenServer host to \"offload\" disk operations from the storage array. Once the first virtual machine boots and begins to read against the master image, XenServer caches the master image data on the local disks configured for Intellicache, and future reads to the image are then satisfied locally. This tremendously reduces the IOPS load against your shared storage array.\n\nImagine 10 XenServers each hosting virtual desktops using MCS and leveraging Intellicache.  Instead of having all the disk operations taking place on a single LUN backed by a certain number of spindles, you\'re using the local disk drives in 10 XenServers and only communicating back out to the array when necessary. A huge shift in the workload-- from entirely consolidated, to a \"consolidated while shared\" model.\n\nAnd because the cost of local drives is more affordable than the drives in an Enterprise quality storage array, you can cut the CAPEX cost of your deployment (which is THE GOAL). You can even invest in solid state drives (they rock, by the way) for the local servers and drive the performance that much higher, and stay at a lower price point.\n\nIntellicache also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3. When a virtual desktop needs to read against the master image, the data is available and presented to it directly from the server its running on, which reduces the latency of that operation.\n\n&nbsp;','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-9','','','2011-10-11 15:44:31','2011-10-11 15:44:31','',5163,'http://egroup.jasonmangone.com/5163-revision-9',0,'revision','',0),(5303,12,'2011-10-11 16:42:32','2011-10-11 16:42:32','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\n\nSo here it goes!\n\nThe goal here is simple-- minimize the cost of the horsepower needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage specifically for this image. And this is absolutely acceptable; a STRONG and highly available storage environment is critically important here and in all other virtualized environments. But again, the goal is to minimize the COST of the necessary horsepower the deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which is somewhat similar but specifically for bandwidth and end user experience optimization). The Intellicache technology leverages LOCAL disk drives in a XenServer host to \"offload\" disk operations from the storage array. Once the first virtual machine boots and begins to read against the master image, XenServer caches the master image data on the local disks configured for Intellicache, and future reads to the image are then satisfied locally. This tremendously reduces the IOPS load against your shared storage array.\n\nImagine 10 XenServers each hosting virtual desktops using MCS and leveraging Intellicache.  Instead of having all the disk operations taking place on a single LUN backed by a certain number of spindles, you\'re using the local disk drives in 10 XenServers and only communicating back out to the array when necessary. A huge shift in the workload-- from entirely consolidated, to a \"consolidated while shared\" model.\n\nAnd because the cost of local drives is more affordable than the drives in an Enterprise quality storage array, you can cut the CAPEX cost of your deployment (which is THE GOAL). You can even invest in solid state drives (they rock, by the way) for the local servers and drive the performance that much higher, and stay at a lower price point.\n\nIntellicache also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3. When a virtual desktop needs to read against the master image, the data is available and presented to it directly from the server its running on, which reduces the latency of that operation.\n\n<img class=\"aligncenter\" src=\"http://img641.imageshack.us/img641/2762/citrixxenserverintellic.png\" alt=\"\" width=\"873\" height=\"482\" />','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-10','','','2011-10-11 16:42:32','2011-10-11 16:42:32','',5163,'http://egroup.jasonmangone.com/5163-revision-10',0,'revision','',0),(5304,12,'2011-10-11 16:45:07','2011-10-11 16:45:07','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (see link here). One of our Citrix Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\n\nSo here it goes!\n\nThe goal here is simple-- minimize the cost of the horsepower needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage specifically for this image. And this is absolutely acceptable; a STRONG and highly available storage environment is critically important here and in all other virtualized environments. But again, the goal is to minimize the COST of the necessary horsepower the deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which is somewhat similar but specifically for bandwidth and end user experience optimization). The Intellicache technology leverages LOCAL disk drives in a XenServer host to \"offload\" disk operations from the storage array. Once the first virtual machine boots and begins to read against the master image, XenServer caches the master image data on the local disks configured for Intellicache, and future reads to the image are then satisfied locally. This tremendously reduces the IOPS load against your shared storage array.\n\nImagine 10 XenServers each hosting virtual desktops using MCS and leveraging Intellicache.  Instead of having all the disk operations taking place on a single LUN backed by a certain number of spindles, you\'re using the local disk drives in 10 XenServers and only communicating back out to the array when necessary. A huge shift in the workload-- from entirely consolidated, to a \"consolidated while shared\" model.\n\nAnd because the cost of local drives is more affordable than the drives in an Enterprise quality storage array, you can cut the CAPEX cost of your deployment (which is THE GOAL). You can even invest in solid state drives (they rock, by the way) for the local servers and drive the performance that much higher, and stay at a lower price point.\n\nIntellicache also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3. When a virtual desktop needs to read against the master image, the data is available and presented to it directly from the server its running on, which reduces the latency of that operation.\n\n<img class=\"aligncenter\" src=\"http://img641.imageshack.us/img641/2762/citrixxenserverintellic.png\" alt=\"\" width=\"873\" height=\"482\" />','Citrix Intellicache FOR MCS - HOW IT REDUCES IOPS REQUIREMENT','','inherit','open','open','','5163-revision-11','','','2011-10-11 16:45:07','2011-10-11 16:45:07','',5163,'http://egroup.jasonmangone.com/5163-revision-11',0,'revision','',0),(5305,12,'2011-10-14 12:17:00','2011-10-14 12:17:00','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (<a href=\"http://egroup.jasonmangone.com/how-citrix-provisioning-services-reduces-iops\" target=\"_blank\">see link here</a>). One of our Citrix Sales Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\n\nSo here it goes!\n\nThe goal here is simple-- minimize the cost of the horsepower needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage specifically for this image. And this is perfectly acceptable; a STRONG and highly available storage environment is critically important here and in all other virtualized environments. But again, the goal is to minimize the COST of the necessary horsepower the deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which is somewhat similar but specifically for bandwidth and end user experience optimization). The Intellicache technology leverages LOCAL disk drives in a XenServer host to \"offload\" disk operations from the storage array. Once the first virtual machine boots and begins to read against the master image, a XenServer host caches the master image data on the LOCAL hard disks configured for Intellicache, and future reads to the image are then satisfied locally. This tremendously reduces the IOPS load against your shared storage array.\n\nImagine 10 XenServers each hosting virtual desktops using MCS and leveraging Intellicache.  Instead of having all the disk operations taking place on a single LUN backed by a certain number of spindles, you\'re using the local disk drives in 10 XenServers and only communicating back out to the array when necessary. A huge shift in the workload-- from entirely consolidated, to a \"consolidated while shared\" model.\n\nAnd because the cost of local drives is more affordable than the drives in an Enterprise quality storage array, you can cut the CAPEX cost of your deployment (which is THE GOAL). You can even invest in solid state drives (they rock, by the way) for the local servers and drive the performance that much higher, and stay at a lower price point.\n\nIntellicache also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3. When a virtual desktop needs to read against the master image, the data is available and presented to it directly from the server its running on, which reduces the latency of that operation, and because it doesn\'t have to go \"out on the wire\", the bandwidth used is minimized.\n\n<img class=\"aligncenter\" src=\"http://img641.imageshack.us/img641/2762/citrixxenserverintellic.png\" alt=\"\" width=\"873\" height=\"482\" />','Citrix Intellicache FOR MCS - HOW IT REDUCES COST OF VDI DEPLOYMENT','','inherit','open','open','','5163-revision-12','','','2011-10-14 12:17:00','2011-10-14 12:17:00','',5163,'http://egroup.jasonmangone.com/5163-revision-12',0,'revision','',0),(5306,12,'2011-10-14 12:18:00','2011-10-14 12:18:00','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (<a href=\"http://egroup.jasonmangone.com/how-citrix-provisioning-services-reduces-iops\" target=\"_blank\">see link here</a>). One of our Citrix Sales Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\n\nSo here it goes!\n\nThe goal here is simple-- minimize the cost of the horsepower needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage specifically for this image. And this is perfectly acceptable; a STRONG and highly available storage environment is critically important here and in all other virtualized environments. But again, the goal is to minimize the COST of the necessary horsepower the deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which is somewhat similar but specifically for bandwidth and end user experience optimization). The Intellicache technology leverages LOCAL disk drives in a XenServer host to \"offload\" disk operations from the storage array. Once the first virtual machine boots and begins to read against the master image, a XenServer host caches the master image data on the LOCAL hard disks configured for Intellicache, and future reads to the image are then satisfied locally. This tremendously reduces the IOPS load against your shared storage array.\n\nImagine 10 XenServers each hosting virtual desktops using MCS and leveraging Intellicache.  Instead of having all the disk operations taking place on a single LUN backed by a certain number of spindles, you\'re using the local disk drives in 10 XenServers and only communicating back out to the array when necessary. A huge shift in the workload-- from entirely consolidated, to a \"consolidated while shared\" model.\n\n<!--more-->\n\nAnd because the cost of local drives is more affordable than the drives in an Enterprise quality storage array, you can cut the CAPEX cost of your deployment (which is THE GOAL). You can even invest in solid state drives (they rock, by the way) for the local servers and drive the performance that much higher, and stay at a lower price point.\n\nIntellicache also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3. When a virtual desktop needs to read against the master image, the data is available and presented to it directly from the server its running on, which reduces the latency of that operation, and because it doesn\'t have to go \"out on the wire\", the bandwidth used is minimized.\n\n<img class=\"aligncenter\" src=\"http://img641.imageshack.us/img641/2762/citrixxenserverintellic.png\" alt=\"\" width=\"873\" height=\"482\" />','Citrix Intellicache FOR MCS - HOW IT REDUCES COST OF VDI DEPLOYMENT','','inherit','open','open','','5163-revision-13','','','2011-10-14 12:18:00','2011-10-14 12:18:00','',5163,'http://egroup.jasonmangone.com/5163-revision-13',0,'revision','',0),(5307,12,'2011-10-14 12:19:07','2011-10-14 12:19:07','I recently posted on how Provisioning Server helps to offload and reduce the amount of IOPS your underlying storage needs to support in order to maintain sufficient performance of your XenDesktop VDI deployments (<a href=\"http://egroup.jasonmangone.com/how-citrix-provisioning-services-reduces-iops\" target=\"_blank\">see link here</a>). One of our Citrix Sales Engineers asked me to also cover MCS and to explain how Citrix is actively working to achieve the same kind of results even when using MCS and a \"master image\" VM.\n\nSo here it goes!\n\nThe goal here is simple-- minimize the cost of the horsepower needed for the underlying storage in a XenDesktop VDI deployment. As described in the PVS post linked above, the \"issue\" with things like Citrix\'s MCS or VMware\'s Linked Clone technology is that it relies on a \"master image\", and that image gets pounded with IO. To work through this, lots of customers invest heavily in their underlying storage specifically for this image. And this is perfectly acceptable; a STRONG and highly available storage environment is critically important here and in all other virtualized environments. But again, the goal is to minimize the COST of the necessary horsepower the deployment.\n\nThis is where Citrix\'s XenServer Intellicache comes into play (not to be confused with HDX Intellicache, which is somewhat similar but specifically for bandwidth and end user experience optimization). The Intellicache technology leverages LOCAL disk drives in a XenServer host to \"offload\" disk operations from the storage array. Once the first virtual machine boots and begins to read against the master image, a XenServer host caches the master image data on the LOCAL hard disks configured for Intellicache, and future reads to the image are then satisfied locally. This tremendously reduces the IOPS load against your shared storage array.\n\nImagine 10 XenServers each hosting virtual desktops using MCS and leveraging Intellicache.  Instead of having all the disk operations taking place on a single LUN backed by a certain number of spindles, you\'re using the local disk drives in 10 XenServers and only communicating back out to the array when necessary. A huge shift in the workload-- from entirely consolidated, to a \"consolidated while shared\" model.\n\n<!--more-->\n\nAnd because the cost of local drives is more affordable than the drives in an Enterprise quality storage array, you can cut the CAPEX cost of your deployment (which is THE GOAL). You can even invest in solid state drives (they rock, by the way) for the local servers and drive the performance that much higher, and stay at a lower price point.\n\nIntellicache also offloads and reduces the consumption of bandwidth on the storage network-- and if you use NAS for your shared storage with support for NFSv3, this can help you overcome the \"single TCP session\" limitation of NFSv3. When a virtual desktop needs to read against the master image, the data is available and presented to it directly from the server its running on, which reduces the latency of that operation, and because it doesn\'t have to go \"out on the wire\", the bandwidth used is minimized.\n\n<img class=\"aligncenter\" src=\"http://img641.imageshack.us/img641/2762/citrixxenserverintellic.png\" alt=\"\" width=\"873\" height=\"482\" />','Citrix Intellicache FOR MCS - HOW IT REDUCES COST OF VDI DEPLOYMENT','','inherit','open','open','','5163-autosave','','','2011-10-14 12:19:07','2011-10-14 12:19:07','',5163,'http://egroup.jasonmangone.com/5163-autosave',0,'revision','',0),(5311,29,'2011-10-14 19:44:45','2011-10-14 19:44:45','We ran into some trouble on a few VMs in our LAB after we upgarded to vSphere 5.   For some reason once powered on  the VM NICs were not showing as connected. And ergo, the VMs were without network connectivity.\n\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected.jpg\"><img class=\"aligncenter size-medium wp-image-5310\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected-300x65.jpg\" alt=\"\" width=\"300\" height=\"65\" /></a>\n\n&nbsp;\n\n&nbsp;\n\nSo the next step of course was to click connected and apply.  But to no avail this did not work.  The virtual NICs still would not connect and the device status did not change.  So the quick fix was to add a new vNIC and then reapply the IP settings at the OS level.  This worked fine  for a few severs but would not scale well if we had to role out massive amounts of new VMs.  Which of course we  do for the up coming <a title=\"Carolina Technology Conference \" href=\"http://www.carolinatechnologyconference.com/\">Carolina Technology Conference</a>.\n\nSo, knowing we needed to change our core base image VM for our <a title=\"VMware View 5\" href=\"http://www.vmware.com/products/view/features.html\">VMware View 5</a> deployment, I started to do some digging.  It turns out that <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> is the culpret here and the problem was solved by excluding the following line in the .vmx file for the VM in question with a \"#\".\n\n#ethernet0.filter0.name = \"vshield-dvfilter-module\"\n\nNow of course comes the challenge of figuring how and why <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> managed to go hay wire during the upgrade.....','vSphere 5 Upgrade quirkiness. ','','inherit','open','open','','5309-revision','','','2011-10-14 19:44:45','2011-10-14 19:44:45','',5309,'http://egroup.jasonmangone.com/5309-revision',0,'revision','',0),(5312,29,'2011-10-14 20:12:46','2011-10-14 20:12:46','We ran into some trouble on a few VMs in our LAB after we upgarded to vSphere 5.   For some reason once powered on  the VM NICs were not showing as connected. And ergo, the VMs were without network connectivity.\n\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected.jpg\"><img class=\"aligncenter size-medium wp-image-5310\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected-300x65.jpg\" alt=\"\" width=\"300\" height=\"65\" /></a>\n\nSo the next step of course was to click connected and apply.  But to no avail this did not work.  The virtual NICs still would not connect and the device status did not change.  So the quick fix was to add a new vNIC and then reapply the IP settings at the OS level.  This worked fine  for a few severs but would not scale well if we had to role out massive amounts of new VMs.  Which of course we  do for the up coming <a title=\"Carolina Technology Conference \" href=\"http://www.carolinatechnologyconference.com/\">Carolina Technology Conference</a>.\n\nSo, knowing we needed to change our core base image VM for our <a title=\"VMware View 5\" href=\"http://www.vmware.com/products/view/features.html\">VMware View 5</a> deployment, I started to do some digging.  It turns out that <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> is the culpret here and the problem was solved by excluding the following line in the .vmx file for the VM in question with a \"#\".\n\n#ethernet0.filter0.name = \"vshield-dvfilter-module\"\n\nNow of course comes the challenge of figuring how and why <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> managed to go hay wire during the upgrade.....','vSPHERE 5 UPGRADE QUIRKINESS. ','','inherit','open','open','','5309-autosave','','','2011-10-14 20:12:46','2011-10-14 20:12:46','',5309,'http://egroup.jasonmangone.com/5309-autosave',0,'revision','',0),(5313,29,'2011-10-14 19:46:21','2011-10-14 19:46:21','We ran into some trouble on a few VMs in our LAB after we upgarded to vSphere 5.   For some reason once powered on  the VM NICs were not showing as connected. And ergo, the VMs were without network connectivity.\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected.jpg\"><img class=\"aligncenter size-medium wp-image-5310\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected-300x65.jpg\" alt=\"\" width=\"300\" height=\"65\" /></a>\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\nSo the next step of course was to click connected and apply.  But to no avail this did not work.  The virtual NICs still would not connect and the device status did not change.  So the quick fix was to add a new vNIC and then reapply the IP settings at the OS level.  This worked fine  for a few severs but would not scale well if we had to role out massive amounts of new VMs.  Which of course we  do for the up coming <a title=\"Carolina Technology Conference \" href=\"http://www.carolinatechnologyconference.com/\">Carolina Technology Conference</a>.\r\n\r\nSo, knowing we needed to change our core base image VM for our <a title=\"VMware View 5\" href=\"http://www.vmware.com/products/view/features.html\">VMware View 5</a> deployment, I started to do some digging.  It turns out that <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> is the culpret here and the problem was solved by excluding the following line in the .vmx file for the VM in question with a \"#\".\r\n\r\n#ethernet0.filter0.name = \"vshield-dvfilter-module\"\r\n\r\nNow of course comes the challenge of figuring how and why <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> managed to go hay wire during the upgrade.....','vSphere 5 Upgrade quirkiness. ','','inherit','open','open','','5309-revision-2','','','2011-10-14 19:46:21','2011-10-14 19:46:21','',5309,'http://egroup.jasonmangone.com/5309-revision-2',0,'revision','',0),(5314,29,'2011-10-14 19:48:43','2011-10-14 19:48:43','We ran into some trouble on a few VMs in our LAB after we upgarded to vSphere 5.   For some reason once powered on  the VM NICs were not showing as connected. And ergo, the VMs were without network connectivity.\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected.jpg\"><img class=\"aligncenter size-medium wp-image-5310\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected-300x65.jpg\" alt=\"\" width=\"300\" height=\"65\" /></a>\r\n\r\nSo the next step of course was to click connected and apply.  But to no avail this did not work.  The virtual NICs still would not connect and the device status did not change.  So the quick fix was to add a new vNIC and then reapply the IP settings at the OS level.  This worked fine  for a few severs but would not scale well if we had to role out massive amounts of new VMs.  Which of course we  do for the up coming <a title=\"Carolina Technology Conference \" href=\"http://www.carolinatechnologyconference.com/\">Carolina Technology Conference</a>.\r\n\r\nSo, knowing we needed to change our core base image VM for our <a title=\"VMware View 5\" href=\"http://www.vmware.com/products/view/features.html\">VMware View 5</a> deployment, I started to do some digging.  It turns out that <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> is the culpret here and the problem was solved by excluding the following line in the .vmx file for the VM in question with a \"#\".\r\n\r\n#ethernet0.filter0.name = \"vshield-dvfilter-module\"\r\n\r\nNow of course comes the challenge of figuring how and why <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> managed to go hay wire during the upgrade.....','vSphere 5 Upgrade quirkiness. ','','inherit','open','open','','5309-revision-3','','','2011-10-14 19:48:43','2011-10-14 19:48:43','',5309,'http://egroup.jasonmangone.com/5309-revision-3',0,'revision','',0),(5315,29,'2011-10-06 19:22:43','2011-10-06 19:22:43','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\nhttp://vimeo.com/30139705\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\"><img class=\"aligncenter size-medium wp-image-5284\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11-245x300.png\" alt=\"\" width=\"245\" height=\"300\" /></a><a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\">\r\n</a>\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore, the process is automated straight off the Data Domain system without going through the Avamar Server.','Source VS Target Based Deduplication ','','inherit','open','open','','5268-revision-15','','','2011-10-06 19:22:43','2011-10-06 19:22:43','',5268,'http://egroup.jasonmangone.com/5268-revision-15',0,'revision','',0),(5316,29,'2011-10-14 20:13:25','2011-10-14 20:13:25','We ran into some trouble on a few VMs in our LAB after we upgarded to vSphere 5.   For some reason once powered on  the VM NICs were not showing as connected. And ergo, the VMs were without network connectivity.\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected.jpg\"><img class=\"aligncenter size-medium wp-image-5310\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/notConnected-300x65.jpg\" alt=\"\" width=\"300\" height=\"65\" /></a>\r\n\r\nSo the next step of course was to click connected and apply.  But to no avail this did not work.  The virtual NICs still would not connect and the device status did not change.  So the quick fix was to add a new vNIC and then reapply the IP settings at the OS level.  This worked fine  for a few severs but would not scale well if we had to role out massive amounts of new VMs.  Which of course we  do for the up coming <a title=\"Carolina Technology Conference \" href=\"http://www.carolinatechnologyconference.com/\">Carolina Technology Conference</a>.\r\n\r\nSo, knowing we needed to change our core base image VM for our <a title=\"VMware View 5\" href=\"http://www.vmware.com/products/view/features.html\">VMware View 5</a> deployment, I started to do some digging.  It turns out that <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> is the culpret here and the problem was solved by excluding the following line in the .vmx file for the VM in question with a \"#\".\r\n\r\n#ethernet0.filter0.name = \"vshield-dvfilter-module\"\r\n\r\nNow of course comes the challenge of figuring how and why <a title=\"vShield\" href=\"http://www.vmware.com/products/vshield/overview.html\">vShield</a> managed to go hay wire during the upgrade.....','vSPHERE 5 UPGRADE QUIRKINESS. ','','inherit','open','open','','5309-revision-4','','','2011-10-14 20:13:25','2011-10-14 20:13:25','',5309,'http://egroup.jasonmangone.com/5309-revision-4',0,'revision','',0),(5319,12,'2011-10-17 13:03:37','2011-10-17 13:03:37','The \"journey to the cloud\" is a great tagline for helping customers go from a pure \"private cloud\" environment to a public or hybrid cloud solution.\n\nOne of the first steps that most customers today are already at, is to virtualize the majority (if not all) of your workloads. Because of how common it is to find this already in place, I won\'t go into detail here. The second step once the systems are virtualized is to quantify the cost of the virtual machines and hardware powering them to establish a baseline and help determine the price','A DIFFERENT JOURNEY TO THE HYBRID CLOUD ','','inherit','open','open','','5318-revision','','','2011-10-17 13:03:37','2011-10-17 13:03:37','',5318,'http://egroup.jasonmangone.com/5318-revision',0,'revision','',0),(5360,2,'2011-10-25 15:07:50','2011-10-25 15:07:50','','Football Image LARGER DATES FOR INVITE copy','','inherit','open','open','','football-image-larger-dates-for-invite-copy','','','2011-10-25 15:07:50','2011-10-25 15:07:50','',0,'http://egroup.jasonmangone.com/wp-content/uploads/2011/10/Football-Image-LARGER-DATES-FOR-INVITE-copy.jpg',0,'attachment','image/jpeg',0),(5321,12,'2011-10-17 14:54:59','2011-10-17 14:54:59','The \"journey to the cloud\" is a great tagline for helping customers go from a pure \"private cloud\" environment to a public or hybrid cloud solution.\n\nOne of the first steps that most customers today are already at, is to virtualize the majority (if not all) of your workloads. Because of how common it is to find this already in place, I won\'t go into detail here. The second step once the systems are virtualized is to quantify the cost of the virtual machines and hardware powering them to establish a baseline and help determine the desired pricing to beat for a public cloud provider.\n\nNow here\'s where the nerd fun begins. At this step, number three if you\'re following along, an important decision must be made to determine how you will deliver access to your data/applications to end users. This can be done through a simple VPN connection, in which the user accesses the data over an encrypted tunnel (though this is a really limited model). It can be done through a web portal or similar Content Management System-- something along the lines of SharePoint can suffice for basic office documents and the like. But where the real power/flexibility comes in is when you start delivering either the application, or a desktop, to the user through a portal or client application. The biggest players here are Citrix, which can deliver the desktop,','A DIFFERENT JOURNEY TO THE HYBRID CLOUD ','','inherit','open','open','','5318-revision-2','','','2011-10-17 14:54:59','2011-10-17 14:54:59','',5318,'http://egroup.jasonmangone.com/5318-revision-2',0,'revision','',0),(5322,12,'2011-10-17 17:00:39','2011-10-17 17:00:39','The \"journey to the cloud\" is a great tagline for helping customers go from a pure \"private cloud\" environment to a public or hybrid cloud solution.\n\nOne of the first steps that most customers today are already at, is to virtualize the majority (if not all) of your workloads. Because of how common it is to find this already in place, I won\'t go into detail here. The second step once the systems are virtualized is to quantify the cost of the virtual machines and hardware powering them to establish a baseline and help determine the desired pricing to beat for a public cloud provider.\n\nNow here\'s where the nerd fun begins. At this step, number three if you\'re following along, an important decision must be made to determine how you will deliver access to your data/applications to end users. This can be done through a simple VPN connection, in which the user accesses the data over an encrypted tunnel (though this is a really limited model). It can be done through a web portal or similar Content Management System-- something along the lines of SharePoint can suffice for basic office documents and the like. But where the real power/flexibility comes in is when you start delivering either the application itself, or a desktop that contains the desired application, to the user through a portal or client application. The biggest players here are Citrix, who can deliver the desktop and/or the application and VMware, who today can deliver the desktop.\n\n&nbsp;','A DIFFERENT JOURNEY TO THE HYBRID CLOUD ','','inherit','open','open','','5318-revision-3','','','2011-10-17 17:00:39','2011-10-17 17:00:39','',5318,'http://egroup.jasonmangone.com/5318-revision-3',0,'revision','',0),(5323,12,'2011-10-17 17:38:32','2011-10-17 17:38:32','The \"journey to the cloud\" is a great tagline for helping customers go from a pure \"private cloud\" environment to a public or hybrid cloud solution.\n\nOne of the first steps that most customers today are already at, is to virtualize the majority (if not all) of your workloads. Because of how common it is to find this already in place, I won\'t go into detail here. The second step once the systems are virtualized is to quantify the cost of the virtual machines and hardware powering them to establish a baseline and help determine the desired pricing to beat for a public cloud provider.\n\nNow here\'s where the nerd fun begins. At this step, number three if you\'re following along, an important decision must be made to determine how you will deliver access to your data/applications to end users. This can be done through a simple VPN connection, in which the user accesses the data over an encrypted tunnel (though this is a really limited model). It can be done through a web portal or similar Content Management System-- something along the lines of SharePoint can suffice for basic office documents and the like. But where the real power/flexibility comes in is when you start delivering either the application itself, or a desktop that contains the desired application, to the user through a portal or client application. The biggest players here are Citrix, who can deliver the desktop and/or the application and VMware, who can deliver the desktop (worth pointing out that VMware requires ESXi as the hypervisor for this).\n\nThese solutions allow users to get to their data / applications securely and remotely (if allowed by your company) without issue, and offer a near native experience for most use cases. Now if a hurricane comes and displaces your users, they can remotely log in from wherever they\'v','A DIFFERENT JOURNEY TO THE HYBRID CLOUD ','','inherit','open','open','','5318-revision-4','','','2011-10-17 17:38:32','2011-10-17 17:38:32','',5318,'http://egroup.jasonmangone.com/5318-revision-4',0,'revision','',0),(5325,29,'2011-10-14 20:15:01','2011-10-14 20:15:01','The question is often asked: “Which is better Target or Source based deduplicaiton?”\r\n\r\nThe answer: Both.\r\n\r\nWatch the video below to find out more.\r\nhttp://vimeo.com/30139705\r\n\r\nBelow is a screen shot that shows a Data Domain system being selected as the backup target from the Avamar Admin Console.\r\n\r\n<a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\"><img class=\"aligncenter size-medium wp-image-5284\" src=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11-245x300.png\" alt=\"\" width=\"245\" height=\"300\" /></a><a href=\"http://egroup.jasonmangone.com/wp-content/uploads/2011/10/AvarmarDDCap11.png\">\r\n</a>\r\n\r\n&nbsp;\r\n\r\nAlso to note, the metadata for the Data Domain backup data sets are sent to the Avamar server so when a client needs to restore, the process is automated straight off the Data Domain system without going through the Avamar Server.','SOURCE VS TARGET BASED DEDUPLICATION','','inherit','open','open','','5268-revision-16','','','2011-10-14 20:15:01','2011-10-14 20:15:01','',5268,'http://egroup.jasonmangone.com/5268-revision-16',0,'revision','',0),(5326,12,'2011-10-17 17:40:56','2011-10-17 17:40:56','The \"journey to the cloud\" is a great tagline for helping customers go from a pure \"private cloud\" environment to a public or hybrid cloud solution.\n\nOne of the first steps that most customers today are already at, is to virtualize the majority (if not all) of your workloads. Because of how common it is to find this already in place, I won\'t go into detail here. The second step once the systems are virtualized is to quantify the cost of the virtual machines and hardware powering them to establish a baseline and help determine the desired pricing to beat for a public cloud provider.\n\nNow here\'s where the nerd fun begins. At this step, number three if you\'re following along, an important decision must be made to determine how you will deliver access to your data/applications to end users. This can be done through a simple VPN connection, in which the user accesses the data over an encrypted tunnel (though this is a really limited model). It can be done through a web portal or similar Content Management System-- something along the lines of SharePoint can suffice for basic office documents and the like. But where the real power/flexibility comes in is when you start delivering either the application itself, or a desktop that contains the desired application, to the user through a portal or client application. The biggest players here are Citrix, who can deliver the desktop and/or the application and VMware, who can deliver the desktop (worth pointing out that VMware requires ESXi as the hypervisor for this).\n\nThese solutions allow users to get to their data / applications securely and remotely (if allowed by your company) without issue, and offer a near native experience for most use cases. And depending on which solution you go with, you can provide your users with a desktop or application on many different devices-- including Macs, iPads, iPhones, Android phones, Blackberry phones, Android tablets, ChromeBooks, etc.','A DIFFERENT JOURNEY TO THE HYBRID CLOUD ','','inherit','open','open','','5318-revision-5','','','2011-10-17 17:40:56','2011-10-17 17:40:56','',5318,'http://egroup.jasonmangone.com/5318-revision-5',0,'revision','',0),(5327,12,'2011-10-20 19:31:42','2011-10-20 19:31:42','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some virtual interfaces.\r\n\r\nFirst, we had to shut down the server and assign it an address for use with CIMC so we could hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\r\n\r\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\r\n\r\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got our CIMC to the 1.2.x code desired. Finally.\r\n\r\n<!--more-->\r\n\r\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\r\n\r\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\r\n\r\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\r\n\r\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\r\n\r\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing vNIC/vHBA or add a new one, set the properties as desired, and fire up the server.\r\n\r\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\r\n\r\nOne additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\r\n\r\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','publish','open','open','','cisco-ucs-c-series-p81e-vic-adding-virtual-interfaces','','','2011-10-20 20:13:20','2011-10-20 20:13:20','',0,'http://egroup.jasonmangone.com/?p=5327',0,'post','',1),(5328,12,'2011-10-20 15:38:06','2011-10-20 15:38:06','I had the pleasure of spending time yesterday evening with a great customer in the Carolians (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve u','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision','','','2011-10-20 15:38:06','2011-10-20 15:38:06','',5327,'http://egroup.jasonmangone.com/5327-revision',0,'revision','',0),(5329,12,'2011-10-20 16:30:18','2011-10-20 16:30:18','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces. First thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly.\n\nOnce this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater, and I\'ll explain why a little later. On the Cisco website when downloading the latest firmware, all that as offered for the 1.4 version was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab.','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-2','','','2011-10-20 16:30:18','2011-10-20 16:30:18','',5327,'http://egroup.jasonmangone.com/5327-revision-2',0,'revision','',0),(5330,12,'2011-10-20 16:30:33','2011-10-20 16:30:33','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces. First thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly.\r\n\r\nOnce this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater, and I\'ll explain why a little later. On the Cisco website when downloading the latest firmware, all that as offered for the 1.4 version was the Cisco Host Update Utility, which downloads as an ISO.\r\n\r\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\r\n\r\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\r\n\r\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab.','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-3','','','2011-10-20 16:30:33','2011-10-20 16:30:33','',5327,'http://egroup.jasonmangone.com/5327-revision-3',0,'revision','',0),(5331,12,'2011-10-20 16:32:56','2011-10-20 16:32:56','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces. First thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly.\n\nOnce this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater, and I\'ll explain why a little later. On the Cisco website when downloading the latest firmware, all that as offered for the 1.4 version was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-4','','','2011-10-20 16:32:56','2011-10-20 16:32:56','',5327,'http://egroup.jasonmangone.com/5327-revision-4',0,'revision','',0),(5332,12,'2011-10-20 16:33:24','2011-10-20 16:33:24','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces. First thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly.\r\n\r\nOnce this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater, and I\'ll explain why a little later. On the Cisco website when downloading the latest firmware, all that as offered for the 1.4 version was the Cisco Host Update Utility, which downloads as an ISO.\r\n\r\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\r\n\r\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\r\n\r\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\r\n\r\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\r\n\r\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\r\n\r\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-5','','','2011-10-20 16:33:24','2011-10-20 16:33:24','',5327,'http://egroup.jasonmangone.com/5327-revision-5',0,'revision','',0),(5333,12,'2011-10-20 16:33:27','2011-10-20 16:33:27','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces. First thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly.\r\n\r\nOnce this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater, and I\'ll explain why a little later. On the Cisco website when downloading the latest firmware, all that as offered for the 1.4 version was the Cisco Host Update Utility, which downloads as an ISO.\r\n\r\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\r\n\r\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\r\n\r\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\r\n\r\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\r\n\r\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\r\n\r\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-6','','','2011-10-20 16:33:27','2011-10-20 16:33:27','',5327,'http://egroup.jasonmangone.com/5327-revision-6',0,'revision','',0),(5335,12,'2011-10-20 16:42:20','2011-10-20 16:42:20','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces.\n\nFirst thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\n\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. One additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs will be in flight at once).\n\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-8','','','2011-10-20 16:42:20','2011-10-20 16:42:20','',5327,'http://egroup.jasonmangone.com/5327-revision-8',0,'revision','',0),(5334,12,'2011-10-20 16:40:19','2011-10-20 16:40:19','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces. First thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly.\n\nOnce this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater, and I\'ll explain why a little later. On the Cisco website when downloading the latest firmware, all that as offered for the 1.4 version was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\n\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. One additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs will be in flight at once).\n\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-7','','','2011-10-20 16:40:19','2011-10-20 16:40:19','',5327,'http://egroup.jasonmangone.com/5327-revision-7',0,'revision','',0),(5337,12,'2011-10-20 16:47:13','2011-10-20 16:47:13','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces.\n\nFirst thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\n\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. One additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\n\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-10','','','2011-10-20 16:47:13','2011-10-20 16:47:13','',5327,'http://egroup.jasonmangone.com/5327-revision-10',0,'revision','',0),(5336,12,'2011-10-20 16:45:00','2011-10-20 16:45:00','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces.\r\n\r\nFirst thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\r\n\r\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\r\n\r\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\r\n\r\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\r\n\r\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\r\n\r\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\r\n\r\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\r\n\r\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. One additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs will be in flight at once).\r\n\r\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\r\n\r\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-9','','','2011-10-20 16:45:00','2011-10-20 16:45:00','',5327,'http://egroup.jasonmangone.com/5327-revision-9',0,'revision','',0),(5338,12,'2011-10-20 17:28:45','2011-10-20 17:28:45','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces.\n\nFirst thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\n\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing one or add a new one, set the properties as desired, and fire up the server.\n\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\n\nOne additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-11','','','2011-10-20 17:28:45','2011-10-20 17:28:45','',5327,'http://egroup.jasonmangone.com/5327-revision-11',0,'revision','',0),(5339,12,'2011-10-20 17:34:58','2011-10-20 17:34:58','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces.\n\nFirst thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\n&nbsp;\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\n\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing vNIC/vHBA or add a new one, set the properties as desired, and fire up the server.\n\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\n\nOne additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-12','','','2011-10-20 17:34:58','2011-10-20 17:34:58','',5327,'http://egroup.jasonmangone.com/5327-revision-12',0,'revision','',0),(5340,12,'2011-10-20 17:36:02','2011-10-20 17:36:02','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces.\n\nFirst thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\n<!--more-->\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\n\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing vNIC/vHBA or add a new one, set the properties as desired, and fire up the server.\n\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\n\nOne additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-13','','','2011-10-20 17:36:02','2011-10-20 17:36:02','',5327,'http://egroup.jasonmangone.com/5327-revision-13',0,'revision','',0),(5342,2,'2011-10-20 19:29:56','2011-10-20 19:29:56','','Football Image copy','','inherit','open','open','','football-image-copy','','','2011-10-20 19:29:56','2011-10-20 19:29:56','',0,'http://egroup.jasonmangone.com/wp-content/uploads/2011/10/Football-Image-copy.jpg',0,'attachment','image/jpeg',0),(5343,12,'2011-10-20 19:20:11','2011-10-20 19:20:11','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces.\n\nFirst thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\n\n<!--more-->\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\n\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing vNIC/vHBA or add a new one, set the properties as desired, and fire up the server.\n\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\n\nOne additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-14','','','2011-10-20 19:20:11','2011-10-20 19:20:11','',5327,'http://egroup.jasonmangone.com/5327-revision-14',0,'revision','',0),(5344,12,'2011-10-20 19:35:12','2011-10-20 19:35:12','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some virtual interfaces.\n\nFirst, we had to shut down the server and assign it an address for use with CIMC so we could hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\n\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\n\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got our CIMC to the 1.2.x code desired. Finally.\n\n<!--more-->\n\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\n\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\n\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\n\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\n\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing vNIC/vHBA or add a new one, set the properties as desired, and fire up the server.\n\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\n\nOne additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\n\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-autosave','','','2011-10-20 19:35:12','2011-10-20 19:35:12','',5327,'http://egroup.jasonmangone.com/5327-autosave',0,'revision','',0),(5345,12,'2011-10-20 19:31:42','2011-10-20 19:31:42','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some interfaces.\r\n\r\nFirst thing first, shut down the server and assign it an address for use with CIMC so we can hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\r\n\r\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\r\n\r\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\r\n\r\n<!--more-->\r\n\r\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\r\n\r\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\r\n\r\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\r\n\r\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\r\n\r\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing vNIC/vHBA or add a new one, set the properties as desired, and fire up the server.\r\n\r\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\r\n\r\nOne additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\r\n\r\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-15','','','2011-10-20 19:31:42','2011-10-20 19:31:42','',5327,'http://egroup.jasonmangone.com/5327-revision-15',0,'revision','',0),(5346,12,'2011-10-20 19:33:09','2011-10-20 19:33:09','I had the pleasure of spending time yesterday evening with a great customer in the Carolinas (thanks guys) working on a Cisco UCS C series server, where the goal was to install the P81E Cisco Virtual Interface Card (VIC) and carve up some virtual interfaces.\r\n\r\nFirst, we had to shut down the server and assign it an address for use with CIMC so we could hit the server directly. Once this was done, we saw the firmware version of the CIMC was at 1.1.1. One of the requirements of the P81E is firmware for the CIMC specifically at 1.2.x or greater. On the Cisco website when downloading the latest firmware all that was offered for the 1.4 code was the Cisco Host Update Utility, which downloads as an ISO.\r\n\r\nWhen using this, it clearly states that you CANNOT upgrade the BIOS or CIMC versions with the Utility until you\'re at 1.2 or later. Since we were at 1.1, we had to download the BIOS / CIMC upgrades separately (which download as ZIP files containing the necessary BIN files). While that was downloading we updated all the other components using the Host Update Utility by mounting the ISO as Virtual Media via the CIMC interface-- love this interface by the way.\r\n\r\nWhen trying to upload the new firmware for the CIMC, we used the Browser Client, which lets you browse to a file on your local hard drive and upload it. This method failed several times, with only an \"HTTP ERROR\" status. When we switched over and used the TFTP server option, it worked without issues, and got out CIMC to the 1.2.x code desired. Finally.\r\n\r\n<!--more-->\r\n\r\nFrom here, we had to let the CIMC reboot and then reconnect back in, where we found this nifty new tab under the \"Inventory\" menu on the main Server tab (left hand side).\r\n\r\n<img class=\"aligncenter\" src=\"http://img26.imageshack.us/img26/5565/p81eadapterstab.png\" alt=\"\" width=\"622\" height=\"134\" />\r\n\r\nOn the Adapters tab it shows the Cisco VIC card and some additional tabs for vNICs / vHBAs.\r\n\r\n<img class=\"aligncenter\" src=\"http://img40.imageshack.us/img40/8808/p81eadaptersvnicstab.png\" alt=\"\" width=\"578\" height=\"371\" />\r\n\r\nHere\'s the fun part-- creating vNICs and/or vHBAs. This is somewhat similar to the Palo adapter on the UCS B series servers, and all the vNICs you carve here are presented without any additional drivers or installation steps (assuming ESXi 4.1 or later as the hypervisor), at 10Gbps. Simply clone an existing vNIC/vHBA or add a new one, set the properties as desired, and fire up the server.\r\n\r\n<img class=\"aligncenter\" src=\"http://img198.imageshack.us/img198/9918/p81evnicview.png\" alt=\"\" width=\"736\" height=\"276\" />\r\n\r\nOne additional note that\'s semi related-- other vendors let you carve the NICs and show only the bandwidth they have presented. In a vSphere world, if you carve up a bunch of interfaces and they show up as anything less than 10Gb, you are limited to 4 vMotions at a time, max. With 10Gb, it will move 8 at a time-- which is faster evacuation or hosts going into maintenance mode (most of the time 8 VMs are in flight at once).\r\n\r\n&nbsp;','Cisco UCS C Series - P81E VIC &amp; ADDING VIRTUAL INTERFACES ','','inherit','open','open','','5327-revision-16','','','2011-10-20 19:33:09','2011-10-20 19:33:09','',5327,'http://egroup.jasonmangone.com/5327-revision-16',0,'revision','',0),(5347,12,'2011-10-23 21:00:31','2011-10-23 21:00:31','The \"journey to the cloud\" is a great tagline for helping customers go from a pure \"private cloud\" environment to a public or hybrid cloud solution.\n\n1. One of the first steps that most customers today are already at, is to virtualize the majority (if not all) of your workloads. Because of how common it is to find this already in place, I won\'t go into detail here.\n\n2. The second step once the systems are virtualized is to quantify the cost of the virtual machines and hardware powering them to establish a baseline and help determine the desired pricing to beat for a public cloud provider.\n\n3. Now here\'s where the nerd fun begins. At this step, number three if you\'re following along, an important decision must be made to determine how you will deliver access to your data/applications to end users. This can be done through a simple VPN connection, in which the user accesses the data over an encrypted tunnel (though this is a really limited model). It can be done through a web portal or similar Content Management System-- something along the lines of SharePoint can suffice for basic office documents and the like. But where the real power/flexibility comes in is when you start delivering either the application itself, or a desktop that contains the desired application, to the user through a portal or client application. The biggest players here are Citrix, who can deliver the desktop and/or the application and VMware, who can deliver the desktop (worth pointing out that VMware requires ESXi as the hypervisor for this, Citrix supports ESXi, XenServer, and Hyper-V).\n\nThese solutions allow users to get to their data / applications securely and remotely (if allowed by your company) without issue, and offer a near native experience for most use cases. And depending on which solution you go with, you can provide your users with a desktop or application on many different devices-- including Macs, iPads, iPhones, Android phones, Blackberry phones, Android tablets, ChromeBooks, etc.\n\n4. So the users in the company can now access their applications and do their work remotely with limited reduction in efficiency or capability. What\'s next? Well at this point, you essentially have a \"private cloud\" and lots of capabilities. This step is optional, but when followed can provide the best level of education and lead to easier / better decisions when looking outside the company for cloud resources.\n\nThis step is all about cost reporting and monitoring. VMware offers their product, vCenter Chargeback, but any similar product will suffice here. The goal is to accurately calculate the cost for your environment to provide compute resources on your private cloud. When you have this information you can easily see what individual machines cost, how much an entire department costs if your company allows for departmental chargeback, and even help you forecast out what you\'ll need to spend to grow your environment. But more importantly, this helps you line up cost for YOUR resources so you can directly compare them a','A DIFFERENT JOURNEY TO THE HYBRID CLOUD ','','inherit','open','open','','5318-revision-6','','','2011-10-23 21:00:31','2011-10-23 21:00:31','',5318,'http://egroup.jasonmangone.com/5318-revision-6',0,'revision','',0),(5348,12,'2011-10-23 21:02:39','2011-10-23 21:02:39','The \"journey to the cloud\" is a great tagline for helping customers go from a pure \"private cloud\" environment to a public or hybrid cloud solution.\n\n1. One of the first steps that most customers today are already at, is to virtualize the majority (if not all) of your workloads. Because of how common it is to find this already in place, I won\'t go into detail here.\n\n2. The second step once the systems are virtualized is to quantify the cost of the virtual machines and hardware powering them to establish a baseline and help determine the desired pricing to beat for a public cloud provider.\n\n3. Now here\'s where the nerd fun begins. At this step, number three if you\'re following along, an important decision must be made to determine how you will deliver access to your data/applications to end users. This can be done through a simple VPN connection, in which the user accesses the data over an encrypted tunnel (though this is a really limited model). It can be done through a web portal or similar Content Management System-- something along the lines of SharePoint can suffice for basic office documents and the like. But where the real power/flexibility comes in is when you start delivering either the application itself, or a desktop that contains the desired application, to the user through a portal or client application. The biggest players here are Citrix, who can deliver the desktop and/or the application and VMware, who can deliver the desktop (worth pointing out that VMware requires ESXi as the hypervisor for this, Citrix supports ESXi, XenServer, and Hyper-V).\n\nThese solutions allow users to get to their data / applications securely and remotely (if allowed by your company) without issue, and offer a near native experience for most use cases. And depending on which solution you go with, you can provide your users with a desktop or application on many different devices-- including Macs, iPads, iPhones, Android phones, Blackberry phones, Android tablets, ChromeBooks, etc.\n\n4. So the users in the company can now access their applications and do their work remotely with limited reduction in efficiency or capability. What\'s next? Well at this point, you essentially have a \"private cloud\" and lots of capabilities. This step is optional, but when followed can provide the best level of education and lead to easier / better decisions when looking outside the company for cloud resources.\n\nThis step is all about cost reporting and monitoring. VMware offers their product, vCenter Chargeback, but any similar product will suffice here. The goal is to accurately calculate the cost for your environment to provide compute resources on your private cloud. When you have this information you can easily see what individual machines cost, how much an entire department costs if your company allows for departmental chargeback, and even help you forecast out what you\'ll need to spend to grow your environment. But more importantly, this helps you line up cost for YOUR resources so you can directly compare them against the cost of cloud resources.\n\n5. Using your calculated pric','A DIFFERENT JOURNEY TO THE HYBRID CLOUD ','','inherit','open','open','','5318-revision-7','','','2011-10-23 21:02:39','2011-10-23 21:02:39','',5318,'http://egroup.jasonmangone.com/5318-revision-7',0,'revision','',0),(5349,12,'2011-10-24 15:55:12','0000-00-00 00:00:00','Having a powerful Unified Storage array like the EMC VNX offers many different capabilities, and an equal number of decisions. The majority of the implementations we do of these boxes are around VMware/virtualization, and in today\'s leading hypervisors you can provide storage through Fiber Channel, Fiber Channel over Ethernet, iSCSI, or NFS for NAS devices. And of course, the EMC VNX gives you the option for any / all of the above.\n\nWithin the context of virtualization for the majority of this post, I\'ll lay out the best practices for configuration of the VNX and network between the host and the storage, and go a bit further where applicable.\n\nPersonal experience has shown that Fiber Channel is still the most common choice customers are making for their storage network / connectivity. When providing storage off of the EMC VNX through Fiber Channel, it\'s very common to find an upstream Cisco or equivalent fiber switch.\n\nConnectivity for the VNX through Fiber Channels comes off of the \"block\" side of the array, through either the ports on the Storage Processor Enclosure itself, or one of the many IO modules connecting to each Storage Processor. If you \"direct attach\", meaning plug your host HBAs into the VNX directly, the array will recognize the host and you will be able to present storage without issues. However, this does not scale, as you\'re using the backend ports for host connectivity, and would be limited the number of ports available per SP.\n\nThis is why most environments have a switch that connects to these ports, and then \"fan out\" the hosts through connectivity to the switch(es).\n\niSCSI\n\niSCSI connectivity on the VNX should be done ONLY through the Storage Processors, and NOT through the X-Blades. There are many reasons for this that I won\'t get into-- and in the past you could do iSCSI that was file system based through the X-blades. Long story short, don\'t do it.\n\nAlso, a common practice in the past was to have the iSCSI storage processor ports on separate subnets. With 2 ports per SP, it was normal to see 1 port from each on Subnet A, and the other ports on Subnet B (so each SP had a single connection in each VLAN). This was due to a \"bug\" or software limitation that was removed/resolved on the CLARiiON platform staring with FLARE 30.\n\nToday if you are implementing iSCSI off of the VNX, the ports should all be in the same VLAN. This makes the design much simpler, and it works great (both for 1Gb and 10Gbe).\n\nAssuming you are connecting the VNX to upstream switches, it\'s important to keep in mind that you want to physically separate this traffic from the rest of the network (meaning dedicated Ethernet switches) where possible, but at the very least logically separate it through VLANs.\n\nThe ports in which the storage processor connect to the switch should have spanning-tree disabled or bypassed through use of spanning-tree portfast (or switchport type edge trunk for the Nexus guys). Quick explanation of what this does is immediately move the port to a forwarding state in the event of a port down or topology change. Because those ports connect to the array (which is not a switch) there is no chance of a network loop, and thus, you should use portfast to immediately forward on those ports.\n\nOn the VMware side, make sure you are following the VMware iSCSI SAN Guide and setting things up appropriately there as well. Depending on how many NICs and what your design looks like, you will have different configurations. But make sure you are mapping your iSCSI-dedicated NICs 1:1 with a vmkernel port (again, on the same subnet). Once this is done in vSphere 5 you set up the iSCSI binding through the GUI. If you are still running vSphere 4.x, this is done through the command line via esxcli.\n\n&nbsp;','EMC VNX - PROTOCOL BASED BEST PRACTICES ','','draft','open','open','','','','','2011-10-24 15:55:12','2011-10-24 15:55:12','',0,'http://egroup.jasonmangone.com/?p=5349',0,'post','',0),(5350,12,'2011-10-23 21:04:21','2011-10-23 21:04:21','Having a powerful Unified Storage array like the EMC VNX offers many different capabilities, and an equal number of decisions. The majority of the implementations we do of these boxes are around VMware/virtualization, and in today\'s hypervisors','EMC VNX - PROTOCOL BASED BEST PRACTICES ','','inherit','open','open','','5349-revision','','','2011-10-23 21:04:21','2011-10-23 21:04:21','',5349,'http://egroup.jasonmangone.com/5349-revision',0,'revision','',0),(5351,12,'2011-10-23 21:08:03','2011-10-23 21:08:03','Having a powerful Unified Storage array like the EMC VNX offers many different capabilities, and an equal number of decisions. The majority of the implementations we do of these boxes are around VMware/virtualization, and in today\'s leading hypervisors you can provide storage through Fiber Channel, Fiber Channel over Ethernet, iSCSI, or NFS for NAS devices. And of course, the EMC VNX gives you the option for any / all of the above.\n\nWithin the context of virtualization for the majority of this post, I\'ll lay out the best practices for configuration of the VNX and network between the host and the storage, and go a bit further where applicable.\n\nPersonal experience has shown that Fiber Channel is still the most common choice customers are making for their storage network / connectivity. When providing storage off of the EMC VNX through Fiber Channel, it\'s very common to find an upstream Cisco or equivalent fiber switch.\n\nConnectivity for the VNX through Fiber Channels comes off of the \"block\" side of the array, through either the ports on the Storage Process enclosure itself, or one of the','EMC VNX - PROTOCOL BASED BEST PRACTICES ','','inherit','open','open','','5349-revision-2','','','2011-10-23 21:08:03','2011-10-23 21:08:03','',5349,'http://egroup.jasonmangone.com/5349-revision-2',0,'revision','',0),