3 Replies Latest reply on Nov 21, 2017 4:16 PM by TheBobkin

    vsan principles secanrio -  migration

    gagusx Lurker

      Hi All

      I have a query on vSan principle  which using this scenario may be able to make clear

       

      Let’s say i have  vSphere Cluster and i wish it to migrate to VSAN -using the following assumptions

       

      - there are 5 Nodes fully equally and participating in a HA, DRS Cluster

      - Each node is running about 50% capacity in terms for resources, thus the environment could withstand a 2 node failure and still keep critical resources

      - there is a SAN backend, resourcing around 15 TB of VMDKs, thin-provisioned

      - the hosts can be upgrade  10TB local storage

      - vCenters and manage apps reside on a seperate 2-node Custer

       

      If you can recommend a method for migrating this to VASN, hopefully it will help me to understand 2 keys issue

      (a) does this environment work on a 1-live, 1 /2/3/4 mirrored copies

      (b) Where should , on best practice t, should the witness appliance reside, on a cluster or somewhere separate on another cluster

       

      many thanks

        • 1. Re: vsan principles secanrio -  migration
          TheBobkin Master
          vExpertVMware Employees

          Hello gagusx,

           

           

          Welcome to Communites.

           

          "(a) does this environment work on a 1-live, 1 /2/3/4 mirrored copies"

           

          Objects stored on vSAN (.vmdk, namespaces, .vswp) have Storage Policy defined properties that dictate their Failures To Tolerate - Default being FTT=1 (FTM=RAID1) which has 2 'mirror' data-components + a witness component for quorum.

          An FTT=2 Object would have 3 'mirror' data-components + 2 witness components for quorum

          What this means with respect to storage-utilization: if FTT=2 is required then these Objects would take up 3x what they use on SAN.

          If the workload does not have very high performance requirements then the other option is RAID5/6 as the FTM which uses significantly less space for the same FTT (1.33x for FTT=1 with RAID5 - requires 4-nodes minimum | 1.5x for FTT=2 with RAID6 - requires 6-nodes minimum)

           

          "(b) Where should , on best practice t, should the witness appliance reside, on a cluster or somewhere separate on another cluster"

           

          Witness appliances are only required in stretched clusters - e.g. 2 nodes at one physical location, 2 nodes in second physical location, witness at third site (as an aside - yes these should be running on a different cluster).

           

           

          Bob

          • 2. Re: vsan principles secanrio -  migration
            gagusx Lurker

            Hi Bob

             

            Many thanks for your reply -  before addressing your points, the thrust of what is making for is an over-view of how one would convert a sample 5-node cluster to VSAN (or even what design considerations would there be). This would enable me to understand VSAN from

             

            IN Regards to Point (A) Form what you’re saying, the FTT Level and to an extent the RAID level defines the number of Nodes in a cluster

             

            Also "An FTT=2 Object would have 3 'mirror' data-components + 2 witness components for quorum" - I'm not sure i understand this, as if 1 Quorum and 2 nodes fail  - that 3 failed components, but 1 Node is running and a quorum is running -  isn't that enough for the cluster to remain operational ?

             

            (b) I though Witness/quorums are essential to every environment

             

            Lastly, I’m getting ain impression that in a VANS environment there is 1 master and ‘many’ mirrors as  opposed to the mutli-node cluster of vSphere -  sounds right ?

            • 3. Re: vsan principles secanrio -  migration
              TheBobkin Master
              VMware EmployeesvExpert

              Hello gagusx,

               

               

              "IN Regards to Point (A) Form what you’re saying, the FTT Level and to an extent the RAID level defines the number of Nodes in a cluster"

              Yes, the desired FTT and specific FTM(s) used define what the minimum nodes per cluster are from a functional perspective as this many Fault Domains are required for component placement - and of course if N+1 for maintenance/fault recovery this is additional to the minimum required.

               

              "as if 1 Quorum and 2 nodes fail  - that 3 failed components, but 1 Node is running and a quorum is running -  isn't that enough for the cluster to remain operational ?"

              Actually the requirement for accessibile Objects is majority (>50%) of components + a full data-mirror, this is the reason why as the FTT (with R1) increases additional witness components are required. This is only the basic layout description of how this works - in reality with striping and votes etc. only relatively small Stripe-Width=1 FTT=1 R1 Objects look like this (2x data + 1x witness).

              As an aside, yes it is technically feasible to restore/create a functional Object from the remnants of an FTT=2 Object with a single active (and current!) data component + witness component - though this is not a trivial task if reliability and data-safety is concerned (and as with most things this has a ghetto-method and a safe-method).

               

              "(b) I though Witness/quorums are essential to every environment"

              They certainly are(!) but there is a distinction between witness component placement based on configuration:

              - Regular clusters store witness components on any available node not storing data or other witness components of that Object (these are relatively .

              - Stretched clusters (with FTT=1) store witness components only on a dedicated Witness Appliance (which is essentially a nested ESXi running from a VM on another host).

               

              "Lastly, I’m getting ain impression that in a VANS environment there is 1 master and ‘many’ mirrors as  opposed to the mutli-node cluster of vSphere -  sounds right ?"

              Writes to data components are synchronous - writes are 'committed' as soon as they hit cache so yes mirrors not a 'shared-disk' (unless Objects are FTT=0).

              Article that explains this functionality (yes I am aware this is for '2-node cluster' but the principles are them same):

              Read Locality in Hybrid 2 Node Virtual SAN - Virtual Blocks

               

              Hope this helps clarify things.

               

               

              Bob