service provider reference architecture - database web view service provider reference architecture
Post on 30-Jun-2020
Embed Size (px)
Service Provider Reference Architecture - Database Hosting using SQL Server 2014
Service Provider Reference Architecture (SPRA)
Multi-Tenant SQL Server 2014
Version 2.0 29-Jun-15
Prepared by Services
Table of Contents Executive Summary 5 1 Solution Overview 5 1.1 Multi-Tenancy Models 6 1.2 Architecture Design Strategy 8 2 Multi-Tenant SQL Server Infrastructure Design 10 2.1 SQL Server Infrastructure 10 2.1.1 Additional Hardware Considerations 11 2.1.2 Hyper-V Replica Considerations 11 2.2 SQL Server Virtual Machine Design 11 2.2.1 SQL Virtual Machine CPU Considerations 12 2.2.2 SQL Virtual Machine Memory Considerations 12 2.2.3 SQL Virtual Machine Storage Considerations 14 2.2.4 SQL Virtual Machine Networking Considerations 16 2.2.5 SQL Virtual Machine Affinity Considerations 17 2.2.6 Additional SQL Virtual Machine Considerations 17 3 Multi-Tenant SQL Server Security Design 17 3.1.1 Surface Area Reduction 18 3.1.2 Policy-Based Management 20 3.1.3 Service Account Selection and Management 21 3.1.4 Patching and Automatic Windows Update 24 3.2 Encryption 24 3.2.1 Data and Database Encryption 24 3.2.2 SSL Encryption 28 3.3 Access Control 29 3.3.1 Administrator Privileges 29 3.3.2 User-Defined Server Roles 30 3.3.3 Database Ownership and Trust 30 3.3.4 Lockdown of System Stored Procedures 31 3.4 Authentication 32 3.4.1 Authentication Modes and Logins 32 3.4.2 Contained Databases and Authentication 34 3.5 Network Security 35 3.6 Auditing 38 4 Multi-Tenant SQL Server High Availability and Disaster Recovery Design 41 4.1 Network Configuration 44 4.2 Quorum Configuration 45 4.3 SQL Server System Data and Availability Groups 46 4.3.1 Jobs, Alerts, Email Operators 46 4.3.2 Backups 46 5 Shared Database Multi-Tenancy Model Design Considerations 47 5.1 Resource Governor 47 5.1.1 Resource Pools, Workload Groups, and Classification 47 5.2 Database Storage 48 6 Multi-Tenant SQL Server Service Management and Automation 49 6.1 Operations Manager 50 6.1.1 SQL Server 2014 Management Pack 50 6.2 Orchestrator 52 6.3 Windows Azure Pack 54 6.3.1 Service Management Automation 55
Microsoft SQL Server is an enterprise class relational database management platform and is an integral and indispensable component in most computing environment today with a significant application ecosystem. With the advent of hosted cloud computing and storage, the opportunity to offer a Microsoft SQL Server as an outsourced service is gaining momentum. This reference architecture is focused on providing sample design guidance and configuration considerations for helping service providers to build a multi-tenant Microsoft SQL Server 2014 platform using Microsoft’s virtualization and management platform.
This pattern and practice provides a consistent architecture for Microsoft SQL Server 2014. This document was written to make the result a collection of both solution and product level best practices. Furthermore, this provides guidance for deploying Microsoft SQL Server 2014 using Microsoft’s software defined datacenter patterns and practices built on the Windows Server Hyper-V and System Center platform.
The primary goal is to familiarize decision-makers and IT professionals of service providers with an example of how to build a multi-tenant Microsoft SQL Server 2014 platform for their organization. The design presented here could be used as is, or could serve as a starting point from which to drive deeper discussions about the business models, service descriptions, technology, and design decisions. This architecture builds on the guidance and configuration considerations of the Service Provider Reference Architecture Multi-Tenant – Foundation which provides the design of a Multi-Tenant infrastructure that includes Microsoft identity solutions as well as Microsoft’s virtualization and management platform.
This solution takes advantage of the full range of in-product features for Microsoft SQL Server 2014. This example design is hosted on a Windows Server software-defined infrastructure, which aims to significantly reduce costs through the use of commodity storage and high-speed, low latency network connectivity.
Multi-Tenant SQL for Service Providers has been specifically designed with service providers in mind to help service providers to deliver database functionality as a service to their customers. Multi-Tenant SQL service support the following necessary capabilities:
· Consumer-based provisioning and management of database instances using on-demand, self-service mechanisms;
· Automated monitoring of and compliance with provider-defined service definitions, attributes and quality of service levels;
· Fine-grained metering of database usage
In addition to these required characteristics, Multi-Tenant SQL also supports granular service elasticity, secure multi-tenancy, automated resource management, and integrated capacity planning.
Microsoft SQL Server supports several isolation models, such as dedicated SQL Server running on dedicated machines (physical or virtual), dedicated SQL Server instance, or dedicated SQL Server database depends on what features and level of flexibility service providers like to offer. Multi-Tenant SQL service will focus on virtualized scenarios to leverage the benefits of infrastructure as a service. The following three multi-tenancy models will be covered:
Virtual Machine Level Isolation: Each tenant database instance will be isolated with Virtual Machine for better feature flexibility and scalability. Virtual machine will be the container for controlling the resources allocation and scalability. Microsoft Hyper-V provides quality of service for various resources, such as CPU, Memory, Network and Storage IOPS.
SQL Server Instance Level Isolation: Each tenant database instance will be isolated with a dedicated SQL Server instance. Multiple SQL Server instances will be hosted on a given virtual machine. SQL Server instance will be the container for controlling the resources allocation, and SQL Server feature related configurations, such as SQL Collation, and patch level, etc. Even instance level isolation provides good security level isolation and feature level isolation, but it has limited options to isolate resources allocation, such as CPU allocation at instance level, and it is also limited to scale, running multiple SQL instances per virtual machine. Therefore, this multi-tenant model is not recommended and will not be focused.
Database Level Isolation: Each tenant database instance will be isolated as contained database running on a shared SQL instance. Resource governor will be leveraged for better resource guarantee and containment for workloads at resource pool level. It is possible to assign tenant database to its own resource pool to achieve database level resource containment. Microsoft SQL 2014 resource governor allows limiting CPU, Memory and IOPS at resource pool level.
The following table illustrates benefits and constraints of each model:
· Optimizes the overhead of resources (memory, CPU, disk space, connections, and more) that are required for each individual instance
· Maximizes value of licenses, since no additional license is required for multiple database instances
· Minimizes the labor and cost of database administration—the fewer individual instances, the easier the system is to monitor and manage
· A common security model (although distinct database and database objects within the model can be secured individually)
· A common service patch level
· The maintenance cycle and downtime
· Platform resources (CPU, Memory, Disk I/O, and more). Resource Governor could help to constraint the resources consumption.
· The data must be very carefully secured.
· The database needs to run at a different service patch level than the other databases.
· The application that depends on the database cannot share a maintenance schedule with other databases, either because the database will require the instance to be started and stopped repeatedly or because the application is too critical to be stopped by the requirements of another application.
· Each instance requires additional resources from the server, including CPU, memory, and disk I/O.
· Memory pools and connections cannot be shared between instances. More resources will be required on the server
· Separate instances require their own logins so additional management efforts will be required.
· Distinct instances require distinct monitoring and administration, which increase cost.
· Server maintenance affects only a single database application.
· The application may require direct access to the server through external stored procedures. This can open the door to certain security risks. By placing the server on its own server, the risk can be mitigated.
· The database can have a unique, isolated security model.
· The database can exercise full control of the resources available on the server.
· Each machine will require a Windows Server license, SQL Server license, and other licenses for antivirus software, backup, monitoring, and more.
· Each additional server requires more resources. If it is a physical machine, the hardware must be purchased, space must be allocated in the data center, and power consumption must be considered. In the case of virtual machines, there is additional load on the host hardware which eventually leads to the need of additional virtual machine host serve