Traditionally, DBAs have distributed the data and transaction log files associated with databases (user and system) along with backups across multiple disks. This tenet holds true for virtual configurations that use FlashArray and has implications for performance, availability, and manageability.
When it comes to performance, the storage controller is one of the places where I/O can cause a bottleneck. A single controller has a finite number of I/O commands that it can queue and funnel to underlying storage. More paths and channels to get to the underlying storage with a minimal amount of queueing improves performance.
Always use vSCSI controllers. Generation 1 VMs default to IDE controllers but vSCSI can be added. Generation 2 VMs cannot use IDE as noted above and can only have vSCSI controllers.
While Microsoft’s official guidance in the Learn topic “Hyper-V Storage I/O Performance” suggests using just one vSCSI controller until the number of disks exceed what a single controller supports (for example, attaching a 65th disk), it is strongly suggested that you test with your particular workload to see if leveraging multiple vSCSI controllers can improve the overall performance. Properly distributing the I/O workload across multiple disks that are attached to different vSCSI controllers is a common configuration for virtualized SQL Server implementations – just like it is for physical deployments, too.
The image below shows four vSCSI controllers configured on a single VM with SQL Server object drives distributed across the controllers. For this example deployment, performance telemetry was used to understand the I/O workload for a more even distribution across the four available controllers.
The number of controllers that is right for each deployment should be tested and is workload dependent. Each customer’s workload demands are unique and should be mapped before creating and placing database objects on each volume. Use any form of in-guest and application-aware performance telemetry to appropriately map out the workload demands and evenly distribute the workload across the available controllers in the most even manner possible.
This distribution and purpose should be communicated and understood by the infrastructure team. For objects distributed in this manner, care must be taken to allow Pure’s features to maintain their effectiveness.
For example, Pure can take periodic snapshots of one or more SAN LUNs to provide a rollback point in the event of an emergency. However, if a LUN containing a database transaction log is rolled back to a different point in time than the corresponding database data file(s), the database could be in jeopardy and not come online. The various LUNs underneath the database objects should be part of a protection group so that the snapshot can be reverted to the same point in time across all LUNs in the group and maintain the database’s integrity.