Your Browser is Out of Date

ShareDemos uses technology that works best in other browsers.
For a full experience use one of the browsers below
Design Guide—VMware vSphere with Isilon and Unity XT Storage
Appendix: Deployment Considerations
Introduction General deployment guidelines Planning for growth Compute Networking Storage Additional considerations

Storage

  • The sample workload in this Ready Stack solution may be different than your anticipated workload. Be sure to size the VMFS datastores hosted on the Unity XT array properly, factoring in VMDK size, IOPS, and concurrency. The Dell EMC Midrange Sizer Tool can help you to model your storage requirements, providing customized array configurations based on your current and future storage workloads.

    For the IOPS created by this Ready Stack use-case, the Unity XT480F is more than sufficient.

    Unless you have specific use cases, use dynamic storage pools on the Unity XT 480F. Dynamic pools were introduced for all-flash systems in Dell EMC Unity OE version 4.2 and later. Dynamic pools replace the previous pool technology, now referred to as traditional pools, as the default pool type for all-flash systems. Dynamic pools use advanced RAID techniques and distributed sparing to offer better storage utilization and more simplified planning than traditional pools. Dynamic pools provide numerous benefits over traditional pools.

    Dynamic pools eliminate the need to design a pool based on a multiple of a stripe width. When creating a dynamic pool, after selecting a minimum drive count for a given level of RAID protection, you can select almost any number of drives to place within the pool. Thus, you can plan a pool based on a specific capacity without concern for stripe-width-based multiples of drives counts. When expanding a dynamic pool, since the stripe-width multiple does not apply, you can also expand the pool by a specific target capacity. In most cases, you can add a single drive to the pool to increase its capacity. These features provide flexible deployment models, which improve the planning and provisioning process. Eliminating the need for extra drives to fulfill a stripe-width multiple also reduces the total cost of ownership of the configuration.

    For Isilon systems, we suggest implementing SmartConnect using a round-robin load-balancing policy. Binding multiple IP addresses to each node interface in a SmartConnect subnet pool is considered a best practice. Most deployments achieve optimal balancing and failover when the number of addresses allocated to the subnet pool equals N * (N – 1), where N equals the number of node interfaces in the pool. For example, if a pool is configured with a total of five node interfaces, the optimal IP address allocation would total 20 IP addresses (5 * (5 – 1) = 20). In this scenario, you would allocate four IP addresses to each node interface in the pool.

    SmartConnect also supports IP failover to provide continuous access to data when hardware or a network path fails. Dynamic failover is recommended for high availability workloads on SmartConnect subnets that handle traffic from NFS clients.

    To evenly distribute connections and optimize performance, size SmartConnect for the expected number of connections and for the anticipated overall throughput likely to be generated. The sizing factors for a SmartConnect pool include:

    • The total number of active client connections expected to use the pool’s bandwidth at any time
    • The expected aggregate throughput that the pool needs to deliver
    • The minimum performance and throughput requirements in case an interface fails

next

Additional considerations