This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Reference architectures are an attractive alternative to DIY solutions. Reference architectures enable you to leverage the expertise of multiple vendors working together to construct a solution that will provide proven performance with no risky trial-and-error guesswork.

There are several ways you can go about adding new servers into your organization’s IT infrastructure. You can do the research yourself and attempt to put together your own custom configurations, or you can use a reference architecture.

Doing it yourself can be tricky. Not only do you have to research the server itself, but you also have to figure out the network and storage requirements, not to mention the configuration of all the different components. The process often comes down to trial and error, and it can be expensive if you get it wrong.

Reference architectures are an attractive alternative to DIY solutions. Reference architectures enable you to leverage the expertise of multiple vendors working together to construct a solution that will provide proven performance with no risky trial-and-error guesswork. Hardware and software vendors each bring their own expertise to bear on a given solution or ranges of solutions—all of which are field-tested to ensure that they work before the reference architecture is published.

The HPE-MS Superdome X and SQL Server Reference Architecture

HPE and Microsoft have worked together to create reference architecture for the HPE Superdome X and SQL Server 2016. HPE and Microsoft developed a solution guideline for running SQL Server 2016 data warehousing and analytics on the HPE Superdome X server with HPE 3PAR StoreServ.

The Superdome X platform can scale from a single blade solution up to eight blade servers, and each blade can have up to 48 cores and 3 TB of memory. Supporting up to 24 TB of RAM, the extremely scalable and high-performing platform is designed to support demanding data warehousing and analytics workloads.

The HPE Superdome X also allows a single-server solution to be logically partitioned to support multiple environments and workloads. The Superdome X’s ability to support multiple partitions (called nPars) enables the server to be appropriately sized for any workload. In addition, you can freely reallocate resources like processors, memory and storage as your business needs change.

The Superdome X does not have any local storage. The OS and other storage are delivered using Fibre Channel-attached storage. For the reference architecture configuration, the HPE 3PAR StoreServ 8450 storage array was selected for its storage capacity and scalable performance capabilities. An all-flash array, the HPE 3PAR StoreServ 8450 can support multiple types of database workloads, including I/O-intensive OLTP and read-heavy data warehouse workloads. Both the Superdome X and the 3PAR StoreServ are on a shared 10 Gb Ethernet network for end user and administrative connectivity. You can see an overview of the HPE Superdome X configuration in Figure 1.

The HPE Superdome X solution used in this reference configuration is connected to the HPE 3PAR StoreServ 8450 storage with eight separate connections between the array and the Superdome X. There are two SAN switches on the Superdome X chassis and four controllers on the HPE 3PAR StoreServ 8450 storage array. Each of the switches on the Superdome X has four wired connections to the switches on the storage array. The switch wiring is completely redundant to provide double the storage bandwidth between the Superdome X and the storage array, as well as high availability. All eight connections are rated at 16 Gb.

Each blade in the configuration used about 2,000 warehouses, with a core SQL Server database of about 1 TB of data, 500 GB of secondary indexes, and 500 GB allowed for the transaction log. The operating system was stored using RAID 1, and data files were stored using RAID 5. The transaction log was on a dedicated RAID 1 drive.

SQL Server 2016 was deployed using the default configuration with the exception of three custom settings: