My PernixData vSphere Design Pocketbook v3 Submissions

So on the 29/03/2016 Frank Denneman announced the authors for the new vSphere Design Pocketbook v3 which is sponsored graciously by PernixData and the list is just amazing and rich with people of high caliber in terms of vSphere design and architecture.

In the past two editions I was lucky that my entries were accepted, unfortunately my submissions for this release were not accepted but I am very much grateful that I was given an opportunity to contribute, as it is not the result which brings joy as much as the journey does and I urge anyone who thinks that they don’t have what it takes to contribute to just go for it as with every contribution you will have a better grasp on the content.

Once I saw the list of the authors I knew my submission where no match, not that the information in them is not beneficial but it is simple mathematics and I am absolutely glad because _we_ will be consuming a lot of great ideas and thoughts so it is a win-win situation if you’d ask me :-).

Here-under you will find my contributions hoping that they’d be informative and useful to someone out there.

Entry1 Blog: Storage design:

VMFS VS RDM VS NPIV:

I have chosen to write about a topic that I have seen scarcely being mentioned, the topic is whether to go with RDM (utilizing the ESXi zoning to present a raw disk to the VM) or using Fibre Channel NPIV and create a virtual HBA for each VM and carry out through the zoning process per each VM from there as well or ultimately go with a VMFS datastore, briefly find a quick description of each:

  1. VMFS: presented to the ESXi and then formatted in VMFS and the virtual machine data exists in a VMDK file (configuration) pointing to a VMDK-flat file (data).vSphere Pocketboot 3 - VMFS
  2. RDM: presented to the ESXi host, then presented to the VM and is formatted within the VM and only has a VMDK file (configuration) pointing to the RDM itself, RDM comes in two modes:
    • Virtual: SCSI commands are sent via the hypervisor to the storage.
    • Physical: SCSI commands are sent directly to the storage.vSphere Pocketboot 3 - RDM
  3. NPIV: Each virtual machine has its own WWPN and then is visible through the FC fabric knowing that the HBA must support NPIV for it to work.vSphere Pocketboot 3 - NPIV

From my point of view the RDM and NPIV are the same, because eventually after both an RDM disk is being presented to the VM but the main difference is the fact that NPIV provides a better vision of your storage, and one could say that it eliminates storage trespassing completely.

Which option should go with for my enterprise application one would say? Well this depends on the scenario at hand and if the client/implementing party has done their benchmarking prior to going with any decision.

This requirement usually comes from the application vendor (SAP, Oracle, Microsoft, Sybase, etc.) whether their application can live on a VMFS VMDK or requires direct access to the storage device and bypass the hypervisor layer.

In addition to the above the choice can be justified by the influence of the environment surrounding the ESXi cluster, for example:

  • You’re using for backup and replication in such a way that if you will utilizing SAN snapshots for your high capacity RDM rather than doing in-guest backups then RDM would be a better choice.
  • You’re migrating an application that has a huge chunk of data and migrating this application would be better off by just converting the OS and just pointing it to the RDM (already existing LUN).

In terms of setup, VMFS and RDMs are quite easy to setup versus NPIV which will require the process of zoning to take place and thus you’ll need to provide the storage administrator with these information every time a new VM is spun and requires direct access to the storage.

My facts, I am not in favor is using RDMs and I am in favor of using VMDKs even with the valid reasons mentioned above, the limitations that were in an earlier era when virtualization was still in its early days of adoption are no longer and with each version of vSphere things are looking even better, don’t let anyone tell you that we’re going with RDM because it has a better performance in addition the new HCI model is emerging in the market and is proving itself to be reliable foundation for business critical apps that used to require RDMs.

One more thought regarding this would be support, if the vendor X doesn’t support VMFS VMDKs then you’d have to comply unless you know about the product more than that vendor does ;-).

Entry 2 Tweet [Words of Wisdom]:

Compatibility matrix, this should be your altar when designing a solution (whatever-it-is) always revert back to the:

  • Hardware compatibility matrix.
  • Software compatibility matrix.
  • Firmware compatibility matrix.
  • Drivers compatibility matrix.

Each vendor provides a compatibility matrix to their product, you should follow that closely before relying on product version and builds in your design, as if not defined in a clear and correct way the implementation team will likely go for the latest and this might work-out fine at the beginning but catastrophic results will for sure rise upon further continuing with an in-compatible setup.

Bring this information to your customer, let them know that bringing all the pieces together requires a harmony even if you’re going to lose certain features of a new release but stability is key and it controls the success and failure of any implementation no matter how the feature rich a new release of a product/firmware is.

Entry 3 Tweet [Words of Wisdom]:

Always prepare a high availability tests plan and make sure it gets executed thoroughly, the plan should include all components around the vSphere infrastructure as well even if it is not in your scope and this includes:

  1. Directory Services.
  2. Storage.
  3. Networking.
  4. File Services in case there is a dependency.

Once this is fulfilled you can pin point any configuration errors or if any configuration item has been missed by mistake, sometimes doing these tests will make you alter a major design decision and it will for sure increase the trust in the infrastructure.

If you feel any of the above information requires correction please feel free to comment here-under and I will update the blog post accordingly, hopefully this will be of use and thank you for taking the time to read this.

(Abdullah)^2

3146 Total Views 1 Views Today

Abdullah

Knowledge is limitless.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.