PowerMax systems are preconfigured with your specified capacity, connectivity options, and storage RAID protection. The SSD drives are spread across the back end and provisioned into logical devices called thin data devices (TDATs). The devices are placed in RAID groups and combined to become an SRP. When host thin devices (TDEVs) are later created, their capacity is consumed in the SRP. Most systems have a single SRP unless a specialized configuration is required.
PowerMax system architectures are based on units known as bricks. A brick includes an engine, which consists of two directors. Each director includes cache, ports, and emulations based on the services and functions that the storage was designed to provide. For example, each director includes ports supporting Fibre Channel (FC) or gigabit Ethernet, and emulations, such as front-end, back-end, iSCSI, eNAS, and SRDF. Each director also includes CPU cores that are pooled to be used with all emulations and serve all director ports. While the default balanced core allocation is usually best, Dell EMC support can deploy other methods if core use across emulations is constantly unbalanced.
PowerMax systems come preconfigured, so that when they are powered up, activities can immediately focus on physical connectivity to hosts, zoning, and storage provisioning to the database servers. Factory pre-configuration makes the deployment fast, easy, and focused on the application needs, rather than on the storage configuration.
Storage connectivity best practices
When planning storage connectivity for performance and availability, connecting storage ports across different engines and directors is better than using all the ports on a single director. In this way, even if a component fails, the storage can continue to service host I/Os.
PowerMax systems use dynamic core allocation. Each director provides services such as front-end connectivity, back-end connectivity, or data management. Each such service has its own set of cores on each director. The cores are combined to provide CPU resources that can be allocated as necessary. For example, even if host I/Os arrive through a single front-end port on the director, the front-end pool with all its CPU cores is available to service that port. Because I/Os arriving at other directors have their own core pools, we recommend connecting each host to ports on different directors before using additional ports on the same director. This practice ensures high performance and availability.
Virtual Provisioning and thin devices
All PowerMax system host devices use Virtual Provisioning technology. The devices are a set of pointers to capacity allocated at 128 KB extent granularity in the SRPs; however, to the host they look and respond just like regular LUNs. Using pointers also increases capacity and efficiency for SnapVX local replication by sharing extents when data does not change between snapshots.
Virtual Provisioning technology offers a choice of whether to fully allocate the host device capacity or to allow allocation on demand.
- A fully allocated device consumes all its capacity in the SRP on creation, and therefore, there is no risk that future writes might fail because the SRP has no remaining capacity.
- Allocation on demand enables over-provisioning. Although the storage devices are created and appear to the host as available with their full capacity, actual capacity is allocated in the SRP only when host writes occur. This is a common cost-saving practice.
Use allocation on demand when:
- You do not know the capacity growth rate for an application.
- You do not want to commit large amounts of storage ahead of time because it might not be used.
- You do not want to disrupt host operations at a later time by adding more devices or expanding the capacity of the existing devices.
If allocation on demand is used, capacity is only physically assigned as needed to meet application requirements.
When data files are created, Microsoft SQL Server pre-allocates capacity by writing to every page with contiguous zeros. When allocation on demand is used, it is best to increase database capacity over time, based on actual need. For example, with SQL Server provisioned with a thin device of 2 TB, the DBA—rather than immediately creating data files of 2 TB and consuming all its space—could use an auto-growth feature that consumes only the needed capacity.
Note: When Windows Instant File Initialization (IFI) is used, allocation of data files occurs in a thin-pool-friendly way. Areas of a disk under which a sparse file is defined, as created by IFI, are not zeroed. As table and index information is written to a fully initialized data file, areas of the database become allocated and used by non-zero user data. SQL Server automatically uses Windows IFI if the service account under which the SQL Server service is running has Perform volume maintenance tasks permission under the local security policy. By default, only administrators have this permission. Information about the IFI is provided in the Microsoft SQL Server Books online product documentation. Transaction logs remain fully allocated even with IFI to avoid marginal performance penalties that might result during additional thin pool allocations.
Considerations for PowerMax data reduction with SQL Server
The following considerations apply when you use PowerMax data reduction for SQL Server:
- Efficiency using thin provisioning—PowerMax systems are fully thin provisioned storage systems providing the highest levels of storage efficiency. SQL server SGs consume storage capacity only for the data that is actually written by the host and grow as needed with host writes. Storage efficiency is already realized when SQL Server SGs are deployed on PowerMax devices. All PowerMax data services continue to offer highly efficient data copy and capacity utilization even when you use PowerMax SnapVX for periodic snapshots or SRDF for remote replication.
- Efficiency using PowerMax compression—PowerMax ACE splits the 128 KB track into four 32 KB buffers and acts on them independently, making the compression process highly efficient. SQL Server I/O ranges between 8 KB and 256 KB with 8 KB to 32 KB write sizes most common for OLTP workloads; therefore, contiguous writes to the same track are considered for the compression analysis. In addition, data is decompressed at the same 32 KB granularity, improving the latency for activities with high locality of reference because data might be already available in PowerMax cache from prior activity on the track. Data that is already compressed and does not exceed the activity thresholds assigned by PowerMax compression algorithms is compressed in line and written to the thin pools, resulting in excellent efficiency.
- Efficiency using PowerMax dedupe—PowerMax dedupe uses the hash IDs that are generated on 128 KB track writes. Microsoft Windows NTFS uses 64 KB alignment. Due to the misalignment with extent size and NTFS allocation unit, the likelihood of dedupe on subsequent writes to the same device is low. However, multiple copies of SQL databases are always created on the PowerMax system for backup, test, dev, and reporting instances. These additional copies would certainly realize the dedupe benefit because the hash IDs for the copies would match either the source or some of the target extents that are associated with other copies. When such matching IDs are found in the hash table, a dedupe relationship is created.
- Dynamically changing compression settings on SGs—PowerMax compression is configured system-wide, but it is enabled or disabled at the SG level and can be changed dynamically. However, because PowerMax compression is activity-based, the effect might not be immediately noticeable. To minimize the impact on other workloads, compression-related movements occur at lower priority. Once the compression ratio is set on the SG, disabling it is possible but not necessary. The PowerMax compression engine compresses and decompresses data as needed to meet application performance requirements even when accessing a compressed dataset. PowerMax dedupe also relies on the compression setting on the SG; therefore, disabling compression on an SG also prevents the SG devices from realizing the dedupe benefit, and degrades the data efficiency.
- Expectation of the compression ratio—Compressibility greatly depends on the dataset. Most live SQL Server databases exhibit compression ratios from 1.3 to 3.0, with compressible datasets on the PowerMax system likely resulting in a higher compression ratio due to better hardware acceleration. Unisphere for PowerMax can provide an indication of SG compressibility for PowerMax systems. With tools such as Dell EMC Live Optics, you can estimate compression ratio targets by collecting and analyzing statistics on random samples of the devices. After you configure the PowerMax system for compression, you can configure individual SGs for compression, and they will achieve their target compression ratio over time. Higher compressibility can potentially be achieved when the dataset has large blocks of fillers or blob data with a lot of cyclic/repeated patterns. PowerMax ACE determines the compressibility of the SG by scanning the contents and transparently moving the application data to highly compressible storage pools, improving the compression ratio of the SG. When the workload is run, compression targets are maintained because ACE decompresses the active dataset and assigns scores to the extents for further compressibility analysis. Less active extents remain on the compression storage pools that meet their potential compressibility.
- Compressibility of logs—SQL Server active log devices generally have lower compressibility, but as the logs fill up and are archived, the inactive nature of the archived logs results in higher compressibility of the log devices.
- SQL Server data and log devices in cascaded configuration—ACE collects statistics on 32 KB data extents for compressibility. Although SQL Server storage provisioning uses child SGs for data and log devices for data protection and manageability, these devices can be part of the same parent SG that has compression enabled. ACE still operates at the device level and achieves compression of various SQL Server objects in the most optimal fashion. Thus, best practices for storage provisioning with PowerMax compression are the same as the best practices associated with other PowerMax data services such as SnapVX and SRDF.
- SQL Server compression and encryption—SQL Server allows database table-level compression for rows and pages. Table-level compression is set up using the Data Compression Wizard. The compressibility is slightly better with SQL Server compression compared to PowerMax compression because SQL Server compression uses Microsoft proprietary technology that is based on SQL Server and it is aware of the block layout at the SQL Server level. However, SQL Server compression puts a greater demand on the host CPU to process compression and decompression on already compressed data that becomes active; thus, SQL Server-based compression affects the overall performance of the database and other applications running on the server. PowerMax compression is set up at the SG level and works within the PowerMax frame, benefitting all the database objects that are part of the SG, including the data, logs, indexes, and any support files associated with the application and database. When PowerMax compression is used, even external blob/object stores can be compressed without any impact to overall performance.
Although SQL Server and PowerMax compression can co-exist, any application performance benefits are realized at the expense of host CPU overhead resulting from SQL Server compression. The benefits are also short-lived because SQL Server reads in more data to decompress to align with server application needs. As the data is aged and the cache needs to be refreshed, any benefits are diminished and performance lowers to the same level as using only PowerMax compression, which incurs no CPU overhead. For optimal performance, if you have a choice, use PowerMax compression rather than SQL Server compression.
You can also use PowerMax compression when SQL Server data, connections, and stored procedures use SQL Server encryption. The compressibility of the data depends on the amount of redundancy or repeated patterns, but there is no reason not to use PowerMax compression even when the database is encrypted. Even if compressibility of the data is lower due to obfuscated data patterns, there is no overhead associated with compression, so application performance is not affected. In addition, using PowerMax compression on the storage enables the use of Data at Rest (D@RE) encryption, with an integrated/external key manager, which allows storage-level encryption for the highest level of security.