Showing posts with label VMWare. Show all posts
Showing posts with label VMWare. Show all posts

Tuesday, 20 September 2016

Windows Server 2016: Storage Spaces Direct (S2D) and VMware Virtual SAN IOPS?

We’re not VMware experts here. Let’s make that very clear. 

However, we do have the ear of many a VMware expert so we are able to ask: Is the Windows Server 2016 hyper-converged Storage Spaces Direct (S2D) setup similar to the VMware Virtual SAN platform? Apples to Apples if you will?

The resounding answer has been, “Yes!”

That leads us to the following articles that are about Intel NVMe all-flash hyper-converged setups:

  1. Record Performance of All Flash NVMe Configuration – Windows Server 2016 and Storage Spaces Direct - IT Peer Network
    • An Intel based four node S2D setup
  2. VMware Virtual SAN 6.2 Sets New Record - IT Peer Network
    • A VMware based 8 node Virtual SAN 6.2 setup

What’s interesting to note is the following:

  1. Intel/S2D setup at 4 nodes
    • 3.2M IOPS at 4K Read
      • 930K IOPS at 70/30 Read/Write
  2. VMware setup at 8 nodes
    1. 1.2M IOPS @ Capacity Mode
      • 500K IOPS at 70/30 Read/Write
    2. ~830K IOPS @ Balance Mode
      • 800K IOPS at 70/30 Read/Write

What is starting to become apparent, at least to us, is that the folks over at the newly minted Dell EMC _really_ need to pay attention to Microsoft’s feature depth in Windows Server 2016. In fact, that goes without saying for all vendors into virtualization, high performance computing (HPC), storage, and data centre products.

We’re pretty excited about the hyper-converged S2D feature set in Windows Server 2016. So much so, we have invested quite heavily in our Proof-of-Concept (PoC).

image

The bill of materials (BoM) for the setup so far:

  • S2D Nodes (4)
    • Intel Server Systems R2224WTTYS with dual E5-2640, 256GB ECC, Intel JBOD HBA, Intel X540-T2 10GbE, Mellanox 56GbE NICs, Intel PCIe 750 NVMe, Intel SATA SSDs, and Seagate 10K SAS spindles
  • Hyper-V Nodes (2)
    • Intel Server Systems R2208GZ4GC with dual E5-2650, 128GB ECC, Intel X540-T2 10GbE, and Mellanox 56GbE NICs
  • Lab DC
    • An Intel Server setup including S1200BT series board and Intel Xeon E3 processor.

Our testing includes using the S2D setup as a hyper-converged platform but also as a Scale-Out File Server (SOFS) cluster destination for a Hyper-V cluster on the two Hyper-V nodes. Then, some testing of various configurations beyond.

We believe Windows Server 2016 is looking to be one of the best server operating systems Microsoft has ever released. Hopefully we won’t be seeing any major bugs in the production version!

Philip Elder
Microsoft High Availability MVP
MPECS Inc.
Our SMB/SME HA Solution
Our Cloud Service

Wednesday, 21 August 2013

Kiss-o'-Death Packet - Time Then and Now

In the days where CMOS and on board clocks ruled the roost time was rock solid. Between atomic clocks that became common place on the Internet and CMOS one never really had to worry too much about it. If there was a bit of a difference the OS would shift the CMOS clock back into alignment. Case closed.

The difference with virtualization is the separation between the OS and the hardware.

Now, one would think that all we really need to do is enable the sync between host and guest via their guest utilities. But a DC cannot be dependent on the host because the guest is not allowed to adjust the time _on_ the host if it is out of sync. If the host carries the DC way out of sync with the rest of the network toast is made.

We’ve seen clusters go down because of time being out of whack.

Our timing post has a registry edit in it that we used to do on 2008 RTM that allowed the guest to ping the host for time but once the OS was up and running it would pick up from ntp.org or whatever.

That registry edit is now there by default from what we have seen.

The time structures were never intended to compensate for today’s virtualization environment since no one could have envisioned the setup in the first place back then.

Now, look up “Kiss-o’-Death Packet” (NTP.ORG site). And we see why we need to be _very_ careful around the time setup on our virtualization platforms.

This packet is the primary reason we make sure we have a physical box set up on the local network to poll for the correct time within the virtualization environment. That box polls ntp.org. The virtualized DC polls that box as it will not stop answering like ntp.org would if polls are more frequent.

Imagine a high load VM setup where the PDC is set to poll ntp.org but the admin set up a script to run the poll a lot more frequently. After exhausting the ntp.org servers in its list due to Kiss-o'-Death Packets it would be hooped and time would go awry on that network.

Since we don’t work with VMware we personally am not aware of how that server setup can work as an NTP server.

We do, however, highly suggest making sure being aware of the perils of time when virtualized.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

Chef de partie in the SMBKitchen
Find out more at
www.thirdtier.net/enterprise-solutions-for-small-business/

Windows Live Writer

Thursday, 26 May 2011

Some Thoughts On Standalone, Cluster Host, and VM Recoverability

The following was our post to the Yahoo SBS2K list that we figured would be good to share here.

The question was: How to install ESXi on a Dell using DRAC on a remote server.

QUOTE

Having looked at all of the responses to virtualizing a server on VMWare or Hyper-V, the following is where we are at in this.

We use Hyper-V exclusively. Why? It is very simple to work with.

For standalone servers we run a GUI install of Windows Server 2008 R2 along with an Intel RMM, iDRAC Advanced, iLO Advanced, etc. This gives us full management of both the hardware and the software so that question is moot. As you have indicated.

For clustering, we utilize Hyper-V Server 2008 R2. Again, it is quite simple to set up (after six months of brain busting investigation since documentation stinks for both s/w and h/w) and manage.

The native tools that come with RSAT or built into Windows Server make management and monitoring fairly straight forward.

Now, as to your dilemma we do the following on both the standalone and Hyper-V Nodes:

  1. Transcend 16GB TS16GJFV30 formatted NTFS and active.
    • Good read speed which is important. We only write once so no worries there.
  2. Copy Hyper-V Server 2008 R2 SP1 OS contents onto the flash. The flash will remain plugged into the server for the life of the box.
    • CAVEAT: If Win2K8 R2 GUI then put that on the flash.
  3. Place needed OS install ISO copies onto the Flash drive.
  4. Place needed drivers and firmware on the flash drive.
  5. If using Tier 1 have their bootable DVD in the optical drive.
  6. RMM, iDRAC ADV, iLO ADV, etc gives us boot control between Optical, USB Flash, and and RAID array with host OS.

What does this do for us?

We have full control over full host recovery, full guest recovery, and more depending on how the backups are structured. As a rule we do _not_ back up the host. It is faster to rebuild the host and either restore the guests from backup or connect existing VHDs depending on the failure.

RMM/iDRAC: We have tried USB redirection to boot the host OS and install via IP KVM and the process is just too painful. BTDT. Send them a fully configured USB Flash drive.

END QUOTE

What the above requires is at least 2 IP addresses from the ISP. One for the Internet connection used by the internal network and the other for the RMM/DRAC/iLO device that will be used to manage the server or cluster node.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*Our original iMac was stolen (previous blog post). We now have a new MacBook Pro courtesy of Vlad Mazek, owner of OWN.

Windows Live Writer