Hosts and port groups

For ease of management and monitoring, we created two storage hosts on the PowerMax array—one containing the two initiators from the Oracle database ESXi host (MX840c in MX slot 1) and the other containing the two initiators from the SQL Server ESXi host (MX840c in MX slot 3).

As described in FCoE-to-FC connectivity and zoning, the FC connectivity and zoning design ensures that both the Oracle ESXi host and the SQL Server ESXi hosts are connected to eight unique front-end ports on the PowerMax array. As a result, we created two storage port groups on the PowerMax array—one containing the eight front-end ports that were zoned with the Oracle database host initiators and the second containing the other eight front-end ports that were zoned with the SQL Server database host initiators. This design ensures equal bandwidth, high-availability, ease of management and monitoring, and security for both the Oracle and the SQL Server databases.

Storage groups and volumes
for Oracle workloads

To consolidate the mixed workloads of Oracle and SQL databases in the single PowerMax storage array, we adapted the following principles for the storage group and storage volume design for three Oracle databases—Oracle OLTP database, Oracle DSS database, and Oracle snapshot database. These design principles simplify the management and performance monitoring of the storage volumes.

• Created the parent storage group for each database such as ORA-OLTP-SG for the Oracle OLTP database.
• Created a separate child group for each type of volumes, such as DATA, REDO, FRA, and TEMP volumes, within each parent storage group. The numbers of corresponding volumes were created in each child group; for example, we created four data volumes in the ORA-OLTP-DATA child group.
• Created a special parent storage group, ORA-OS-OCR, that consolidates the operating system virtual disks for all Oracle database guest VMs and for Oracle Clusterware OCR and voting disks. The child groups within this parent group were created for each VM operating system volume and each Oracle Clusterware OCR and voting disk volume.

With these design principles in mind, we developed the following storage groups and volumes for these mixed workload Oracle databases.

For the Oracle OLTP database, we created the ORA-OLTP-SG parent storage group and the following child storage groups within the parent group:

• ORA-OLTP-DATA for DATA files
• ORA-OLTP-REDO for REDO logs
• ORA-OLTP-FRA for FRA
• ORA-OLTP-TEMP for TEMP files

We also created the ORA-OLTP-OS and ORA-OLTP-OCR child groups within the common ORA-OS-OCR parent group. The following table shows the storage groups and the number of volumes and volume sizes for this Oracle OLTP database:

Table 28.        Storage groups and volumes for the Oracle OLTP database

Similarly, for the Oracle DSS database, we created the ORA-DSS-SG parent storage group and the following child storage groups:

• ORA-DSS-DATA for DATA files
• ORA-DSS-REDO for REDO logs
• ORA-DSS-FRA for FRA
• ORA-DSS-TEMP for TEMP files

We also created the ORA-DSS-OS child group and ORA-DSS-OCR child group within the common ORA-OS-OCR parent group. The following table shows these storage groups, the number of volumes, and the size of the volumes for this Oracle DSS database:

Table 29.        Storage groups and volumes for the Oracle DSS database

In this reference architecture design, we adapted the following principles for the storage group and storage volume design for five SQL Server databases—two OLTP databases, two DSS databases, and one snapshot database:

• Created the parent storage group for each database, such as SQL_OLTP_VM1_SG for the SQL Server OLTP database.
• Created a separate child group for each type of volume, such as data, log, and tempdb data and tempdb log volumes within each parent storage group. We created the number of corresponding volumes in each child group—for example, two data volumes in the SQL_OLTP_VM1_Data child group.
• Created a special parent storage group, SQL_OS_SG, that consolidates the operating system virtual disks for all SQL Server database guest VMs. We created the child groups within this parent group for each VM’s operating system volumes.

These design principles simplify the management and performance monitoring of the storage volumes, including the volumes that were created through snapshots for the SQL Server workload running along with the Oracle workload.

The following table shows the storage groups and volumes for the SQL Server OLTP database workloads.

Table 30.        Storage groups and volumes for the SQL Server OLTP databases

For the SQL Server DSS database, we created a similar storage layout. The following table shows the storage groups, the number of volumes, and the volume sizes for the two SQL Server DSS databases:

Table 31.        Storage groups and volumes for the SQL Server DSS databases

Snapshot database volumes

The following figure illustrates the architecture of SnapVX snapshots of the production (source) database volumes. It shows how these snapshots are linked to another set of target devices, which are accessed by the snapshot database host, to form a snapshot database such as a development or test database.

Figure 28.     SnapVX snapshot creation and snapshot database mounting

For snapshot databases, we created two types of storage groups:

• New storage groups—We created new volumes in these storage groups for the snapshot database. These storage groups include the guest operating system volumes, Oracle OCR/voting disks, Oracle TEMP volumes, and the SQL Server guest operating system and TEMP volumes, as shown in the following table:

Table 32.    New storage groups for snapshot databases

• Snapshot or SnapVX storage groups—These storage groups are snapshots of existing database storage groups. The volumes in these storage groups include snapshots of the corresponding Oracle DATA, REDO, and FRA, and SQL Server DATA and LOG source volumes. We created two SnapVX snapshots: one of the existing Oracle OLTP database and another of the existing SQL Server OLTP database. The host database servers, however, access the snapshot storage groups or volumes using the SnapVX link target storage groups that we created for the respective Oracle and SQL Server snapshots. The following table shows the source, snapshot, and SnapVX link target storage groups that we created for both Oracle and SQL Server snapshot databases:

Table 33.    Source, snapshot, and link target storage groups for snapshot databases

Note: Unisphere storage management automatically creates the SnapVX link target storage group structure to be the same as that from which it is created. Hence, the number and the size of the snapshot volumes is identical to the source database volumes.

We then mapped all the new storage groups and the SnapVX link target storage groups that were created for the snapshot databases to their respective database ESXi hosts by creating the appropriate masking views. Within the respective ESXi hosts, we manually added all the volumes to the appropriate VM that was created for the snapshot database. Within the respective database guest VMs, we mounted these volumes to the snapshot database.

The following figure illustrates the snapshot creation, linking, and mounting process, using the Oracle OLTP database and its snapshot database as an example.

Figure 29.     Snapshot creation, linking, and mounting process