Microsoft SQL Server Acceleration Flash Buyer s Guide. Allon Cohen, PhD Scott Harlin. OCZ Storage Solutions, Inc. A Toshiba Group Company

Transcription

1 Microsoft SQL Server Acceleration Flash Buyer s Guide Allon Cohen, PhD Scott Harlin OCZ Storage Solutions, Inc. A Toshiba Group Company

2 Contents 1 Introduction Microsoft SQL Server Overview What are common Microsoft SQL Server DBMS data types? What are the common Microsoft SQL Server databases? What are the common Microsoft SQL Server applications? When should I use flash to accelerate my SQL Server application? Which flash form factors are best for my SQL Server application? Which performance metrics should I use to best compare flash solutions? Testing flash performance specific to SQL Server workloads What is the difference between flash volumes and flash caching, and when to use each? What kinds of SQL Server data should I place on flash? What capabilities verify data will be available on flash for SQL Server? What parameters should I consider if my SQL Server instances are virtualized? What native flash functionality does SQL Server 2014 provide? How can flash improve SQL Server ETL processes? How can implementation wizards affect the success of my SQL Server acceleration project? Flash Buyer s Checklist Introducing OCZ s ZD-XL SQL Accelerator Introduction Flash memory technology provides a perfect match to the performance requirements of enterprise and cloud database applications. In comparison to traditional hard disk drive (HDD) storage, flash-based storage uses significantly less electricity, has no moving mechanical heads or spinning disks, and reads and writes data significantly faster handling random data access effortlessly while completely outperforming the slower electromagnetic media. The purpose of this Flash Buyer s Guide developed by OCZ Storage Solutions a Toshiba Group Company is to provide database administrators (DBAs) and IT managers responsible for the success of their enterprise database applications with key guidelines on when and why to deploy flash in a Microsoft SQL Server environment and how to accelerate this application effectively using solid-state storage. The guide details typical and common questions asked by DBAs and IT managers when considering flash usage in their environments and provide answers to those questions with solutions and capabilities that accelerate Microsoft SQL Server applications. 2

3 Included in the Flash Buyer s Guide is a checklist that can be used when comparing the variety of offerings available from various flash storage vendors, as well as a short introduction to how OCZ accelerates SQL Server applications through its award-winning ZD-XL SQL Accelerator PCIe card. 2 Microsoft SQL Server Overview SQL Server is a database management system (DBMS) developed by Microsoft designed for enterprise environments. It is a software product whose primary function is to store and retrieve data as requested by other applications (either on the same computer or on another computer across a network). There are different editions of Microsoft SQL Server aimed at various audiences with workloads that include OnLine Transaction Processing (OLTP), data warehousing, data mining, OnLine Analytical Processing (OLAP), to name a few. As the most pervasive DBMS solution in the market, Microsoft SQL Server provides enterprises of all sizes with a wide range of transactional and analytical capabilities to solve critical business needs. Being data access intensive, one of the major factors affecting its performance is the strength of the underlying storage resources. The speed of the storage implementation is determined by the time it takes to scan and analyze large portions of data as well as the amount of concurrent commands that the storage device can process ultimately determines whether users receive the business insight they need, when they need it. To enable a large number of users to be serviced without contention, and to maximize each user s application experience, the underlying storage metrics particular to SQL Server workloads must deliver optimal performance. Providing immediate access to data becomes especially critical during peak usage so that productivity is not adversely affected. Transactional access rates and database read bandwidth can significantly impact the time it takes to complete queries in enterprise and cloud environments. New technologies introduced in Microsoft SQL Server 2014, such as in-memory columnar processing and buffer pool extensions further enhance SQL Server performance, far bypassing the capabilities of traditional HDD storage. With the parallel growth in server CPU power and memory, a matching storage paradigm is required to achieve the full benefits and new capabilities presented by SQL Server What are common Microsoft SQL Server DBMS data types? Microsoft SQL Server is a DBMS that lets users create and access data in a database and manages these user requests freeing them and other application programs from having to know where data is located on storage media. As a DBMS, it ensures that data continues to be accessible, is consistently organized as intended, and is secured so only those with access privileges can access the data. 3

4 The most common DBMS is a relational database management system (RDBMS), as the standard user and program interface is the Structured Query Language (SQL). A DBMS can be thought of as a file manager that manages data in databases rather than files in file systems. Microsoft SQL Server is a DBMS that serves database requests from multiple users and includes three distinct data types: 1. Data records and indexes (referred to as database data) 2. Transaction logs (referred to as the write log files) log user transactions and are also used for recovery and data replication 3. TempDB files use a temporary database to store transient, non-persistent data 2.2 What are the common Microsoft SQL Server databases? Microsoft SQL Server databases typically fall into two primary categories, either transactional or analytical, with records presented as either row or columnar based. Transactional Databases These databases facilitate and manage all online transactions capturing information surrounding a business transaction (e.g. a sale) while enabling the data to be segmented, grouped, stored or retrieved for a specific use-case. This type of data commonly includes data items such as products ordered, sales prices, shipping and routing information, method of payment, applied warranties/rebates /discounts, sales location and any number of other variables available through the recording of transactions. Analytical Databases These databases selectively extract data for analysis and provide varying points of view of the data captured. As an example, this type of data enables users to analyze products sold in a geographic area, during a specific month, compared to revenue during another month, or a comparison of other product sold during the same time period, etc. To facilitate this kind of analysis, the data in some cases is stored in a multi-dimensional database (versus a relational database) that considers each data attribute (such as product, geographic sales region, and time period) as a separate dimension for analysis. Row-Oriented Databases A DBMS that stores data in rows, sometimes referred to as a record, and includes a set of database fields within a table relevant to a specific entry. For example, in a table called customer contact information, a row may contain the following fields: ID LastName FirstName Bonus 132 Doe John Smith Will Jones Mike

5 In a row-oriented DBMS, each record would be stored as a unit. In the above example, three units would be stored and include {132, Doe, John, 8000}, {133, Smith, Will, 4000} and {134, Jones, Mike, 2000}. Column-Oriented Databases A DBMS that stores data in columns (instead of rows) so that data can be highly compressed enabling operations to be performed very quickly as the number of data elements that typically must be read by the database engine while it is processing queries is greatly reduced. Also, since columnar databases are self-indexing, they require less storage space. Using the example from the Row-Oriented records, in a column-oriented DBMS, each record would be stored as a unit as follows: {132, 133, 134}, {Doe, Smith, Jones}, {John, Will, Mike} and {8000, 4000, 2000}. 2.3 What are the common Microsoft SQL Server applications? Microsoft SQL Server applications typically fall into three primary categories including OnLine Transaction Processing (OLTP), OnLine Analytical Processing (OLAP) and data mining. A brief description of each now follows: OLTP A database application that facilitates, manages, and processes transactions. A primary example includes data entry and sales order retrieval in support of a number of industries. The key to supporting OLTP applications in the enterprise is to enable a large number of users to be serviced without contention and to deliver optimal storage latency and transactional IOPS. SSD flash memory provides a perfect fit for the data access requirements of OLTP applications through its support of ultra-low latencies and the ability to efficiently handle randomized data access requests. OLAP A database application used to selectively extract data for analysis and to provide varying points of view of the data captured and helps enable companies and organization to make better business decisions. As it relates to marketing applications, OLAP is commonly used to verify or prove the effectiveness of existing marketing campaigns. In many cases, the data to be used for OLAP is collected into a central repository commonly called a data warehouse. Data from various OLTP applications and other sources are selectively extracted and organized onto the data warehouse database for use by analytical applications and user queries. A Microsoft SQL Server data warehouse can include hundreds of thousands of products and a few million records (typical in today s enterprise) so the accuracy of the information and the ability to deliver data in real-time to customers can be the difference in securing customer orders and providing a heightened experience. 5

6 Data Mining In data mining applications, miners sort through huge data sets using sophisticated software to identify undiscovered patterns and establish hidden relationships, whereas data analytics focuses on the process of deriving a conclusion based solely on what is already known. Typical data mining parameters include: Association: searches for patterns that connect one event to another Sequence (Path) Analysis: searches for patterns where one event leads to another later event Classification: classifies new facts into previously discovered patterns Clustering: finds and visually groups facts into distinct classes Forecasting: discovers patterns in data that can lead to reasonable future predictions known as predictive analysis 3 When should I use flash to accelerate my SQL Server application? A DBA or IT manager will definitely know when they have a performance issue to address when either end users complain about performance or when the CFO complains about SAN and server expenditures. Microsoft SQL Server performance can be affected by multiple external factors such as the underlying networking, slow CPUs, and limited memory allocation, but the collective experience of many DBAs has shown that in a majority of cases, the culprit is slow storage. The following highlights key signs that indicate the enterprise environment can benefit from using flash to accelerate SQL Server applications. Low CPU Utilization during Peak Usage Times During high workload events when memory fills up, SQL Server often requires frequent access to data pages from underlying storage. Low CPU utilization coupled with high memory usage is an indicator that the processing cores are wasting idle cycles waiting for data to arrive. In these cases, deploying flash services quickens data access and dramatically improves CPU utilization. SAN Controller I/O at Maximum Performance If SQL Server is saturating the underlying SAN, all other applications attempting to access the SAN will also be affected. The performance bottleneck will spread from SQL Server to other applications. On-host flash resources, such as PCIe cards, enable the data hungry SQL Server CPUs to get the data they need locally, alleviating pressure on the SAN while enabling it to handle other applications. Excessive TempDB Usage TempDB files may contain interim results (such as transient calculation tables) that the server writes during the query and must read before being able to complete the query, therefore, write and read performance are critical for the timely execution of such queries. In multi-core systems, tempdb files may be written to and read from simultaneously creating random access patterns that are detrimental to HDD performance as its mechanical head moves from location 6

7 to location. Each movement takes time so the read/write IOPS performance and latency slows down considerably until data is found and accessed. In contrast, tempdb usage patterns are. Low memory creates further loads on tempdb files as SQL Server uses it to store interim results when main memory runs out. Utilizing flash storage, tempdb performance can be dramatically improved and an excellent fit for SSDs as it seamlessly handles random read and write loads. Frequent Storage and Server Upgrades If an IT department is constantly upgrading the SAN due to growing usage, or if more servers are being purchased to improve performance while CPU utilization for each server remains low, introducing flash into the environment will efficiently extend CPU utilization on existing servers and gain the required performance benefits while reducing licensing, OPEX and CAPEX costs in the enterprise. 4 Which flash form factors are best for my SQL Server application? The main flash-based SSD formats fall into three categories: PCIe Flash Cards a high-speed expansion card format that connects enterprise servers to peripherals in a serial interface format. Every device connected to a motherboard using PCIe can use multiple point-to-point connections called lanes. As a result, PCIe-connected devices can aggregate bandwidth, which in turn, enables more scalable performance, lower latency and higher data transfer rates making these devices ideal for SQL Server applications. As a server-side flash solution, PCIe cards are typically compact, power-efficient and fit directly into the server s PCIe bus to increase server application performance while delivering fast and reliable access to data without burdening host CPU and memory resources. The interface supports different size formats of PCIe cards such as Full Height/Full Length (FH/FL), Full-Height/ Half-Length (FH/HL) and Half-Height/Half-Length (HH/HL). SAS or SATA SSDs These flash-based drives are packaged in the same form factor as traditional HDDs so they can be ubiquitously deployed and utilized in practically any server or storage slot initially designed to hold HDDs. SAS (Serial Attached SCSI) and SATA (Serial Advanced Technology Attachment) are both industry standard connections used to connect HDDs, and now flash-based SSDs, into a computer system based on serial signaling technology. One drawback of both SAS and SATA is that these form factors were originally designed for HDDs, so that the power that can be drawn and used by SSDs is limited affecting each SSD s peak performance. Storage capacity is also capped by the amount of flash that can actually fit into these smaller HDD enclosures. Finally, bandwidth is also limited by SAS and SATA 7

8 interfaces to the maximal rates originally designed for mechanical HDDs in mind. To a certain extent, this limitation can be overcome by aggregating the bandwidth from multiple SSDs in an enclosure. External Flash Arrays External flash arrays offer a simple way to deploy large amounts of flash centrally to multiple servers. They connect to servers using traditional SAN and NAS interfaces and present flash to the array through networking protocols. Flash arrays enable relatively simple deployment because they do not require physical access to the host running SQL Server to deploy the flash. These external arrays therefore offer an excellent solution when the flash placed locally on the server is limited, as is the case in blade arrays. Flash arrays may be susceptible to networking and storage controller bottlenecks as they do not sit directly on the host PCIe bus. Latency will also be increased due to the extra network hops. 5 Which performance metrics should I use to best compare flash solutions? Flash storage vendors present performance data that covers various users and use cases so one must use caution when interpreting this data when it pertains to Microsoft SQL Server environments as this application has very particular data access patterns. As a result, some of the general performance data published by flash vendors may be irrelevant to the eventual performance one will actually obtain in a SQL Server environment. Typical parameters used to evaluate the total effectiveness of a storage system include input/output operations per second (IOPS), bandwidth and latency. Latency The time it takes to complete an operation. Typically the farther away the flash storage device is from the CPU accessing it, the more latency exists and the slower it is to complete an operation. As an example, a PCIe flash card that resides on the server s PCIe bus, in close proximity to the CPU, has significantly less latency than a SAS-based or SATA-based SSD residing on a shared storage network. HDDs have significantly higher latency than SSDs given the time it takes to move the read head to new locations. It is important to note that while latency measures the total time it takes to complete an I/O command, not all commands are identical. Commands are differentiated by their command size which reflects the amount of data that needs to be passed to or from an SSD. Small command sizes require the processing of small amounts of data and hence the latency to process them will typically be lower. Larger command sizes require the processing of larger amounts of data and hence take more time to process. For this reason low latency numbers published by flash storage vendors usually reflect very small command sizes. 8

9 For most transactional operations, SQL Server uses large command sizes typically ranging from 4KB to as high as 64KB, and therefore the lowest latency number published usually are not relevant to SQL Server performance. As most SQL Server applications run on multicore systems and issue multiple storage commands in parallel, the latency of a single I/O command will rarely be the determinant of overall performance. In most systems the ability to handle multiple concurrent commands is much more critical as indicated by IOPS performance. IOPS (Input/Output Operations Per Second) A measurement representing the total number of I/O operations that an SSD can perform in one second in context with the type of storage operation performed (read, write, hybrid) and the size of commands for the data being exchanged. While lowering latency does enable a higher number of IOPS (as more commands can be completed each second), latency is not the only factor determining IOPS. The second factor affecting IOPS performance is parallelism, which increases IOPS by enabling multiple commands to be processed in parallel. A PCIe flash card that employs parallelism will be able to process more commands per second and more effectively handle the concurrent requests of many CPU cores processing data in parallel for SQL Server queries. For this reason, a PCIe card with multiple controllers (or a controller with multiple cores) will usually fair better in SQL Server environment than a PCIe card with a single controller, even if it is capable of producing very low latencies of individual commands. While IOPS is usually a better metric to look at than latency for measuring SQL Server performance, remember that even when comparing IOPS it is important to consider command sizes relevant to SQL Server loads as they range from 4K to 64K. IOPS are particularly important as a performance indicator for transactional workloads (OLTP applications) which involve large, multiple, concurrent transactions. However, the performance of analytics and reporting workloads are sometimes governed by the ability to quickly read very large amounts of data for processing which is measured by the bandwidth indicator. Bandwidth Synonym for the data transfer rate and represents the amount of data that can be transferred in a given time period. SSD bandwidth is usually measured and expressed in megabits per second or gigabits per second (Mbps or Gbps). When SQL Server needs to access large amounts of data (such as entire tables) for analytical or report generation, it will attempt to read the largest sequential commands possible. In this scenario, the storage device will receive a series of very large sequential commands that can reach up to 256K per command. At this stage, the time it will take to complete such queries is no longer governed by a maximal IOPS count (as each command is in itself very large) but rather by the maximal bandwidth the SSD can produce. This will vary between manufacturers and between models as the maximum bandwidth can be limited by the interface (SAS/SATA/PCIe), by the power available to the SSD, by the controller(s) and by the internal handling of large data sets by the SSD (such as striping large commands between NAND chips). 9

10 5.1 Testing flash performance specific to SQL Server workloads While IOPS can help determine performance for transactional loads and bandwidth can help determine flash performance for analytical loads, in day to day activities the performance boost received through the use of flash is also dependent on other environment variables such as the CPU, amount of memory, and the design of the actual queries being performed by SQL Server. Therefore, the best measure for evaluating flash performance is to test with the specific SQL Server data sets and queries of your environment. If testing production data is not possible, standard benchmarks are available and can be helpful in indicating flash performance under typical database loads. Commonly used standard benchmark tests include TPC-C which simulates transactional loads and TPC-H which simulates analytical loads. Many manufacturers can provide you with the results of their testing based on these benchmarks and other tests. Using tools such as Hammer DB can help you generate emulated benchmark loads against SQL Server instances. 6 What is the difference between flash volumes and flash caching, and when to use each? A flash volume is a portion of a PCIe flash card or SSD that is exposed as a volume to the operating system so that data is written and read directly to flash. Flash volumes offer the highest possible speed for both read and write operations as they use flash directly for every command. As a result, flash volumes are particularly useful when both high write speeds and high read speeds are required by the application. A typical example is the tempdb file. When SQL Server does not have enough DRAM available, queries will automatically be written into a tempdb file. As the memory clears up, data in the tempdb file will immediately be read. This write operation followed shortly thereafter by a read operation of the tempdb file makes its performance highly susceptible to both read and write speeds. If the tempdb file resides on a remote SAN, these write and read operations can cause a considerable drop in SQL Server performance. Placing tempdb files on local flash volumes provide an immediate boost in application performance. A flash cache is a repository of flash memory storage that holds copies of certain portions of a database stored on another media such as HDDs. The cache enables requests for data to be fulfilled at greater speed and used in tandem with slower hard disk drives (HDDs) to improve data access times. Cache can be located in a server, storage device or network, and requires time for it to warm-up and populate. As more data enters the cache, more requests can be accelerated. A good example for flash caching occurs with large databases that will not fit into flash volumes. As database capacities grow beyond a certain point, it becomes are impractical or not cost-effective to place the entire database on SSD flash. Even though database files can reach terabytes in size, only the data within certain hot zones needs to be frequently accessed. Storing only data from these hot zones on flash cache allows for a major performance increase at a considerable cost savings. 10

11 There are two major use cases that require a SQL Server environment to use flash caching: When user databases are larger than the available flash resources In this use case, flash caching offers an excellent avenue to accelerate performance with lower amounts of flash when a caching algorithm is used that can select the right data to place on flash from the larger databases on the HDD volumes. Caching selection algorithms that are tailored to provide the highest benefit to a particular data access pattern are called optimized caching policies. It is useful to differentiate between transactional and analytical loads when caching data as their access patterns are very different, requiring each to have its own optimized caching policy. When enterprise environments use legacy SAN backup and High Availability functions In this use case, it is important to use write-through caching as it ensures that the data on the SAN always contains the latest data and is safe for backup and High Availability (HA) purposes. When an enterprise environment depends on its legacy SAN for backup and HA, caching will provide a way to benefit from flash while retaining all current procedures. While all-flash volumes provide the fastest performance, flash caching lowers CAPEX and OPEX by combining smaller amounts of flash with less costly HDDs. Selecting a flash solution that can easily shift between flash volumes and flash caching, or uses both modes concurrently for different databases, will future-proof the SQL Server environment for data growth. 7 What kinds of SQL Server data should I place on flash? SQL Server stores its databases in files, of which, the two most common are the main database file and the log file. TempDB files represent a third type of database file and discussed in Section V. Log Files These files are write-intensive with heavy reading occurring only when transactions need to be reconstructed due to an external event such as a power failure. For this reason, write-through caching (which accelerates reads but not writes) is not effective for use with log files. To accelerate log files, place them on a flash volume but make sure to maintain High Availability (HA) on this volume (e.g. with mirroring) to assure that the log file will not be lost if a flash failure occurs. Main Database Files The main database files are usually more balanced in terms of reads and write with actual read and write ratios dependent on the workload. When SQL Server requires a page from the database, it can load it into memory much faster if that page is on flash rather than on an HDD. As a performance guideline, the higher the probability that a page will be in flash when it is needed by SQL Server, the better SQL Server performance will be. This is typically measured by a metric called the hit ratio, or the percentage of time a request from SQL Server can be 11

12 answered by data in flash rather than SQL Server having to fetch the data from HDD storage. To improve hit ratios, the caching software needs to statistically process the data in real-time and intelligently select whether specific data elements are worth caching. However, the more analysis that the software performs in real-time, the higher the interference incurred on the data path, resulting in the classic data path design dilemma: If too much time is spent on deciding whether to cache a data element as it flows through the data path, data access to SSD flash can be slowed down. If too little time is spent on deciding whether to cache a data element as it flows through the data path, it s possible that the data cached will be useless to the application, or even worse, critical data can be flushed out of the cache. Caching performance can be improved when a system uses out-of-band processing to select what data to cache. 8 What capabilities verify data will be available on flash for SQL Server? Enterprise applications such as SQL Server are extremely vulnerable to cache policy optimization as they dynamically handle large amounts of data of constantly shifting importance. Data that is critical to cache at one point in time may be useless at another, and the selection of the best data to cache at each point in time is highly dependent on current access statistics. To assure high hit ratios, there are four basic methods to select data to be cached on flash. Hot Zone Detection A mechanism that pinpoints frequently accessed data locations in SSD flash volumes to help determine what data to cache and its relevance. The key to accelerating SQL Server is figuring out what data is important and worth caching so that the data on SSD flash is quickly accessible and relevant to the needs of the application. This method relies on optimized caching policies to determine the data to cache based on how hot the data is. A smart caching mechanism can detect where indexes are located within a file by monitoring the number of accesses to a zone. The located hot zones can then be used to determine what data is worth storing on the flash. Sequentiality Detection This data cache selection mechanism differentiates between relevant and irrelevant data access patterns and can filter out background processing tasks (such as error checking) to prevent irrelevant data from entering the cache. On the other hand, important sequential patterns (such as index creation) may be marked for special handling in the cache. 12

13 Command-size Inspection Commands are differentiated by their command size and reflect the amount of data that needs to be passed to or from an SSD. Inspecting the command sizes being generated by SQL Server enables differentiation between different types of data usages. Cache Analysis and Warm-up While hot zone detection is effective for transactional processing throughout the day, analytical processing requires a different method for selecting data to cache. Analytical processing often involves a periodic batch process that requires accessing specific types of data. For example, a SQL Server instance may be collecting sales data throughout the day, but at night, a report generation process may be collecting data from different sources to help develop a complete sales report comparing the day s sales activities to previous periods. In this scenario, hot zone detection will not be helpful for this type of analytics because the data being accessed is not the same data that was hot during the day. To achieve high hit ratios for analytics requires data access analysis and a pre-warming cache mechanism. Data access analysis monitors the data being accessed during a certain period of the day (in the example above it would monitor what data is accessed for report generation). After an analysis of the required data is performed, a pre-warming cache mechanism fetches this data just before generating the report verifying that the data is on flash at the precise time SQL Server needs it. 9 What parameters should I consider if my SQL Server instances are virtualized? Whether or not your SQL Server implementation is virtualized today, at some point in the future, some or all of the SQL Server instances may need to move to a virtualized environment. Selecting a flash acceleration solution that supports both virtualized and non-virtualized environments enables the flexibility to deploy SQL Server in either of these modes. Accelerating a virtualized SQL Server instance is similar in many respects to accelerating a physical SQL Server instance however there are a few additional considerations that must be taken into account when deploying flash into a virtualized environment. Flash Resource Sharing If the virtual environment includes multiple instances of SQL Server virtual machines (VMs) running concurrently, as well other application VMs that can benefit from flash resources as well, look for a solution that enables intelligent and efficient distribution of flash resources between all connected VMs. Additionally, when the solution allows you to virtualize flash as a highly available network-exposed resource, the flash can be shared amongst any VM in the cluster regardless of location making sure that no VM inefficiently occupies flash when it can be better used elsewhere in the environment. 13

14 High Availability Support One of the main reasons for deploying virtualization is the ability to provide High Availability (HA) should a server running the SQL Server virtual machine (VM) go offline for any reason. Therefore, users should look for flash acceleration solutions that either support SQL Server s native High Availability Always On Technology when deployed virtually or supports a virtualization platform s HA functionality such as VMware High Availability. Virtual Machine Migration While virtual machines (VMs) can migrate between physical servers in a cluster, flash is a physical resource that resides in a particular location in the enterprise. If the chosen solution does not allow exposing flash over the network, once a VM is migrated to a new server, it will lose connectivity to its flash cache, and that source application will experience a sharp drop in performance until data is reloaded over time to the new cache. Therefore, look for a flash solution that enables the dynamic migration of a VM from one storage system to another, with no VM downtime, service disruption or loss of cache to end-users. Remote Flash Access In some cases, SQL Server will run on remote servers while the flash resources are located remotely on either a different commodity server or storage appliance. Therefore, look for a flash solution that provides a connection from SQL Server to its flash resources remotely and can relocate SQL Server files to remote flash volumes, remote flash caching or a combination of both enabling SQL Server virtual machines (VMs) to continue enjoying the benefits of flash acceleration even when migrated between servers. 10 What native flash functionality does SQL Server 2014 provide? Recognizing the importance of flash for performance acceleration of SQL Server environments, Microsoft has added flash buffer pool extension (BPE) support to the SQL Server 2014 version release. Buffer Pool Extensions allow SQL Server users to define a file residing on flash so that the SQL Server instance can extend its memory buffer to flash. SQL Server uses the flash file to store clean buffer pages that it has no room for in memory. Assuming these pages will be needed by SQL Server again, they can be fetched faster by loading them directly from the flash buffer pool extension rather than from the database files. While it is important to make sure that the flash acceleration solution supports SQL Server 2014 Buffer Pool Extensions, it is also important to select a solution that extends and enhances the capabilities provided by BPE. For example, native BPE support can be activated at the SQL Server Instance level but cannot differentiate between different databases running in the environment. Therefore, to make sure that the flash is used to accelerate a key database critical for performance (without the flash being hogged by a less important but larger database), look for a solution that can selectively differentiate between databases and accelerate at a per database level. 14

15 Analytical loads are another key area in which the Microsoft BPE functionality can be extended by acceleration software. In this scenario, the BPE mechanism relies on data being accessed before loading it into the flash buffer extension. Therefore, if the data is only accessed one time each night (e.g. for nightly report generation), it will most likely not be in the flash when SQL Server requires it. If analytics are used with such recurring processes, look for a solution that provides analysis and warm-up scheduling to assure the data is loaded into the flash just before it is needed by the application. 11 How can flash improve SQL Server ETL processes? As it relates to managing databases, Extract/Transform/Load (ETL) refers to three separate functions that are combined into a single programming tool and can be used to acquire a temporary subset of data for reports or other purposes or a more permanent data set for the population of a data mart or data warehouse, the conversion from one database type to another, or the migration of data from one database or platform to another. Each process has a very distinct function as follows: Extract This function reads data from a specified source database and extracts a desired subset of data Transform This function works with the acquired data, using rules or lookup tables, to convert it to the desired state Load This function writes the resulting data (either all of the subset or just the changes) to a target database, which may or may not previously exist Depending on the size of data and database files, the ETL process can be long and time consuming. Look for a flash solution that has the ability to partition its flash for use as a flash volume, flash cache or a hybrid of both. The ability to partition flash volumes provide an optimized solution where the write log and tempdb data files benefit from high flash performance while hot areas of the database are flash cached for immediate use by SQL Server. The result enables all SQL Server data types to be optimized and accelerated. A flash solution that enables write-through caching functionality will allow you to load that data into flash as it is being loaded into an underlying database. When used as a mirrored volume for the ETL process, the most current data will already be cached on flash in the secondary replica significantly reducing ETL run times. 15

16 12 How can implementation wizards affect the success of my SQL Server acceleration project? Many DBAs are expert in database administration but are not as experienced in deploying flash into their enterprise environments, so simplifying the DBAs life through best practice guidelines for flash implementation is a benefit. Based on a simple to use and intuitive graphical user interface (GUI), implementation wizards are very helpful in guiding DBAs through a flash-based storage deployment. Adding best practice models of the flash-based resources can also provide efficient acceleration and quick plug-and-play set-up into existing SQL Server deployments. Look for flash solutions with intuitive GUI management wizards that can: Divide the flash resource into a volume section and a cache section Advise on what data and workloads to place on the flash volume or on flash cache Provide a list of the database volumes so that optimized policies can be used whether the workload is transactional or analytical Provide instructions on how to pre-warm the cache in advance of demanding and critical jobs 16

17 13 Flash Buyer s Checklist Category Functionality Solution A Solution B Supported Form Factors In-Server Installation (PCIe, SAS/ SATA ) External Appliance Support Random Read IOPS at 8K Random Write IOPS at 8K Performance Max Read Bandwidth Max Write Bandwidth Benchmark Performance (TPC-C, TPC-H, etc.) Performance under my test load Flash Volume Support Usage Mode Flash Cache Support Flexible concurrent usage Caching Policies for OLTP and analytics Caching Functionality Data Accesses Analysis Cache Warm-up Scheduling Database Level Acceleration Flash Resource Sharing Virtualization Support High Availability Support VM Migration and Remote Caching Support BPE SQL Server 2014 Flash BPE Enhancements Implementation Wizards Deployment and Management SQL Server Management Integration Central Management for multiple servers 17

18 14 Introducing OCZ s ZD-XL SQL Accelerator ZD-XL SQL Accelerator is a tightly integrated hardware/software, plug-and-play acceleration solution optimized for Microsoft SQL Server applications. It leverages OCZ s industry-proven PCIe SSD hardware and application-tuned software to deliver low latency flash that resolves potential SQL Server bottleneck issues enabling the flash to be deployed as a local flash volume, a flash cache for HDD volumes, or as a combination of both. The solution includes a combination of fast flash performance, a unique cache mechanism that makes advanced and statistically-optimized decisions on what data to cache, and a dynamic cache warm-up scheduler that enables workloads to be placed on flash cache in advance of demanding and critical jobs. This advanced PCIe accelerator card utilizes implementation wizards and step-by-step instructions to guide database administrators (DBAs) through the deployment process enabling best practice models of its flash-based resources to be simply and quickly set-up for efficient SQL Server acceleration. The intuitive GUI also divides the ZD-XL SQL Accelerator SSD resource into a volume section and cache section, advising DBAs on what data and workloads to place on flash. It also provides a list database volumes enabling DBAs to simply select the optimized policy to use on each workload and instructs them on how to pre-warm the cache in advance. Additionally, ZD-XL SQL Accelerator provides complete High Availability (HA) via Microsoft AlwaysOn Technology so not only can SQL Server environments function at the speed of flash, but in the event of planned or unplanned downtime, can continue operations from the stopping point retaining all of its data as if no downtime had occurred. With this level of functionality and performance, OCZ s initial ZD-XL SQL Accelerator release earned prominent reviews as well as the 2013 Best of Interop award in the Data Center & Storage category. In support of SQL Server 2014, ZD-XL SQL Accelerator enables its flash resources and associated management capabilities to connect directly to the application providing the utmost in application management integration. This tight integration of flash and application management enables ZD-XL SQL Accelerator to accelerate the application at a per database level versus having to accelerate all of the databases in the SQL Server instance. SQL Server can run on blade servers or specific rack-mounted servers except that the PCIe form factor does not fit making flash acceleration more difficult. OCZ enables flash acceleration for these instances by running ZD-XL SQL Accelerator software next to the database application on blade or rack-mounted servers while the SSD flash is located remotely on either a commodity server or storage appliance. As a result, ZD-XL SQL Accelerator software provides a direct connection from SQL Server to its flash resources remotely. Many enterprises benefit from the capability of running SQL Server in a virtualized environment. For these applications, ZD-XL SQL Accelerator supports both VMware ESXi and Microsoft Hyper-V hypervisors enabling its flash resources to be deployed exactly to the needs of VMs while retaining the application connection in the virtualized environment. 18

19 Contact us for more information OCZ Storage Solutions 6373 San Ignacio Avenue San Jose, CA USA P E sales@oczenterprise.com W ocz.com/enterprise SALES TEAM VISIT OCZ ENTERPRISE Disclaimer OCZ may make changes to specifications and product descriptions at any time, without notice. The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors. Any performance tests and ratings are measured using systems that reflect the approximate performance of OCZ products as measured by those tests. Any differences in software or hardware configuration may affect actual performance, and OCZ does not control the design or implementation of third party benchmarks or websites referenced in this document. The information contained herein is subject to change and may be rendered inaccurate for many reasons, including but not limited to any changes in product and/or roadmap, component and hardware revision changes, new model and/or product releases, software changes, firmware changes, or the like. OCZ assumes no obligation to update or otherwise correct or revise this information. OCZ MAKES NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE CONTENTS HEREOF AND ASSUMES NO RESPONSIBILITY FOR ANY INACCURACIES, ERRORS OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION. OCZ SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE. IN NO EVENT WILL OCZ BE LIABLE TO ANY PERSON FOR ANY DIRECT, INDIRECT, SPECIAL OR OTHER CONSEQUENTIAL DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF OCZ IS EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. ATTRIBUTION 2014 OCZ Storage Solutions, Inc. A Toshiba Group Company. All rights reserved. OCZ, the OCZ logo, OCZ XXXX, OCZ XXXXX, [Product name] and combinations thereof, are trademarks of OCZ Storage Solutions, Inc. A Toshiba Group Company. All other products names and logos are for reference only and may be trademarks of their respective owners. 19