Infrastructure Solutions for Microsoft SQL Server

Infrastructure Solutions for Microsoft SQL Server
Information Infrastructure Solutions

EMC Proven Solutions What to expect Full-stack testing
Not just interop Shared deployment risk with EMC Decreased deployment/testing cycles Assured performance Verified building blocks for scalability

Proven Solutions approach
Title Month Year Proven Solutions approach Capture & Define Test and Validate Document Publish 1 2 3 4 Requirements Singapore Shanghai, China Cork, Ireland Hopkinton, MA Santa Clara, CA Vienna, Austria

Why EMC for Microsoft SharePoint Server Technical Overview May 2009
Solutions Overview for Microsoft Applications Tiered/ Unified Storage Replication, Backup and Recovery Business Continuity Security Virtualization and Private Cloud EMC for Microsoft SharePoint Infrastructure allows you to address your complete information infrastructure requirements for SharePoint. EMC provides: Tiered Storage and Unified Storage as a solid foundation to deploy SharePoint: Cost effective, scalability, performance for any size SharePoint environment Flexibility to grow as requirements change Proven and documented best practices for optimal layout and design to ensure scalability Easily manage tiered storage with non-disruptive migration of data with Virtual LUN technology Virtual Infrastructure: Lower TCO by maximizing server and storage utilization Lower energy costs Maximizes service levels by enabling flexibility and ensuring quality of service Support Microsoft HyperV and VMware Infrastructure Backup, Recovery, Archive Unified protection for all Microsoft Applications Schedule, create, and manage VSS snapshots – VSS consistent point in time copies With deduplication, enable fast full backups at the source Simple, affordable, and secure platform for SharePoint data archiving Business Continuity Unified protection for all Microsoft Applications: recovery for local or remote site to any point in time Replicate to a transaction consistent state and enable any-point-in-time recovery Roll back and recovery to specific point in time Granularity and consistency of recovery across federated environment to meet SharePoint requirements Enterprise Content Management SharePoint Integration for content services and archive services Common enterprise wide content management platform: complete archival , capture and records management Flexible policy based archiving to centralized enterprise infrastructure based on Documentum Security Discovery of sensitive information on SharePoint sites Information rights management through integration of DLP and MS RMS Central entitlements management – protect data based on content, context and identify Monitoring and reporting of user access and activities Let’s discuss each of these solution areas in more detail. Note to Presenter: At this point you may which to select from the following slides based on your account interests. Symmetrix VMAX VNX VNXe IOmega VMware vSphere Microsoft Hyper-V VBlock VPLEX Replication Manager NetWorker Avamar Data Domain EMC Disk Library (EDL) Cluster Enabler RecoverPoint vCenter SRM SRDF MirrorView Celerra Replicator RSA Data Loss Prevention Suite RSA SecureView RSA enVision RSA SecurID RSA Adaptive Authentication Proven Solutions, White Papers and Best Practices

SQL Server Always On - I/O Reliability Program
Title Month Year SQL Server Always On - I/O Reliability Program A Microsoft validated program for storage solution that complies with a set of core technical criteria to ensure the highest level of availability for mission critical SQL applications All EMC storage arrays adhere to and can enforce write ordering consistency Adherence to SQL Server Write Ahead Logging (WAL) Protocols with EMC’s Consistency Technology (transactional integrity) Onboard protected caching to optimize I/O operations EMC storage platforms will not transition asynchronous I/O operations from a host into synchronous ones SQL Server Storage Solution Review Program is a specific SQL Server Always On program that enables storage solution providers to highlight those storage solutions and configurations via the SQL Server Always On labeling successfully reviewed against core functional Microsoft SQL Server storage requirements Microsoft SQL Server Database Engine Input/Output Requirements

Enterprise Flash Drives and SQL Server
What to expect Decreased response time More throughput Smaller footprint, less power Enable the use of nl-SAS with FAST

Enterprise Flash Drives with SQL Server
EMC Innovation for Symmetrix DMX Series February 2008 Decrease response time and improve scaling with assurance Response time can be as low as 1ms (x10 faster than 15k FC disks) Single Flash drive can deliver up to x30 IOPS than FC disk Smaller footprint and reduced energy requirements by ~38% Read intensive workloads with low cache read-hit rate Random I/O patterns Small I/O requests (up to 16KB) Extremely low latency, high transaction throughput

Enterprise Flash Drives with SQL Server
EMC Innovation for Symmetrix DMX Series February 2008 Decrease response time with assurance Selected Tables Implementing table partitioning for read intensive tables Significant performance improvement TempDB Typically generates large sequential I/O , but in some instances I/O can be very random Moderate performance improvement Index Transaction Logs Testing has shown no performance benefit over FC+Array write cache

Reference Architecture: Tiered Storage
Tiered storage design with: CLARiiON CX4-960 Two-node active/passive failover cluster Storage connectivity - 8 Gb/s FC Network connectivity - 1 GbE Workload OLTP with TPC-E like standard Number of customers: 75,000 User data: 789 GB Expected throughput: 10,000 IOPs

Reference Architecture Layout – (FC ONLY)
Title Month Year Reference Architecture Layout – FAST (Flash+FC) Reference Architecture Layout – (FC ONLY)

Layout with Flash & FC Drives
Maintain performance with less acquisition cost

Maintain performance with smaller footprint

The table below highlights the results identified between our baseline configuration of 90 FC drives compared to 30 FC drives with 4 Flash Configuration All Fibre Channel Tiered Flash/FC Disks 90 FC 30 FC / 4 Flash Tested TPS Baseline 2.4% Improvement Tested IOPs 4.2% Improvement Management 80% Less Time Acquisition Cost 38% Less Cost Power/Cooling 45% Less Cost

FAST VP for Virtualized SQL Servers Reference Architecture
Storage Two Engine VMAX 1 GigE Ethernet network VMFS Datastore VMware Four SQL VMs (Hot/Warm) 8 vCPU, 16GB RAM

Improving Performance and Efficiency
Performance and Capacity IOPS TPS Formatted capacity (GB) 64 FC 10559 1504 14400 4 Flash + 28 SATA 11439 1663 14936 Change +8% +11% +4% CAPEX and OPEX Cost Disk drives Annual power consumption* Total cost >10 yrs 64 FC $145,280 $3,196 $177,240 4 Flash + 28 SATA $99,140 $1,296 $112,100 Cost saving $46,140 $1,900 $65,140 % Saving 32% 60% 37% -32% -60% -37% Note: The tested 2 tiers approach is a viable option and not necessarily a best practice

Transaction Throughput
Performance Use FAST Cache to substantially improve OLTP throughput Improve performance without complex data migration No downtime No application impact No schema changes Improvement is dependent on several factors Locality of Data Ratio of Data to Cache Transaction Throughput Over 3x Configuration 1 is 6 FC spindles (4 for DB, 2 for Log; in RAID 1 or RAID 10 configuration) Max Supported TPS/Ravg figures. Next sample breached gating metric. ( 2 second Average Response Time (Ravg)) FC Only – 346 TPS, 1.6s Ravg FC + FAST – 1328 TPS, 1.7s Ravg Configuration 2 is 20 FC spindles (16 for DB, 4 for Log; in RAID 10 configuration) FC Only – 1322 TPS, 1.7s Ravg FC + FAST – 4455 TPS, 1.9s Ravg

Improve Capacity Utilization by 4x
Efficiency Use FAST Cache to increase utilization while maintaining performance Configuration 1 is 6 FC spindles (4 for DB, 2 for Log; in RAID 1 or RAID 10 configuration) Max Supported TPS/Ravg figures. Next sample breached gating metric. ( 2 second Average Response Time (Ravg)) FC Only – 346 TPS, 1.6s Ravg FC + FAST – 1328 TPS, 1.7s Ravg Configuration 2 is 20 FC spindles (16 for DB, 4 for Log; in RAID 10 configuration) FC Only – 1322 TPS, 1.7s Ravg FC + FAST – 4455 TPS, 1.9s Ravg Improve Capacity Utilization by 4x Equivalent Performance

Ease of Use Traditionally Databases have hot and cold areas
FAST can eliminate complex data architecture projects Traditionally Databases have hot and cold areas Common Approach Manually partition database for TODAY’s workload Problem: Complicated, downtime required, costly and only solves it for the present. FAST Approach No Manual steps required Adapts dynamically to changing access patterns Grow storage tiers as needed without any application level impact

FAST Cache and SQL Server
Improve storage efficiency Eliminate short-stroking Reduces power and cooling requirements

Improvement might not be immediate
FAST requires time to monitor the system and move data around. Typically happens on a daily schedule Does not adapt to mid-day changes in workload FAST Cache requires multiple accesses to promote data Lab testing shows few hours between Cache available, and fully used. TPS Improvement within 5 hours

vfCache What to expect Massively decreased read response time
Massively increased scale of performance Reduced workload on existing SAN fabric and arrays Licensing cost savings through increased consolidation

EMC VFCache Improves Server Performance
Server Flash caching solution that uses intelligent caching software and hardware technology to reduce latency and increase throughput “Hottest” data accessed through VFCache in the server providing increased performance VFCache benefits SQL Server 2012: Lower database I/O latency by 60% 50% more I/O serviced within 1 ms 4X more transactions per SQL Server database Perfect fit for OLTP workloads Incorporating tiering and Flash into storage is a powerful solution to increasing performance for database systems and applications. However, certain application workloads will require bringing the compute closer to the application and database servers to reduce latency. EMC is now offering Server Flash caching which leverages PCIe Flash technology embedded in traditional or virtualized servers to reduce latency and increase throughput. This extends FAST into the server itself, so we can now tier performance not just at the storage level but at the server level. Through using Server Flash we can shorten the distance application I/O needs to travel allowing the hottest data to be accessed on the PCIe card in the server decreasing latency which increases performance. Through EMC SQL Server 2012 testing we were able to demonstrate a total transaction throughput of 4x with 60% decreased latency…..and more than 50% of I/O operations were now being serviced in less than 1 millisecond all that comparing to a standard EMC tiered storage environment. VFCache provides read caching, while any write request is serviced directly by the storage array, hence it is more efficient with OLTP workloads which are more read centric and involve smaller and highly random I/Os. Transactions Per Minute (TPM) Read Latency (Sec)

Total Protection Write-through caching to the array
Data persists down to EMC Symmetrix VMAX and EMC VNX networked storage to ensure high availability, end-to-end data integrity, data reliability, and disaster recovery Sharable and scalable No stranded storage While other vendors promise the performance of PCIe Flash technology, VFCache provides this performance with protection. VFCache protects data by leveraging a write-through algorithm, which means that writes persist to the back-end storage array. Data is protected by the advanced data services that EMC’s trusted networked storage such as Symmetrix VMAX and VNX provide, including high availability, data durability, reliability, and disaster recovery.

Read Hit Example Read request from application to an accelerated array LUN VFCache Driver determines a hit occurred and accesses data from Flash device Data returned from the Flash device is forwarded to the application Application 1 3 Note to Presenter: Click now in Slide Show mode for animation. In the case of a read hit, the application issues the read request. As a side note, VFCache is completely application-agnostic and is not even aware that VFCache is sitting below it. After the application issues the read request, VFCache picks up that read request and does a very quick lookup in its memory tables. VFCache sees that it can satisfy the read request within its PCIe Flash. It then goes to get that data from the card and delivers that data back to the application. This is where all the performance comes from. By not having to go out to the storage array to satisfy the read request, VFCache is able to satisfy the read request in less than 100 microseconds, as opposed to the normal networked storage time, which could be multiple milliseconds. VFCache Driver 2 SAN HBA PCIe Flash SAN storage

Read miss data is written to Flash device asynchronously
Read Miss Example Read request from application to an accelerated array LUN VFCache Driver determines a miss occurred and accesses data from array LUN Data is read from the array and returned to the application Read miss data is written to Flash device asynchronously Application 1 3 Next, let’s talk about a read miss. Note to Presenter: Click now in Slide Show mode for animation. Again, the application issues the read request. The VFCache driver picks up the read request, looks it up in its memory tables, sees that it does not have that data sitting in its cache, and then simply sends the read request down the stack so that the back-end storage can satisfy the read request. Once the storage array receives the read request, it processes the read request and delivers the data back to the application. The VFCache driver then writes the missed read to the cache for any future reads of that data. This is, of course, done asynchronously so that the application does not have to wait. VFCache Driver 2 4 SAN HBA PCIe Flash SAN storage

Write data is asynchronously written to Flash device
Write Example Write request from application to an accelerated array LUN VFCache Driver writes data to array LUN Application write acknowledged upon array completion Write data is asynchronously written to Flash device Application 1 3 Finally, here is how a write operation is handled. Note to Presenter: Click now in Slide Show mode for animation. The application issues the write request. The VFCache driver looks at the write request; since it’s a write, it simply passes the write request down to the back-end storage. The back-end storage picks up the write request and processes the write like it normally would in order to ensure persistence of the data for protection. The storage then sends an acknowledgement back to the application. The application then continues processing. The VFCache driver then writes the write request to the cache for any future reads of that data. It is important to note that VFCache employs an LRU (Least Recently Used) algorithm to determine which data should stay within its cache, thus ensuring the hottest, most frequently accessed data stays in the cache for optimal performance results. VFCache Driver 2 4 SAN HBA PCIe Flash SAN storage

The VFCache Effect More transactions, less waiting Response time 50%
Here is an example of the effect that VFCache can have on your application. This shows a typical use case, a 1.2 TB Oracle Database application, before and after VFCache was implemented. In this example, VFCache was able to increase throughput by 2.3 times, simultaneously reducing response time by 50 percent. The results you will achieve will vary depending upon the read/write ratio and read hit rate of your specific application. This particular workload had a typical Oracle read/write ratio of about 70/30 and a read hit rate of about 80 percent. Response time 50% Throughput 210% Measured workload example: TPCC-like workloads on Oracle and DB2 (1.2 TB database)

VFCache for SQL Server - Architecture

VFCache for SQL Server - Impact

Solutions Overview for Microsoft Applications Virtualization and Private Cloud Tiered/ Unified Storage Replication, Backup and Recovery Business Continuity Security EMC for Microsoft SharePoint Infrastructure allows you to address your complete information infrastructure requirements for SharePoint. EMC provides: Tiered Storage and Unified Storage as a solid foundation to deploy SharePoint: Cost effective, scalability, performance for any size SharePoint environment Flexibility to grow as requirements change Proven and documented best practices for optimal layout and design to ensure scalability Easily manage tiered storage with non-disruptive migration of data with Virtual LUN technology Virtual Infrastructure: Lower TCO by maximizing server and storage utilization Lower energy costs Maximizes service levels by enabling flexibility and ensuring quality of service Support Microsoft HyperV and VMware Infrastructure Backup, Recovery, Archive Unified protection for all Microsoft Applications Schedule, create, and manage VSS snapshots – VSS consistent point in time copies With deduplication, enable fast full backups at the source Simple, affordable, and secure platform for SharePoint data archiving Business Continuity Unified protection for all Microsoft Applications: recovery for local or remote site to any point in time Replicate to a transaction consistent state and enable any-point-in-time recovery Roll back and recovery to specific point in time Granularity and consistency of recovery across federated environment to meet SharePoint requirements Enterprise Content Management SharePoint Integration for content services and archive services Common enterprise wide content management platform: complete archival , capture and records management Flexible policy based archiving to centralized enterprise infrastructure based on Documentum Security Discovery of sensitive information on SharePoint sites Information rights management through integration of DLP and MS RMS Central entitlements management – protect data based on content, context and identify Monitoring and reporting of user access and activities Let’s discuss each of these solution areas in more detail. Note to Presenter: At this point you may which to select from the following slides based on your account interests. Symmetrix V-Max VNX VNXe IOmega VMware vSphere Microsoft Hyper-V VBlock VPLEX Replication Manager NetWorker Avamar Data Domain EMC Disk Library (EDL) Cluster Enabler RecoverPoint vCenter SRM SRDF MirrorView Celerra Replicator RSA Data Loss Prevention Suite RSA SecureView RSA enVision RSA SecurID RSA Adaptive Authentication Proven Solutions, White Papers and Best Practices

Virtualizing SQL What to expect Reduced Licensing Cost
Smaller footprint More power efficiency Assured performance Simplified scaling Increased operational flexibility Simplified disaster recovery Simplified test/dev provisioning

~5-8x reduction in SQL licensing costs
16 Physical SQL Servers Enterprise Edition 64 core licenses* Cost: $439,936 (minimum) * MS licenses a minimum of 4 cores per server. Frequently it’s more. 16 Virtualized SQL Servers Enterprise Edition Two quad-core procs 2 vCPU per core* Cost: $54,992 - limited mobility (no SA) $96,236 - unlimited mobility (with SA) * MS recommends up to 8 vCPUs/core with Hyper-V

Key Benefits – Server Virtualization
Consolidation - Achieve 2-10x consolidation ratio, especially for larger deployments Lower TCO - Significant power, cooling and data center space Availability - Using a VM based protection for SharePoint provides homogeneous high availability (VMware HA, WFC) Business Continuity - Simplified disaster recovery management (vCenter Site Recovery Manager, Cluster Enabler) Maintenance - Live migration of virtual machines (VMware vMotion, Hyper-V Live Migration) Load Balancing - Maximized overall performance with balanced HW utilization across the farm (VMware DRS, SCVMM PRO) Rapid Provisioning and Scaling – Using VM templates for fast provisioning for easier scale-out

Approaches to SQL Server Consolidation
Title Month Year Approaches to SQL Server Consolidation Single instance - Databases consolidation Requires common configuration Preferably similar workloads Resource contention (Memory, TempDB..) Downtime/Maintenance impact Limited performance management Multiple instances - Instance consolidation Per-Instance resource allocation Workload isolation Multiple VMs - Hypervisor consolidation Better isolation Dynamic resource management Faster deployment VI benefits (CPU/Memory over-commitment)

SQL Server Scaling In Virtual Deployments
Scale-Up Approach Multiple databases or SQL instances per VM Fewer ESX Servers Single point of failure Larger VM SMP overheads OS bottleneck, especially for 32- bit environments Scale-Out Approach Single instance/database per VM Better SQL Instance and workload isolation DSS vs. OLTP separation More granular change management DRS/VMotion more effective with smaller VMs VM1 VM2 ESX Server SQL_1 SQL_3 SQL_5 SQL_7 OS SQL_2 SQL_4 SQL_6 SQL_8 Virtual Machines ESX Server SQL_2 OS SQL_1 SQL_5 SQL_6 Virtual Machines ESX Server SQL_4 OS SQL_3 SQL_7 SQL_8

SQL Server Scale up performance Physical vs. Virtual
At 1-2 vCPUs, ESX achieves 92% of native throughput 4 vCPUs can reach 88% while 8 vCPUs 86% of native throughput At 1, 2 and 4 vCPUs on the 8pCPU server, ESX is able to effectively offload certain tasks to idle cores. The graph demonstrates the 1 and 2 vCPU virtual machines performing at 92 percent of native. The 4 and 8 vCPU virtual machines achieve 88 and 86 percent of the non-virtual throughput, respectively. At 1, 2, and 4 vCPUs on the 8 CPU server, ESX is able to effectively offload certain tasks such as I/O processing to idle cores. Having idle processors also gives ESX resource management more flexibility in making virtual CPU scheduling decisions. However, even with 8 vCPUs on a fully committed system, vSphere still delivers excellent performance relative to the native system. The scaling in the graph represents the throughput as all aspects of the system are scaled such as number of CPUs, size of the benchmark database, and SQL Server buffer cache memory. Table 8 shows ESX scaling comparably to the native configuration’s ability to scale performance Comparison Performance Gain Physical - 8 CPU vs. 4 CPU 1.71 vSphere vCPU vs 4 vCPU 1.67 36

Virtualized SQL Server - Connectivity Options
SQL 2008 on Windows 2008 performed similarly under virtual and physical machines The physical machine and virtual machine (MSI) saturate at 9,000 users VMFS, and RDM saturate at 8,000 users. VMFS performance drops rapidly once user saturation is reached Overall, the virtual machine performs almost identical as the physical machine for a disk configuration of (10+4). SQL Server 2008 on Windows Server 2008 performs almost identical in virtual machines and physical machines Users Transactions Per Second Physical Guest MSI VMFS RDM 8,000 415 414 403 411 9,000 461 460 330 425 10,000 456 353 375 VMware ESX - Performance/Connectivity options (iSCSI Connectivity, Avg., User response time <2.0 sec)

Solutions Overview for Microsoft Applications Virtualization and Private Cloud Tiered/ Unified Storage Replication, Backup and Recovery Business Continuity Security EMC for Microsoft SharePoint Infrastructure allows you to address your complete information infrastructure requirements for SharePoint. EMC provides: Tiered Storage and Unified Storage as a solid foundation to deploy SharePoint: Cost effective, scalability, performance for any size SharePoint environment Flexibility to grow as requirements change Proven and documented best practices for optimal layout and design to ensure scalability Easily manage tiered storage with non-disruptive migration of data with Virtual LUN technology Virtual Infrastructure: Lower TCO by maximizing server and storage utilization Lower energy costs Maximizes service levels by enabling flexibility and ensuring quality of service Support Microsoft HyperV and VMware Infrastructure Backup, Recovery, Archive Unified protection for all Microsoft Applications Schedule, create, and manage VSS snapshots – VSS consistent point in time copies With deduplication, enable fast full backups at the source Simple, affordable, and secure platform for SharePoint data archiving Business Continuity Unified protection for all Microsoft Applications: recovery for local or remote site to any point in time Replicate to a transaction consistent state and enable any-point-in-time recovery Roll back and recovery to specific point in time Granularity and consistency of recovery across federated environment to meet SharePoint requirements Enterprise Content Management SharePoint Integration for content services and archive services Common enterprise wide content management platform: complete archival , capture and records management Flexible policy based archiving to centralized enterprise infrastructure based on Documentum Security Discovery of sensitive information on SharePoint sites Information rights management through integration of DLP and MS RMS Central entitlements management – protect data based on content, context and identify Monitoring and reporting of user access and activities Let’s discuss each of these solution areas in more detail. Note to Presenter: At this point you may which to select from the following slides based on your account interests. Symmetrix V-Max Symmetrix DMX CLARiiON CX4 CLARiiON AX4 Celerra Unified Storage IOmega VMware vSphere Microsoft Hyper-V VBlock VPLEX Replication Manager Avamar NetWorker Data Domain EMC Disk Library (EDL) RecoverPoint SRDF MirrorView Cluster Enabler vCenter SRM RSA Data Loss Prevention Suite RSA SecureView RSA enVision RSA SecurID RSA Adaptive Authentication Proven Solutions, White Papers and Best Practices

Local Replication with EMC
What to expect Rapid data restores and backups regardless of data size Offloaded backups to increase potential operating/maintenance time Single management point for all your apps and platforms Automated repurposing for test/dev

SQL Operational Recovery - Know Your RPO&RTO
EMC Today March 2008 Daily Backup: Recovery point every 24 hours Recovery Gap Snapshots/Clones: Recovery point every 2-6 hours Recovery Gap Time-based CDP: Time indexed, but no SQL aware recovery points Time Based Recovery Points (T) Time CDP and/or CRR with SQL VDI Bookmarks: Application optimized recovery points Checkpoint Patch Post-Patch Cache Flush Eng. Version Release Hot Backup VDI Snapshot Unlimited Recovery Points with SQL Server Aware VDI Bookmarks (T) Time

Common Interface for Multiple Recovery Scenarios
Title Month Year File group Restore Allows you to restore a subset of the database at file group granularity Full Restore Restores the entire user database/s. This includes the data, log files, and, for SQL Server 2005/8, all full-text catalogs Replace Restore Rapid VDI based restore that skips all the checks (log backup, duplicate DB, duplicate filename) Advanced Recovery Recovery (PiT) No Recovery (For T-log replay) Standby (Read-Only) File System (Manually attach) RM provides crash-consistent access to the full protection window immediately after you run your first RM RP job! (slick feature) This means that even though RM may not have been around for the last few days, but we will still get your application up and running (provided volumes have not been added or deleted in the time of the protection) When you an RM job, it collects the most recent information about your application and stores it on the RM server in its own database. When you mount or restore your production server, RM uses this stored catalog information to determine which drive letters to mount and database instances to contact to perform an application attach or recovery operation. RM will copy this information when you ask for a point-in-time instead a replica to perform a mount or restore. The RM team always suggests that ALL restore operations occur only after that data has been mounted and verified first! On-demand mount allows single interface for all types of replicas RecoverPoint CDP bookmark, CRR bookmark, Crash Consistent Point-in-Time Copy Time slider for crash consistent point-in-time mount User-friendly name for ‘Any Point-in-Time’ event

Array and SAN replication for SQL
What to expect Database and application layer replication integration Decreased bandwidth consumption with RecoverPoint Simplified Failover Push-button failover with VMware SRM Automated failover with Cluster Enabler Transparent failover with VPLEX Possibility of zero data loss RPO with synchronous replication Extremely rapid RTO with CE/VPLEX

SQL Server Availability
Zero-Seconds Minutes Hours Hours Minutes Seconds Failover Cluster (Local) DB Mirroring (Sync) Cluster Enabler (Sync) Cluster Enabler (Async) Transactional Replication DB Mirroring (Async) Recovery Time (RTO) Log Shipping VDI/VSS Backup/Restore SAN Replication (Sync) SAN Replication (Async) Native Backup/Restore Recovery Point (RPO)

SQL Server Replication
Title Month Year SQL Server Replication Stretched Failover Clustering Automated restart solution, based on Windows server Failover Clustering Provides high-availability on the instance level Active/Passive or multiple active instances/nodes Modules available for SRDF, MirrorView and RecoverPoint (Sync and Async) Can be fully automated Supports all cluster modes (MNS, FSW etc) Multiple subnets support coming in “Denali” Windows Failover Cluster Site A Site B SRDF MirrorView RecoverPoint

VMotion over Distance Microsoft-Oracle-SAP Enabled By VPLEX Metro
EMC SRDF Three Data Center Solutions on Symmetrix with Open Systems December 2009 Site A VPLEX Metro Symmetrix VMAX CLARiiON CX4-480 Site B Vblock 1 (CX4) 100Km Distance Application / RDBMS # VMs VMotion (min) SQL Server 2008 2 5:17 SharePoint Server 2007 7 3:37 SAP ERP 6.0 / BW 7.0 8 1:53 Oracle E-Business 12.1 3:52 Total 19

Title Month Year Automated SQL Consistent Replicas at Both Sites With Physical or Virtual Hosts ESX1 Virtual Machine RDM D: E: VMFS F: G: BOOKMARK Replication Manager Server Here is an animation showing how RM interacts with the application and the storage technology, and the resulting replicas. VMware ESX Cluster VMware ESX Server Farm SAN WAN SAN BOOKMARK SAN RecoverPoint RecoverPoint LUN LUN Production LUN Local CDP Journal Remote CRR Journal Remote CRR Copy Local CDP Copy 4. Images are now mountable/recoverable 1. Replication Manager freezes SQL databases (VDI) 2. Replication Manager server requests bookmark to be created 3. Replication Manager thaws SQL databases

Solution Architecture
4* SQL Server Virtual Machines 2* Online Transaction Processing Databases (75,000/25,000 users) 2* Data Warehouse / Analytics Databases (2TB/1TB) Storage Configuration OS: RAID5 FC Pool OLTP DB: RAID 1/0 FC Pool DW DB: RAID 6 SATA Pool DB Logs: RAID 1/0 FC RG RP Journals: RAID 1/0 FC RG James J

Optimizing WAN with RecoverPoint
Operating System + PageFile 3.6mbits WAN traffic 43mbits site write rate James SQL System DBs + SQL TempDB 151mbits 177.9mbits User Databases 23.3mbits Average compression ratio achieved 4:1 J

Solutions Overview for Microsoft Applications Tiered/ Unified Storage Replication, Backup and Recovery Business Continuity Security Virtualization and Private Cloud EMC for Microsoft SharePoint Infrastructure allows you to address your complete information infrastructure requirements for SharePoint. EMC provides: Tiered Storage and Unified Storage as a solid foundation to deploy SharePoint: Cost effective, scalability, performance for any size SharePoint environment Flexibility to grow as requirements change Proven and documented best practices for optimal layout and design to ensure scalability Easily manage tiered storage with non-disruptive migration of data with Virtual LUN technology Virtual Infrastructure: Lower TCO by maximizing server and storage utilization Lower energy costs Maximizes service levels by enabling flexibility and ensuring quality of service Support Microsoft HyperV and VMware Infrastructure Backup, Recovery, Archive Unified protection for all Microsoft Applications Schedule, create, and manage VSS snapshots – VSS consistent point in time copies With deduplication, enable fast full backups at the source Simple, affordable, and secure platform for SharePoint data archiving Business Continuity Unified protection for all Microsoft Applications: recovery for local or remote site to any point in time Replicate to a transaction consistent state and enable any-point-in-time recovery Roll back and recovery to specific point in time Granularity and consistency of recovery across federated environment to meet SharePoint requirements Enterprise Content Management SharePoint Integration for content services and archive services Common enterprise wide content management platform: complete archival , capture and records management Flexible policy based archiving to centralized enterprise infrastructure based on Documentum Security Discovery of sensitive information on SharePoint sites Information rights management through integration of DLP and MS RMS Central entitlements management – protect data based on content, context and identify Monitoring and reporting of user access and activities Let’s discuss each of these solution areas in more detail. Note to Presenter: At this point you may which to select from the following slides based on your account interests. Symmetrix VMAX VNX VNXe IOmega VMware vSphere Microsoft Hyper-V VBlock VPLEX Replication Manager NetWorker Avamar Data Domain EMC Disk Library (EDL) Cluster Enabler RecoverPoint vCenter SRM SRDF MirrorView Celerra Replicator RSA Data Loss Prevention Suite RSA SecureView RSA enVision RSA SecurID RSA Adaptive Authentication Proven Solutions, White Papers and Best Practices

Applause

SQL Server Best Practices I/O Patterns
Title Month Year Generalizing SQL Server I/O patterns is difficult - sizing storage for unknown workload is not trivial OLTP (Online Transaction Processing) Typical heavy on random read / writes (8K most common) RDW (Relational Data Warehousing) Typical 64KB+ sequential reads (table and range scan) KB sequential writes (bulk load) Operational Activities Backup/Restore , Index rebuild etc. In reality, “mixed” workloads are more common

SQL Server Best Practices Planning
Title Month Year SQLIO, SQLIOSIM, IOMETER etc. are all synthetic, yet customizable, load tools. Ideally, resource planning should be based on an observed workload if possible Consider splitting workloads with very different I/O characteristics at the physical level Isolation at physical level can provide predictable performance Traditional storage best practices are challenged these days with the introduction of VP, FAST and FAST Cache

VNX FAST/FAST Cache Some workloads are too dynamic for FAST
Data access patterns can change between scheduled tiering One-time operations can skew the real patterns FAST Cache may be a better choice in those circumstances FAST Cache isn’t needed everywhere Ex: Transaction Logs, Reserve LUNs, Write Intent Log Enabling FAST Cache on these items takes resources away from other things and hurts performance potential

SQL Server Best Practices Allocating Storage
Title Month Year Plan for performance not for capacity Disk Response time IOPS (Random I/O) Throughput in MB/s (Sequential I/O) Place SQL transaction log and database files on physically separate Disk groups/Pool Avoid disk contention (random and sequential I/O) Ensure disk or volume failures do not impact both Log and Data Place database files on RAID1/0 or RAID5 volumes/pools RAID5 for more read intensive workloads (DW or when writes are less than 30% of the workload) RAID1/0 for higher random write workloads (OLTP) RAID 6 usually for higher availability with large pools

SQL Server Best Practices Allocating Storage - Log files
Title Month Year Log manager activity is sequential in nature Checkpoints are more random in nature Disk response time is key Logical Disk Counters: Avg. Disk/sec Write SQL Server Databases: (Log Flush Wait Time)/(Log Flushes/sec) Place transaction log files on a RAID1/0 volume/pool for lower write latency and faster rebuilds

SQL Server Best Practices Allocating Storage – Data Files
Title Month Year To utilize more spindles, consider FILEGROUPs for database files Balance the load across multiple LUNs/RAID Groups/Pools As a general rule of thumb use .25 to 1 file per core within a FILEGROUP Use equal size for files within a single FILEGROUP For performance benefit only, might be easier to configure and maintain using storage virtualization By default the tempdb database is rather small and gets its characteristics from the model database. Each time the Microsoft SQL Server service is started; tempdb is dropped and re-created with its initial parameters. Thus, if tempdb is initially 128 MB and during operations it autogrows to 4 GB, on restart it will be 128 MB again. Then it will have to go through the autogrow again, which will impact the performance of your database. To minimize this impact it is recommended that tempdb be sized appropriately for the environment. The easiest way to size the tempdb database is the following: Start with a reasonable size tempdb for the size of databases that are in the same SQL Server instance. For example, a 1 GB tempdb database is a reasonable starting place for a sum total of instance databases between 10 GB and 100 GB, but not for 1 TB. A good starting place is to sum the total size of the databases in the instance and size tempdb between 1 percent and 10 percent of that size. Set a valid autogrow increment that will allow tempdb to grow without heavy fragmentation. The best way to do this is to set autogrow to 10 percent to 20 percent of the tempdb initial size. Do not use a percentage for the growth parameter; calculate the MB growth that corresponds to the percentage and set that as the autogrowth size. You should also make sure that fast file initialization is enabled. Periodically verify the size and utilization of the tempdb database to see if it has grown significantly. Reset the size of the tempdb database to something close to its size, before a shutdown. If our tempdb database from the previous example had grown from 1 GB to 5 GB, then resetting it to start at 5 GB would be advantageous, unless the new size is obviously excessive. For example, if the sum total of user databases was 10 GB and tempdb was 15 GB, this would seem excessive. It is possible that an odd set of scenarios came together to cause uncharacteristic tempdb growth. If you suspect that this may be the case, then the starting size should be set to something smaller than the current size. If the tempdb repeatedly grows to larger than is initially considered reasonable, then it is possible that this is simply the size of tempdb that is needed for your workload. From here, a DBA could diagnose what is causing the excessive growth and then determine if it is valid, or if anything needs tuning. It is recommended that tempdb be placed on its own spindles, where tempdb and user database activity cannot cause physical disk contention with each other. The number of spindles will be determined on a case-by-case basis using the same principles that are applied to designing storage for user databases. Consider placing Tempdb database on separate spindles depending on how well you know your workload use of it Same practices as data files with respect to sizing and growth Pre-allocate the Tempdb space with a size large enough to accommodate the expected workload (1-10% of instance size) Set the file growth increment large enough to minimize Tempdb expansions Microsoft recommends setting the Tempdb files FILEGROWTH increment to 10%

SQL Server Best Practices
Settings Title Month Year Plan Data files size accordingly (Virtual Provisioning!) Don’t rely on AutoGrowth File growth can cause locking, set files size and autogrow increments appropriately Disable Auto Shrink Allocation unit size is the smallest unit of allocation for NTFS SQL 2005 supports “instant file initialization” it is enabled on the OS level for NTFS volumes by granting SQL service account “Perform Volume Maintenance Tasks” permission Data and log files are initialized to overwrite any existing data left on the disk from previously deleted files. Data and log files are first initialized by filling the files with zeros when you perform one of the following operations: Create a database. Add files, log or data, to an existing database. Increase the size of an existing file (including autogrow operations). Restore a database or filegroup. File initialization causes these operations to take longer. However, when data is written to the files for the first time, the operating system does not have to fill the files with zeros. Instant File Initialization In SQL Server, data files can be initialized instantaneously. This allows for fast execution of the previously mentioned file operations. Instant file initialization reclaims used disk space without filling that space with zeros. Instead, disk content is overwritten as new data is written to the files. Log files cannot be initialized instantaneously. “Lock pages in memory” permission should be granted to SQL service user Autogrowth/shrink - Plan for the following Disk Response Times Data files R/W Operations (Response Time) Recommendation < 10 ms Very Good < 20 ms Acceptable > 20 ms Need for investigation and improvement Log file Write Operations (Response Time) < 5 ms 5 – 10 ms ms Investigate and Improve

Host Title Month Year Observe and adjust Queue Depth settings on the HBA if I/O accumulation on the host level is noticed Proper Multipathing (Zoning/Mapping/Masking) is important for both performance and availability Thin Provisioned LUNs Use the “Quick Format” option !!! Enable Instant file initialization !!! Enhances the speed for database creates, restores, data file growth Log files would be fully allocated and zeroed Allocation unit size is the smallest unit of allocation for NTFS SQL 2005 supports “fast file initialization” it is enabled on the OS level for NTFS volumes by granting SQL service account “Perform Volume Maintenance Tasks” permission Data and log files are initialized to overwrite any existing data left on the disk from previously deleted files. Data and log files are first initialized by filling the files with zeros when you perform one of the following operations: Create a database. Add files, log or data, to an existing database. Increase the size of an existing file (including autogrow operations). Restore a database or filegroup. File initialization causes these operations to take longer. However, when data is written to the files for the first time, the operating system does not have to fill the files with zeros. Instant File Initialization In SQL Server, data files can be initialized instantaneously. This allows for fast execution of the previously mentioned file operations. Instant file initialization reclaims used disk space without filling that space with zeros. Instead, disk content is overwritten as new data is written to the files. Log files cannot be initialized instantaneously. “Lock pages in memory” permission should be granted to SQL service user Autogrowth/shrink - Important I/O counters Average Disk/sec Read & Write Current Disk Queue Length* Disk Reads/Writes per Second Disk Read & Write Bytes/sec Average Disk Bytes/Read & Write * Hard to interpret due to virtualization of storage. Consider in combination with response times.

Summary Title Month Year Understanding the actual SQL server workload is CRUCIAL for Server hardware, Storage and Database optimization Storage Understand the workload type (random, sequential or mixed) Monitor the average I/O size and it’s effect on the overall IOPS Always plan for peak loads Provide sufficient storage bandwidth to handle consolidated workloads Virtualization Start with smaller Tier 2 databases and gradually move to larger databases Some SQL instances might not be best candidates for virtualization When more than 8 vCPUs required (4 with Hyper-V) Scale out is not an option Tuning Advisor is a tool in Microsoft SQL Server 2005 that enables you to tune databases for improved query processing. Database Engine Tuning Advisor examines how queries are processed in the databases you specify and then it recommends how you can improve query processing performance by modifying physical design structures such as indexes, indexed views, and partitioning Query Editor (replaces Query Analyzer), a component of SQL Server Management Studio and the primary tool for designing and testing Transact-SQL statements, queries, batches, and scripts interactively. With the Query Editor, you can write new scripts in Transact-SQL and Multidimensional Expressions (MDX). You can also edit scripts that are created from files or that are automatically generated from SQL Server Management Studio dialog boxes or from SQL Object Explorer. SQL Server Profiler is a tool that captures SQL Server 2005 events from a server. The events are saved in a trace file that can later be analyzed or used to replay a specific series of steps when trying to diagnose a problem. Monitoring/Controlling SQL Profiler in correlation with Perfmon and STP, SQL Database Engine Tuning Advisor (Index/Partitions) SQL 2008 Resource Governor (cpu+memory control) SQL 2008 Performance Warehouse EMC Select partners – ZettaPoint (DBClassify), Precise (TPM)

Infrastructure Solutions for Microsoft SQL Server

Similar presentations

Presentation on theme: "Infrastructure Solutions for Microsoft SQL Server"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Infrastructure Solutions for Microsoft SQL Server

Similar presentations

Presentation on theme: "Infrastructure Solutions for Microsoft SQL Server"— Presentation transcript:

Similar presentations

About project

Feedback