PRÁTICAS RECOMENDADAS E DIRETRIZES DE PROJETO PARA ARMAZENAMENTO EMC PARA O MICROSOFT SQL SERVER

Transcrição

1 White paper PRÁTICAS RECOMENDADAS E DIRETRIZES DE PROJETO PARA ARMAZENAMENTO PARA O MICROSOFT SQL SERVER Família VNX da, Sistemas Symmetrix VMAX e Produtos Xtrem Server Práticas recomendadas de projeto e dimensionamento Aceleração do desempenho do Exchange Server com tecnologias flash Práticas recomendadas de recuperação de desastres e alta disponibilidade Soluções Resumo Este white paper identifica as práticas recomendadas e os principais pontos de decisão para o planejamento e a implementação do Microsoft SQL Server com a família VNX da VNX de armazenamento unificado, o armazenamento da série Symmetrix VMAX e os produtos XtremSF e XtremSW Cache. Outubro de 2013

2 Copyright 2013 Corporation. Todos os direitos reservados. A assegura que as informações apresentadas neste documento estão corretas na data da publicação. As informações estão sujeitas a alterações sem prévio aviso. As informações nesta publicação são fornecidas "no estado em que se encontram". A Corporation não garante nenhum tipo de informação contida nesta publicação, assim como se isenta de garantias de comercialização ou adequação de um produto a um propósito específico. O uso, a cópia e a distribuição de qualquer software da descrito nesta publicação exigem uma licença de software. Para obter uma lista mais atualizada de produtos da, consulte Corporation Trademarks no site brazil.emc.com. Todas as marcas comerciais aqui mencionadas pertencem a seus respectivos proprietários. Número da peça H12341 para o Microsoft Exchange Server 2 2

3 Índice Resumo executivo... 7 Objetivo deste white paper... 7 Público-alvo... 7 Escopo... 7 Terminologia... 8 Componentes e arquitetura do Microsoft SQL Server Visão geral do SQL Server Versões do SQL Server SQL Server Edições do SQL Server Componentes do SQL Server Windows Server Tipos de volume do Windows SMB Arquitetura do SQL Server Componentes lógicos do SQL Server Componentes físicos do SQL Server Tipos de arquivo Páginas e extensões Registro de transações Grupo de arquivos Características de I/O e largura de banda do SQL Server Visão geral OLTP Data warehouse/banco de dados OLAP Lendo páginas Gravando páginas Log Manager Uso do banco de dados temporário Padrões de I/O Práticas Recomendadas para Dimensionamento e Provisionamento de Armazenamento do SQL Server Visão geral Práticas recomendadas gerais para o armazenamento do SQL Server Práticas recomendadas básicas para o SQL Server Práticas recomendadas básicas de armazenamento Considerações sobre clustering Considerações sobre versões anteriores Considerações gerais sobre armazenamento Considerações sobre desempenho versus capacidade Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 3 3

4 Seleção de tipo de disco Pools e tipos de RAID Considerações sobre armazenamento de provisionamento virtual Thin-LUN versus thick-lun Práticas recomendadas para dimensionamento de armazenamento Consideração sobre dimensionamento de banco de dados OLTP Práticas recomendadas para o dimensionamento do FAST VP Consideração sobre dimensionamento de banco de dados OLAP Considerações sobre armazenamento de hipervisor Diretrizes gerais de virtualização Práticas recomendadas para o ambiente VMware vsphere Microsoft Hyper-V Considerações sobre armazenamento de clustering do SQL Server Diretrizes sobre projeto de armazenamento Symmetrix VMAX Considerações sobre projeto de hardware da série VMAX Considerações e práticas recomendadas sobre provisionamento virtual Considerações e melhores práticas do FAST VP para um sistema de armazenamento VMAX Diretrizes sobre projeto de armazenamento VNX Considerações e práticas recomendadas para FAST Cache Considerações e práticas recomendadas para FAST VP FAST Cache versus FAST VP Considerações sobre server flash Visão geral do XtremSF Práticas recomendadas de projeto do XtremSF Visão geral do XtremSW Cache Práticas recomendadas de projeto do XtremSW Cache Práticas recomendadas de projeto do XtremSW Cache em um ambiente virtualizado Considerações sobre dimensionamento do XtremSF e do XtremSW Cache Automação com ESI Proteção do SQL Server Visão geral AlwaysOn Availability Groups Proteção de dados nativa do SQL Server Cópias recuperáveis versus reinicializáveis Estruturas VDI e VSS para replicação do backup Produtos de alta disponibilidade e proteção de dados da para o SQL Server Tecnologias de replicação Ferramentas de gerenciamento de replicação Recuperação de desastres em vários locais Considerações Tecnologias de replicação de vários locais Ferramentas para automação de reinício Ferramentas de automação de instâncias virtualizadas Opções de recuperação de desastres para o SQL Server para o Microsoft Exchange Server 4 4

5 Recomendações adicionais de backup AlwaysOn para HA/DR AlwaysOn com FAST Suite AlwaysOn com flash XtremSW Cache/XtremSF Conclusão Resumo Informações adicionais Apêndice A: Data Protection Advisor for Replication Analysis Visão geral Assistentes Data Collection and Discovery Detecção e coleta de dados Detectando storage arrays Configurando o Data Protection Advisor para monitoramento do Microsoft SQL Server Exibindo e relatando lacunas e exposições Apêndice B: Ferramentas para monitoramento do desempenho, ajuste e dimensionamento do SQL Server Visão geral Ferramentas no nível do aplicativo DBclassify Perfcollect Workload Performance Assessment Tool PAL Ferramentas no nível do banco de dados SQL Server Ferramenta de dimensionamento VSPEX SQL Server Transact-SQL SQL Server Profiler SQL Server Database Engine Tuning Advisor SQL Server Dynamic Management Views Ferramenta no nível do host Windows Monitor de desempenho do Windows (Perfmon) Ferramentas no nível do hipervisor Principais métricas para monitorar ESX Principais métricas para monitorar Hyper-V Ferramentas no nível do cache de armazenamento/servidor Unisphere Analyzer XtremSW Cache Performance Predictor Storage Configuration Advisor Apêndice C: Ferramentas de geração de carga de trabalho do SQL Server Visão geral Introdução às ferramentas SQL Server Profiler IOMeter Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 5 5

6 SQLIO SQLIOSim Quest Benchmark Factory Apêndice D: Projetos de armazenamento de exemplo e arquiteturas de referência Visão geral Projeto de armazenamento do Microsoft SQL Server no VMAX com FAST VP Fase 1 Coletar os requisitos do usuário Fase 2 Projetar a arquitetura de armazenamento com base nos requisitos do usuário Cálculo de IOPS Cálculo de capacidade Abordagem de projeto de componente básico para o data warehouse Considerações sobre os componentes básicos Detalhes sobre os componentes básicos Implementando componentes básicos Projeto de alocação de LUNs e máquinas virtuais SQL Server Solução de proteção do SQL Server RecoverPoint Replication Manager SRM do VMware vcenter para o Microsoft Exchange Server 6 6

7 Resumo executivo Nas fases de planejamento e projeto de uma implementação ou um upgrade do Microsoft SQL Server, é importante compreender como o aplicativo interage com a plataforma de armazenamento e as tecnologias de virtualização. Também é essencial saber quais práticas recomendadas de armazenamento e projeto devem ser seguidas para evitar problemas e obter alto desempenho. De uma perspectiva de projeto de armazenamento, considere a arquitetura dos aplicativos e as características do perfil do usuário do Microsoft SQL Server para questões de desempenho, proteção e crescimento do banco de dados SQL Server. Este white paper pode ajudar os profissionais da solução a avaliar e atender aos requisitos de armazenamento do SQL Server em termos de desempenho, capacidade de expansão, e disponibilidade: A preferência é sempre coletar dados reais do local. Na ausência dos dados de desempenho reais, faça uma série de suposições razoáveis ao projetar um ambiente típico. Ao projetar um sistema de armazenamento, sempre considere os requisitos de proteção. Objetivo deste white paper Público-alvo Escopo Este white paper apresenta o conjunto de práticas atualmente recomendadas pela para o projeto de armazenamento como suporte ao Microsoft SQL Server. São apresentadas diretrizes no contexto da implementação do SQL Server na família VNX da, da série Symmetrix VMAX e da família Xtrem. O white paper contém diretrizes de implementação do SQL Server em ambientes físicos e virtuais. Este white paper se destina a clientes, parceiros da e equipes de serviço que estejam considerando uma implementação de um ambiente de banco de dados com o Microsoft SQL Server ou considerando um upgrade de uma versão anterior do SQL Server. Presumimos que o público-alvo conheça o Microsoft SQL Server, os produtos de armazenamento da como VNX, Symmetrix VMAX, XtremSF e XtremSW Cache, além dos ambientes virtuais VMware ou Microsoft Hyper-V. Este documento apresenta práticas de projeto de armazenamento recomendadas pela para hospedagem do Microsoft SQL Server em armazenamento VNX da, armazenamento Symmetrix VMAX e XtremSF ou XtremSW Cache em ambientes físicos e virtuais. O paper contém exemplos de dimensionamento e projeto baseados nas abordagens comprovadas da. Instruções detalhadas da implementação completa estão além do escopo deste documento. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 7 7

8 Terminologia Este white paper inclui a terminologia a seguir. Tabela 1. Terminologia Termo AG (Availability Groups, grupos de disponibilidade) Réplica de disponibilidade Sincronização de dados XtremSF emlc FAST Cache FAST VP (Fully Automated Storage Tiering for Virtual Pools) Flash MLC (Multi-Level Cell) NAND Definição Recurso de HA (High Availability, alta disponibilidade) e recuperação de desastres do SQL Server Ao maximizar a disponibilidade de um conjunto de bancos de dados do usuário, ele fornece uma alternativa de nível corporativo ao espelhamento do banco de dados. Instância de um grupo de disponibilidade que é hospedada por uma instância específica do SQL Server e mantém uma cópia local de cada banco de dados de disponibilidade pertencente ao grupo de disponibilidade. Existem dois tipos de réplica de disponibilidade uma réplica primária única (consulte Réplica primária nesta tabela) e até quatro réplicas secundárias (consulte Réplica secundária legível). O processo pelo qual as alterações feitas em um banco de dados primário são reproduzidas em um banco de dados secundário. Uma únicaplaca de hardware de server flash discreta que se encaixa em qualquer servidor montado em rackdentro do envelope de alimentação de um só slot PCIe, disponível com um amplo conjunto de recursos emlc (Enterprise Multi-Level Cells, células multinível corporativas) e SLC (Single-Level Cell). Célula multinível corporativa. Célula multinível é uma tecnologia de memória Flash projetada para baixas taxas de erro usando vários níveis por célula a fim de permitir que mais bits sejam armazenados pelo mesmo número de transistores. O FAST (Fully Automated Storage Tiering) Cache é um software da que possibilita que os clientes acrescentem várias capacidades de flash drives para ampliar a atual capacidade de cache, a fim de melhorar o desempenho em todo o sistema. O FAST Cache agora está disponível com configurações de maior capacidade, usando o flash drive de 100 GB ou de 200 GB. Essas configurações adicionais só estão disponíveis no storage array VNX. Recurso dos storage arrays VNX que automatiza a identificação de volumes de dados com o objetivo de alocar ou realocar dados de aplicativos de negócios em níveis diferentes de desempenho e capacidade no storage array. Uma tecnologia de memória flash que utiliza vários níveis por células para permitir que mais bits sejam armazenados com o uso do mesmo número de transistores. Memória flash NAND é um tipo de tecnologia de armazenamento não volátil que não requer energia para reter dados. para o Microsoft Exchange Server 8 8

9 Termo OLTP Réplica primária RAID Réplica secundária legível Repropagação Flash SLC (Single-Level Cell) SP AlwaysOn do SQL Server 2012 Pool de armazenamento Thin-LUN Thick-LUN VMDK Definição Online Transaction Processing (processamento de transações on-line). Os aplicativos típicos de OLTP incluem processamento de transações de recuperação e entrada de dados. A réplica de disponibilidade que torna os bancos de dados primários disponíveis para conexões de leitura/gravação de clients e envia apontamentos de registro de transações de cada banco de dados primário a cada réplica secundária. RAID (Redundant Array of Independent Disks, array redundante de discos independentes) é um método para armazenar dados em vários drives de disco, a fim de aumentar o desempenho e a capacidade de armazenamento e oferecer redundância e tolerância a falhas. Bancos de dados de réplica secundária configurados para permitir conexões de client somente leitura. Processo de copiar um banco de dados de uma réplica primária em réplicas secundárias correspondentes. Um tipo de SSD (Solid State Drive, unidade de estado sólido) que armazena um bit de informação por célula de mídia flash. Controladora de armazenamento. Solução completa de alta disponibilidade e recuperação de desastres para o SQL Server O AlwaysOn apresenta recursos novos e aprimorados para bancos de dados específicos e instâncias inteiras, fornecendo flexibilidade para dar suporte a várias configurações de alta disponibilidade. Estruturas virtuais que permitem que os dados sejam movidos dinamicamente entre diferentes níveis de acordo com a atividade de negócio dos dados. Com os sistemas VNX e VMAX, os pools de armazenamento são totalmente automatizados para fins de autogerenciamento. Tipo de LUN criada em um pool de armazenamento no qual o espaço físico alocado pode ser inferior à capacidade dos usuários experimentada pelo servidor host. Tipo de LUN criada em um pool de armazenamento no qual o espaço físico alocado é igual à capacidade dos usuários experimentada pelo servidor host Formato de arquivo de disco de máquina virtual em um ESXi Server. VHDX Formato de disco rígido virtual no Windows Server 2012 Hyper-V. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 9 9

10 Componentes e arquitetura do Microsoft SQL Server Visão geral do SQL Server O Microsoft SQL Server é um sistema de análise e gerenciamento de bancos de dados relacionados da Microsoft para soluções de data warehousing e operações diárias A versão atual é o Microsoft SQL Server 2012, e as versões anteriores incluem o Microsoft SQL Server 2008 R2, o SQL Server 2008, o SQL Server 2005 e o SQL Server Versões do SQL Server Na versão do SQL Server 2000, a Microsoft concentrou-se no desenvolvimento de recursos de Business Intelligence, entre eles, a ferramenta ETL (Extract, Transform, and Load), o Reporting Server e serviços de análise OLAP (Online Analytical Processing). O SQL Server 2005 introduziu o tipo de dados XML, DMVS (Dynamic Management Views) para monitoramento e diagnóstico do estado e do desempenho do servidor, bem como CLR (Common Language Runtime) para integração com o.net Framework. O SQL Server 2005 SP1 (Service Pack 1) adicionou o Database Mirroring para recursos de redundância e failover no nível do banco de dados. O SQL Server 2008 introduziu tecnologias AlwaysOn para reduzir o tempo de inatividade, com o objetivo de conferir ao gerenciamento de dados capacidades de autoajuste, auto-organização e automanutenção. O SQL Server 2008 R2 adicionou Master Data Services para gerenciar, de maneira central, hierarquias e entidades de dados master, e o gerenciamento de vários servidores para centralizar várias instâncias e serviços do SQL Server. O SQL Server 2012 introduziu instâncias do AlwaysOn SQL Server Failover Cluster e grupos de disponibilidade para aumentar a disponibilidade dos bancos de dados, índices da Columnstore para melhorar o desempenho das consultas e Contained Databases para simplificar o movimento entre as instâncias do banco de dados e melhor gerenciamento de memória. Cada versão do SQL Server é fornecida em várias edições, o que pode ser considerado um subconjunto dos recursos do produto. Os usuários podem verificar qual edição eles estão executando com a seguinte consulta: select serverproperty( edition ). As principais edições são Datacenter, Enterprise, Standard, Web, Business Intelligence, Workgroup e Express. SQL Server 2012 O SQL Server 2012 é a versão mais recente do Microsoft SQL Server. Ele dá suporte a alta disponibilidade e recuperação de desastres por meio de clusters AlwaysOn e grupos de disponibilidade, armazenamento em memória xvelocity para desempenho de consultas mais rápido, exploração de dados rápida por meio do PowerView e da modelagem tabular em serviços de análise e o novo recurso de gerenciamento de dados com Data Quality Services. Edições do SQL Server 2012 O Microsoft SQL Server 2012 inclui estas edições principais: SQL Server Standard Edition: esta edição fornece recursos básicos de gerenciamento de dados e de lógica analítica e geração de relatórios de Business Intelligence. Ela fornece gerenciamento de bancos de dados eficaz com o mínimo de recursos de TI. para o Microsoft Exchange Server 10 10

11 Business Intelligence Edition: além de todos os recursos da edição Standard do SQL Server, esta edição também dá suporte a soluções de BI dimensionáveis e de autoatendimento. Ela apresenta: PowerView: recurso suplementar dos serviços do SQL Reporting para recuperação de dados rápida PowerPivot: recurso que proporciona, com facilidade, colaboração e compartilhamento de percepções com acesso e dados de mashup Master Data Services: empregado para manter dados master usados para mapeamento de objetos, dados de referência e gerenciamento de metadados por toda a estrutura da organização Modelo semântico de BI: fornece uma exibição consistente de todas as fontes de dados heterogêneas e transforma aplicativos criados pelo usuário em soluções de BI corporativas Enterprise Edition: esta edição fornece recursos completos de datacenter high-end. Ela consegue processar cargas de trabalho exigentes com desempenho rápido, enquanto mantém a proteção de dados e o tempo de funcionamento necessários. Ela apresenta: SQL Server AlwaysOn: fornece maior tempo de funcionamento, failover mais rápido e melhor uso dos recursos de hardware com solução de alta disponibilidade unificada PowerView: cria e interage com exibições de dados de modelos baseados em pastas de trabalho do PowerPivot e fornece geração de relatórios ad-hoc intuitiva xvelocity: usa armazenamento da Columnstore com armazenamento em cache de memória, verificação de dados altamente paralela e algoritmos de agregação para intensificar o desempenho no data warehousing e Business Intelligence Data Quality Services: aumenta a qualidade dos dados usando conhecimento organizacional e provedores de dados de referência de terceiros para criar perfis, limpar e fazer a correspondência de dados Componentes do SQL Server Windows Server O SQL Server consiste em quatro componentes principais: Mecanismo do SQL Server Database: cria e impulsiona bancos de dados relacionais SSIS (SQL Server Integration Services: Executa o processo ETL (Extract, Transform, and Load) a fim de limpar e formatar dados brutos dos sistemas de origem nos bancos de dados como informações prontas para uso SSAS (SQL Server Analysis Services): o componente de análise de dados que cria cubos OLAP e data mining SSRS (SQL Server Reporting Services): fornece uma estrutura de geração de relatórios para criar, gerenciar e implementar relatórios gráficos de matriz tabular A plataforma de banco de dados é intimamente relacionada ao sistema operacional. O Microsoft Windows Server fornece uma infraestrutura sólida para o SQL Server. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 11 11

12 Tipos de volume do Windows Os estilos de partição de volume do Windows incluem MBR e GPT: MBR: o estilo de particionamento legado, que permite, no máximo, quatro partições. A tabela de partições é salva apenas no início do disco. GPT: estilo de particionamento que gerencia partições com mais de 2 TB. Sua tabela de partições é salva em vários locais. Ela poderá ser facilmente recuperada se alguma partição estiver corrompida. São suportados dois tipos de modo de disco: Básico: o disco mais básico, que contém partições primárias e, se necessário, partições estendidas. Os recursos do modo básico são: Partição primária: partição inicializável padrão. Partição estendida: partição não inicializável. Esta é a quarta partição em um disco MBR básico, que mantém partições lógicas, além de permitir mais de quatro partições. Partição lógica: partição não inicializável contida na partição estendida para ampliar o disco básico. EFI (Extensible Firmware Interface): usada para armazenar arquivos de inicialização em sistemas compatíveis com EFI. MSR (Microsoft System Reserved): disponível apenas em discos básicos GPT, usado para reservar espaço para uso futuro. Dinâmico: o disco dinâmico é um gerenciador de volume lógico baseado em host nativo, responsável por agregar discos em volumes lógicos com várias opções. Ele cria duas partições; uma contém todos os volumes dinâmicos e a outra permanece oculta e contém o banco de dados LDM (Logical Disk Manager). Esse banco de dados é replicado por todos os discos dinâmicos do sistema para que ele seja recuperável. Ele pode conter até volumes dinâmicos (32 é o número máximo recomendável). Os recursos do modo dinâmico são: Simples: Volume independente Fracionado: como o RAID 0, o volume fracionado grava um bloco de dados nos dois discos. Os volumes que integram esse arranjo devem ter o mesmo tamanho. Estendido: como RAID 0, com volumes concatenados. Se ocorrer uma falha no disco, somente a parte dos dados será perdida. Os volumes não precisam ter o mesmo tamanho. Ele apresenta um desempenho inferior ao dos volumes fracionados com a mesma quantidade de discos. Espelhamento: RAID 1 RAID: RAID 5 para o Microsoft Exchange Server 12 12

13 A Tabela 2 descreve os volumes típicos criados no armazenamento e usados no ambiente do SQL Server. Tabela 2. Implementação típica do SQL Server para armazenamento da Partição de volume Disco Volume Tamanho da alocação Opções de formatação MBR Básica NTFS 64 KB Formato rápido* Obs.: como o array da fornece proteção RAID de armazenamento, se possível, os discos dinâmicos deverão ser evitados, pois eles complicam o gerenciamento do armazenamento, bem como a recuperação de desastres local e remota. Opões de formato rápido são necessárias para thin-luns. SMB 3.0 O SMB (Server Message Block) 3.0 é uma nova versão do protocolo de compartilhamento de arquivos de rede existentes, que permite aos aplicativos em um computador ler e gravar em arquivos e solicitar serviços dos programas do servidor em uma rede de computadores. O SMB 3.0 foi introduzido no Windows Server 2012 e é compatível com o SQL Server 2012 como uma topologia de armazenamento viável para bancos de dados a partir da versão RTM do SQL Server O SQL Server 2012 dá suporte a discos virtualizados (VHD/VHDX) e bancos de dados hospedados diretamente em compartilhamentos do SMB 3.0. Os compartilhamentos podem ser apresentados ao Windows Server 2012 ou servidores de vários clusters. O SMB 3.0 oferece a capacidade de sobrevivência a falhas de hardware que, em outras situações, afetariam o acesso aos arquivos. A dá suporte completo ao SMB3.0 como uma topologia de armazenamento NFS para o SQL Server. Consulte Storage Windows 2012 para obter descrições detalhadas do armazenamento do Windows. Arquitetura do SQL Server A Figura 1 mostra os quatro principais componentes da arquitetura do SQL Server: SQL OS, gerenciamento, processador de consultas e camada de protocolo. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 13 13

14 Figura 1. Arquitetura do SQL Server SQL OS é a camada de aplicativos no nível mais baixo do mecanismo de banco de dados do SQL Server. Ele lida com atividades como programação, detecção de impasses e gerenciamento de memória. O SQL Server gerencia seus recursos de memória dinamicamente. O pool de buffer é o principal componente de memória do SQL Server. A memória não usada por outros componentes da memória permanece no pool de buffer e será usada como cache de dados para páginas lidas dos arquivos do banco de dados no disco. O gerenciamento de memória gerencia funções de I/O de disco para levar os dados e as páginas de índice para o cache de dados de maneira que os dados possam ser compartilhados entre os usuários. O mecanismo de armazenamento gerencia todo o acesso a dados por meio de comandos de transação e operações em lotes. Ele tem três áreas principais: métodos de acesso, serviço de bloqueio e transação e comandos de utilitário. A camada do processador de consultas (mecanismo relacional) aceita lotes de T-SQL e determina o que fazer. Ele analisa, compila e otimiza as consultas do T-SQL e supervisiona o processo de execução do lote. À medida que o lote é executado, uma solicitação para os dados é transmitida ao mecanismo de armazenamento. O processador de consultas tem dois componentes: Otimizador de consultas e executor de consultas. para o Microsoft Exchange Server 14 14

15 O otimizador de consultas determina o melhor plano de execução. O executor de consultas executa a consulta. O processador de consultas também gerencia a execução de consultas que solicitam dados do mecanismo de armazenamento e processa os resultados retornados. O conjunto de linhas do OLE DB (Object Linking and Embedding Database) é o canal de comunicação entre o mecanismo relacional e o mecanismo de armazenamento. O analisador de comandos lida com eventos da linguagem T-SQL enviados às instâncias do SQL Server, verifica a sintaxe adequada e converte os comandos de T-SQL na árvore de consultas. O otimizador de consultas obtém a consulta e a prepara para execução compilando o lote de comandos, otimizando as consultas e encontrando a melhor maneira de processá-la em um plano de execução. O executor de consultas coloca em prática o plano de execução, agindo como um dispatcher para todos os comandos do plano. A camada de protocolo recebe a solicitação do aplicativo do usuário e a converte em um formulário com o qual o mecanismo relacional possa trabalhar. Ele também converte os resultados das consultas, o status e as mensagens de erro em um formato que o client possa entender. Componentes lógicos do SQL Server O Microsoft SQL Server inclui dois componentes lógicos principais: Mecanismo relacional (processador de consultas), usado para verificar instruções SQL e selecionar a maneira mais eficiente de recuperar os dados da consulta Mecanismo de armazenamento, usado para executar solicitação de I/O física e retornar a linha solicitada pelo mecanismo relacional Esses dois mecanismos trabalham juntos para fornecer integridade de dados para o SQL Server. A arquitetura lógica do SQL Server define como os dados são agrupados e apresentados de maneira lógica aos usuários. Estes são os componentes básicos dessa arquitetura: Tabelas: as tabelas são formadas por páginas de dados agregados de maneira lógica (o formato básico dos dados). As colunas e as linhas são os dois principais componentes de uma tabela do SQL Server. Índices: um índice criado em uma ou mais colunas de uma tabela e associado a uma tabela ou uma exibição acelera a recuperação dos dados. Índices clusterizados e não clusterizados não são compatíveis. Uma tabela só pode ter um índice clusterizado que defina a ordem na qual os dados estão armazenados na tabela. Tabela de heap é uma tabela sem índice. Exibições: uma exibição pode ser uma tabela virtual ou uma consulta armazenada. Os dados retornados de uma exibição são armazenados no banco de dados por meio da instrução selecionada. Procedimento armazenado: procedimento armazenado é um grupo de instruções Transact-SQL compiladas em um só plano de execução. Restrições, regras e acionadores: componentes que são usados para manter o tipo e a integridade dos dados da tabela. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 15 15

16 Funções definidas pelo usuário: as funções são usadas para encapsular uma lógica executada com frequência. Acionadores: um acionador é similar a um procedimento armazenado. Ele é anexado a uma tabela e executado apenas quando acionado por um comando INSERT, UPDATE ou DELETE. Componentes físicos do SQL Server Os componentes físicos do SQL Server determinam como os dados são armazenados no sistema de arquivos do sistema operacional. Arquivos de banco de dados, páginas, extensões e arquivos de registro de transações são os componentes físicos básicos do SQL Server. Tipos de arquivo Os bancos de dados SQL Server têm os seguintes tipos de arquivo: Arquivos de dados primários têm uma extensão MDF. Um banco de dados requer, pelo menos, um arquivo de dados primário. Arquivos de dados secundários têm uma extensão NDF. Todos os arquivos de dados de um banco de dados que não são arquivos primários são secundários. Arquivos de dados secundários não são necessários, e um banco de dados pode ter muitos arquivos secundários ou nenhum. Arquivos de registro têm uma extensão LDF. Eles contêm todas as informações do registro de transações necessárias para recuperar o banco de dados. Cada banco de dados tem um arquivo de registro, independentemente do número de arquivos de dados. Os arquivos de dados armazenam dados e informações de índice. A Figura 2 representa o layout físico de um objeto de arquivo de dados que mostra o relacionamento de páginas e extensões. Figura 2. Arquivo de dados, páginas e extensões Páginas e extensões Uma página do SQL Server é a unidade básica do armazenamento de dados lógico. Com um tamanho de página de 8 KB (128 páginas por megabyte), cada página começa com um cabeçalho de 96-bytes que contém informações do sistema sobre a página. para o Microsoft Exchange Server 16 16

17 O espaço em disco alocado ao arquivo de dados primário ou secundário (.mdf ou.ndf) é dividido em páginas de maneira lógica. As operações de I/O de disco são executadas no nível da página. Extensões são as unidades básicas que gerenciam o espaço. Cada extensão tem oito páginas fisicamente adjacentes, com 64 KB (16 extensões por megabyte). Uma tabela ou um índice é, geralmente, alocado com páginas de extensões mistas. Extensões uniformes são usadas para alocações subsequentes após o aumento para oito páginas. Registro de transações O registro de transações mantém as modificações feitas pelas transações nos arquivos de dados. Ele contém informações relacionadas aos seguintes eventos: O início e o fim de cada transação Modificação de dados Alocação e cancelamento da alocação de extensões e páginas- Criação e eliminação de uma tabela ou um índice O registro de transações é essencial para recuperar bancos de dados durante uma falha do sistema. Os registros do registro são armazenados em uma sequência de série, e cada registro contém um ID de transação. Um só registro de transações físicas é segmentado de maneira lógica em registros virtuais baseados em algoritmos internos do SQL Server e no tamanho inicial do registro de transações. Um registro virtual dentro do arquivo de registro físico registra informações transacionais sempre que a atividade transacional é iniciada. Grupo de arquivos Um grupo de arquivos do SQL Server pode ser usado para separar arquivos para tabelas e índices, permitindo a colocação seletiva deles no nível do disco. Ele pode Separar tabelas e índices no nível do disco Separar os objetos que requerem mais arquivos de dados devido a uma alta taxa de alocação de página O administrador do banco de dados SQL Server pode: Realizar um backup no nível do arquivo ou no grupo de arquivos. O SQL Server pode fornecer disponibilidade parcial a um grupo de arquivos específico. Ele pode permanecer on-line enquanto o grupo de arquivos primário estiver online, mesmo quando outros grupos de arquivos estiverem off-line. Um grupo de arquivos estará disponível ser todos seus arquivos estiverem disponíveis. Use grupos de arquivos separados para dados em linha e dados de objetos grandes em tabelas e índices Use um grupo de arquivos para tabelas particionadas: Cada partição pode estar em seu próprio grupo de arquivos As partições podem ser colocadas e retiradas da tabela para se obter um melhor arquivamento Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 17 17

18 Características de I/O e largura de banda do SQL Server Visão geral Entender o padrão de I/O e as características do SQL Server é essencial para projetar e implementar os aplicativos do SQL Server. Um subsistema de I/O configurado de maneira adequada pode otimizar o desempenho do SQL Server. Há dois tipos de cargas de trabalho genéricas de banco de dados SQL Server: OLTP e data warehouse/olap. Um banco de dados de usuário específico pode gerar uma carga de trabalho de I/O drasticamente diferente daquelas do benchmark padrão. A única maneira de determinar as necessidades de desempenho de I/O é analisar o banco de dados em uma carga típica em tempo real. OLTP As cargas de trabalho OLTP produzem numerosas transações simultâneas com leituras de I/O aleatórias significativas e gravações (IOPS). Os bancos de dados OLTP são alterados constantemente. A maioria dos aplicativos ad-hoc gera carga de trabalho OLTP. De acordo com os artigos Microsoft SQL Server Best Practice, as cargas de trabalho de bancos de dados OLTP contêm os seguintes padrões: As leituras e as gravações emitidas em relação a arquivos de dados são geralmente aleatórias por natureza. A atividade de leitura (na maioria dos casos) é constante por natureza. A atividade de gravação nos arquivos de dados ocorre durante as operações de checkpoint (frequência determinada por configurações de intervalo de recuperação). As gravações em registro são sequenciais por natureza, com tamanho variável dependendo do tipo de carga de trabalho (setor alinhado com até 60 KB). As leituras do registro são sequenciais por natureza (setor alinhado com até 120 KB). Em geral, os bancos de dados OLTP têm muitas atividades de gravação que pressionam o subsistema de I/O, particularmente a LUN de registro, porque a gravação vai primeiro para o registro de transações. Um sistema OLTP típico tem um grande número de conexões simultâneas adicionando e modificando ativamente os dados, por exemplo, em um sistema de reserva online de companhias aéreas. Um sistema OLTP requer, com frequência, o backup de registros de transações e coloca demandas adicionais no subsistema de I/O. Em configurações que usam a replicação transacional, após a ocorrência do snapshot inicial, alterações subsequentes em dados e modificações do esquema feitas no editor são entregues ao assinante, impulsionando mais atividade de leitura para o registro de transações no banco de dados de assinante. para o Microsoft Exchange Server 18 18

19 O uso de índice é outro fator que afeta o subsistema de I/O. Sistemas OLTP altamente indexados podem dar suporte a alta simultaneidade e baixa latência para recuperar um pequeno número de linhas de conjuntos de dados que contenham muito poucos dados históricos. A volatilidade de transações em um sistema OLTP pode requerer uma manutenção frequente do índice, gerando uma alta carga de solicitações de leitura e gravação no subsistema I/O. Em geral, os sistemas OLTP geram um grande número de IOPS (Input/Output Operations per Second, operações de entrada/saída por segundo). Uma quantidade maior de drives de disco dá suporte a uma maior capacidade de IOPS. Data warehouse/banco de dados OLAP Em geral, o data warehousing é a base de um DSS (Decision Support System, sistema de suporte a decisões) ou um sistema de Business Intelligence. Trata-se de um repositório de dados de uma organização, projetado para facilitar atividades de consulta analítica complexas usando conjuntos de dados de grande porte para geração de relatórios e análise. Os bancos de dados de data warehouse são do tipo OLAP (Online Analytical Processing) que, geralmente, usam análise complexa com dados agregados ou resumidos no data warehouse. Os dados no sistema de data warehouse, geralmente, são estáticos com leitura sequencial e muito pouca atividade de gravação, exceto atualizações em lote típicas. A largura de banda de I/O é mais importante que a IOPS. A carga de trabalho típica em um data warehouse faz uso intenso de I/O com operações como carga de dados de grande porte e criação de índice, criação de exibições e consultas em grandes volumes de dados. O subsistema de I/O subjacente para o data warehouse deve atender a estes requisitos de alta largura de banda. As características de I/O para data warehouse são: Leituras e gravações sequenciais, geralmente, o resultado de verificações em tabelas ou no índice e de operações de inserção em massa Dados não voláteis, conjuntos de dados históricos maiores Índice leve na tabela de fatos Baixa simultaneidade Alta atividade do banco de dados temporário Tamanho de I/O variado: geralmente, superior a 8 KB. A leitura antecipada corresponde a qualquer múltiplo de 8 KB até 512 KB. As operações de carregamento em massa correspondem a qualquer múltiplo de 8 KB até 128 KB. Ao usar indexação da Columnstore, o tamanho de I/O dos arquivos do banco de dados é muito maior que 256 KB Uma importante consideração sobre o projeto de uma solução de armazenamento eficiente de DW (Data Warehouse) é equilibrar os recursos do sistema de DW pelas camadas de computação, rede e armazenamento. Por exemplo, a camada de computação deve ser capaz de processar dados a taxas de largura de banda que possam ser fornecidas pelo armazenamento em níveis de utilização confortáveis. Por sua vez, o sistema de rede das camadas de computação e armazenamento deve ser suficiente para sustentar o throughput máximo permitido entre essas camadas. De preferência, para garantir uma solução de DW com bom custo-benefício, os elementos da solução devem ter capacidade equiparada. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 19 19

20 Ao projetar um data warehouse, calcule quanto de largura de banda de I/O um determinado servidor e placas de HBA (Host Bus Adapter, adaptador de barramento do host) podem utilizar, e garanta que a configuração de I/O selecionada possa atender ao requisito do servidor. Um sistema de data warehouse bem projetado otimiza o sistema de armazenamento para operações centralizadas em verificações ; a CPU do servidor pode receber e processar dados fornecidos pelo armazenamento na mesma largura de banda. Como as consultas no data warehouse podem buscar milhões de registros do banco de dados para processamento, os dados, geralmente, são grandes demais para caberem na memória. Um bom projeto de armazenamento deve localizar e entregar, com rapidez, os dados do disco para os processadores a fim de executar a agregação e a compactação. Lendo páginas As leituras de I/O do mecanismo de banco de dados SQL Server são dos seguintes tipos: Leitura lógica: ocorre quando o mecanismo de banco de dados solicita uma página do cache do buffer Leitura física: copiará a página do disco no cache se ela não estiver atualmente no cache do buffer As solicitações de leitura são controladas pelo mecanismo relacional e otimizadas pelo mecanismo de armazenamento. O mecanismo de leitura antecipada antecipa as páginas de dados e índice necessárias a um plano de execução de consultas e traz as páginas para o cache do buffer que estiver sendo usado pela consulta. Esse mecanismo torna possível sobrepor a computação com I/Os a fim de fazer uso total da CPU e do disco para otimizar o desempenho. Gravando páginas As gravações de I/O de uma instância do mecanismo de banco de dados são dos seguintes tipos: Gravação lógica: ocorre quando os dados são modificados em uma página no cache do buffer Gravação física: ocorre quando a página é gravada do cache do buffer no disco As leituras e gravações de páginas ocorrem no cache do buffer. Sempre que uma página é modificada no cache do buffer, ela é marcada como suja. Uma página pode ter mais de uma gravação lógica antes de ela ser fisicamente gravada no disco. Os apontamentos do registro devem ser gravados no disco antes de a página suja associada ser gravada no disco. Para garantir a consistência dos dados, o SQL Server usa registro de gravação antecipada para impedir a gravação de uma página suja antes de o apontamento do registro ser gravado no disco. A Figura 3 ilustra a operação de gravação de páginas no SQL Server. para o Microsoft Exchange Server 20 20

21 Figura 3. Operação de gravação de páginas no SQL Server Uma página suja é gravada em um disco de uma das seguintes maneiras: Gravação lenta: processo do sistema que mantém os buffers livres disponíveis removendo do cache do buffer páginas não usadas com frequência. A gravação lenta grava páginas sujas no disco. Gravação rápida: esse processo do sistema grava páginas sujas com operações não registradas, como seleção ou inserção em massa. Checkpoint: a operação de checkpoint verifica periodicamente páginas de banco de dados no cache do buffer e grava as páginas sujas no disco. A gravação lenta, a gravação rápida e os processos de checkpoint usam I/O assíncrona que permite ao thread de chamada continuar o processamento, enquanto a operação de I/O ocorre no plano de fundo a fim de maximizar os recursos de CPU e I/O para as tarefas apropriadas. Log Manager Uso do banco de dados temporário A carga de trabalho do registro é a I/O em relação ao registro de transações. Geralmente, ela tem gravações sequenciais e requer baixa latência para cargas de trabalho de transações em alta escala. As gravações do arquivo de registro de transações são síncronas para uma determinada transação, porque o SQL Server faz o flush de todas as atualizações associadas a uma transação confirmada no registro para que o thread do usuário possa iniciar a próxima transação. O banco de dados temporário é um banco de dados do sistema que é usado pelo SQL Server como um espaço de trabalho temporário. O padrão de I/O para o banco de dados temporário é similar a padrões OLTP. Dependendo da carga de trabalho, o banco de dados temporário pode variar de baixa atividade (no tipo OLTP de cargas de trabalho) a atividade extremamente alta (cargas de trabalho DSS ou OLAP). Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 21 21

22 Padrões de I/O A Tabela 3 resume os padrões de I/O envolvidos em cada tipo de banco de dados. Tabela 3. Padrões de I/O de diferentes cargas de trabalho para um banco de dados SQL Server Tipos e características de I/O Arquivos de dados Arquivo de banco de dados OLTP (Online Transaction Processing) I/Os aleatórias menores (8 64 KB) Alta proporção de leituras em comparação com gravações (geralmente, proporção de leitura/gravação de 90/10 a 70/30) Alto desempenho e proteção, em geral, podem ser obtidos com RAID 10. Com armazenamento hierárquico, é possível usar RAID 5 ou RAID 6 no pool de armazenamento para proporcionar desempenho suficiente. Sistema de suporte a decisões (data warehouse, OLAP) I/Os sequenciais maiores (a maioria, com 64 KB; podem ter mais de 256 KB com índice da Columnstore) Baixa proporção de gravações em comparação com leituras, às vezes, somente leitura Geralmente, o RAID 5 proporciona um desempenho adequado e muito mais espaço utilizável para um determinado número de discos Arquivo de registro de banco de dados Arquivo de dados do banco de dados temporário I/Os pequenas e altamente sequenciais (alguns múltiplos de 512 bytes) Quase exclusivamente gravações, com leituras ocasionais durante reversões de grande porte ou backups de registro O RAID 1/0 é recomendado para registros. O RAID 5 também pode proporcionar um desempenho adequado (devido às gravações de frações completas). O desempenho pode diminuir quando há falhas em um drive (a degradação do desempenho poderá ser ignorada se for em flash drives.) Tamanho variável dependendo do uso (em geral, I/O maior, normalmente, não excede 64 KB) I/Os seriais ou aleatórias, uma determinada carga de trabalho pode ser um tanto sequencial, muitas cargas de trabalho em execução simultânea podem fornecer ao banco de dados temporário uma aparência de I/O aleatória Geralmente, uma divisão de cerca de 50/50 de gravações e leituras Com base na natureza imprevisível do banco de dados temporário combinado com sua proporção de gravações geralmente alta, o RAID 1/0, em geral, proporciona o melhor desempenho para um determinado número de discos. Semelhante aos arquivos de registro, o RAID 5 também pode proporcionar um desempenho adequado, principalmente quando são usados flash drives. A atividade do banco de dados temporário varia. Geralmente, ele não é muito ativo com baixa demanda de desempenho. Pode ser muito ativo para relatórios frequentes e associações de tabelas de grande porte. O banco de dados temporário pode ter alta demanda de desempenho que requer armazenamento flash no lado do servidor, como XtremSF. para o Microsoft Exchange Server 22 22

23 Práticas Recomendadas para Dimensionamento e Provisionamento de Armazenamento do SQL Server Visão geral O projeto de armazenamento é um dos mais importantes elementos de uma implementação bem-sucedida do Microsoft SQL Server. Para obter um projeto de armazenamento com o nível ideal de confiabilidade, desempenho, custo e facilidade de uso, siga as diretrizes de armazenamento recomendadas. Esta seção apresenta as práticas recomendadas gerais para implementação do SQL Server em armazenamento da, como o armazenamento da série Symmetrix VMAX, VNX Unified Storage, XtremSF e XtremSW Cache, além de recomendações para recursos específicos de storage array da com o SQL Server. Visto que a virtualização de um ambiente do SQL Server exige um conjunto próprio de considerações, esta seção também oferece orientação sobre esse assunto. Práticas recomendadas gerais para o armazenamento do SQL Server A recomenda que você inicie o projeto do SQL Server com cinco LUNs, conforme mostrado em Figura 4, e expanda essa configuração com base nos requisitos de desempenho dos aplicativos. Figura 4. Configuração do SQL Server Para a configuração do SQL Server, comece considerando os seguintes requisitos básicos: Binários do SO/SQL Server Em uma implementação típica do SQL Server, o servidor é dedicado ao SQL Server e os binários estão na mesma LUN que o SO. Siga a recomendação da Microsoft para o tipo de SO e a versão do SQL Server e considere a sobrecarga para aplicativos que você precisa instalar nesse servidor. As LUNs típicas para os binários do SO/SQL Server/bancos de dados do sistema têm GB. Geralmente, os discos de alta capacidade/baixo desempenho em um pool de armazenamento RAID 5 podem atender a essa necessidade. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 23 23

24 Bancos de dados do sistema Na maioria dos ambientes, os bancos de dados do sistema não são alterados com frequência e podem ter a mesma LUN que o SO. Registros para bancos de dados de usuário Os registros de bancos de dados de usuário, em geral, precisam de baixa IOPS (na maior parte, gravações sequenciais). Mesmo com replicação, como AAG (AlwaysOn Availability Group), as IOPS necessárias nessas LUNs, em geral, não são muito exigentes. Dessa maneira, as LUNs de registro são, em geral, configuradas com discos FC (Fibre Channel) (em um pool de armazenamento, pode ser afixado no nível FC) que podem atender à necessidade de capacidade com, pelo menos, 10% de espaço extra. Tempbd Em um ambiente OLTP, o banco de dados temporário pode não ser muito exigente em relação a I/O e pode seguir os mesmos princípios de projeto para registros. Nesse caso, geralmente, eles podem estar no mesmo pool, com as LUNs de registro do banco de dados SQL Server. Quando há geração de relatórios ad-hoc ou programada ou associações de tabelas de grande porte, o uso do banco de dados pode ser intenso. É necessário medir as necessidades do sistema SQL para determinar o uso do banco de dados temporário. Um banco de dados temporário em um data warehouse ou para cargas de trabalho OLAP, geralmente, tem demandas de I/O muito intensas e exige atenção especial nesses ambientes. O projeto do banco de dados temporário nesses ambientes deve seguir, se necessário, o princípio de projeto de banco de dados em termos de dimensionamento e posicionamento. Banco de dados do usuário As LUNs do banco de dados de usuário, geralmente, são o principal foco do projeto de armazenamento. Os tipos de LUN variam de acordo com os requisitos de desempenho e capacidade, bem como o tipo de carga de trabalho. Siga as práticas recomendadas gerais de armazenamento do SQL Server apresentadas na Microsoft TechNet. Estes são alguns dos pontos principais: Práticas recomendadas básicas para o SQL Server Estas são algumas das práticas recomendadas básicas para o SQL Server: Selecione a política Lock pages in memory para a conta inicial do SQL Server a fim de evitar que o SQL Server efetue swap da memória. Faça a pré-alocação dos arquivos de dados para evitar Autogrow durante o horário de pico. Defina Autoshrink como Off para arquivos de registro e dados. Faça arquivos de dados de tamanho equivalente no mesmo banco de dados o SQL Server usa um algoritmo de preenchimento proporcional que favorece alocações em arquivos com mais espaço livre. Execute a manutenção rotineira com recriação do índice ou reorganização com o comando dbcc checkdb. para o Microsoft Exchange Server 24 24

25 Considerações sobre arquivos e grupos de arquivos As seguintes considerações são relativas a grupos de arquivos no SQL Server: É possível acessar grupos de arquivos paralelamente; a colocação de grupos de arquivos em discos/pool de armazenamento diferentes pode melhorar o desempenho. Ao projetar um banco de dados, organize em um grupo os arquivos de dados do SQL Server que apresentam necessidades de desempenho e proteção semelhantes. Para alocar bancos de dados intensos como o temporário, quando necessário, crie 0,25 a 1 arquivos de dados por grupo para cada CPU. Inicie com um pequeno número de arquivos de dados. Aumente os números quando necessário. Crie um arquivo de registro em um ambiente típico. Uma quantidade de arquivos de registro maior não melhorará o desempenho. Consulte Usando arquivos e grupos de arquivos na Biblioteca Microsoft MSDN para obter mais informações. Práticas recomendadas básicas de armazenamento Veja a seguir algumas práticas recomendadas básicas de alto nível para o projeto do armazenamento. Os detalhes são apresentados em Considerações gerais sobre armazenamento. Planeje o desempenho, a capacidade e a proteção. A Tabela 4 lista os tempos de resposta para arquivos de dados e de registro. Tabela 4. Tempos de resposta para arquivos de dados e de registro Tempo de resposta de I/O Arquivos de dados registro Muito bom Menos de 10 ms Menos de 5 ms Aceitável 10 a 20 ms 5 a 15 ms Precisa de investigação e aprimoramento Mais de 20 ms Mais de 15 ms Ao criar um volume no Windows, defina a unidade de alocação do Windows como 64 K para LUNs de registro e banco de dados SQL Server. Para obter o desempenho ideal com um nível de serviço previsível, coloque o banco de dados temporário, os arquivos de registro e dados em LUNs separadas. Para deixar espaço para o aumento dos dados, evite exceder 80% da capacidade das LUNs com arquivos do banco de dados. Coloque LUNs para arquivos de dados em drives mais rápidos ou use para eles classificação automatizada por níveis. Coloque LUNs para arquivos de registro em drives SAS ou FC sem classificação automatizada por níveis. Use drivers HBA atualizados, recomendados pelo fabricante. Garanta que o firmware do storage array esteja atualizado. Considere usar múltiplos caminhos para otimização da disponibilidade/redundância e do throughput, principalmente em configurações baseadas em arquivos/iscsi. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 25 25

26 Considerações sobre clustering A proteção é necessária para um banco de dados temporário no SQL Server. O arquivo do banco de dados temporário é recriado sempre que uma instância do SQL Server é iniciada. Em ambientes XtremSF, VPLEX e CE (Cluster Enabler), é possível usar, sempre que possível, partições de disco não compartilhadas para o banco de dados temporário em um cluster FCI do SQL Server 2012, a fim de reduzir o custo e a largura de banda. Considerações sobre versões anteriores Considere o seguinte ao usar versões anteriores do SQL Server e do Windows: Para o SQL Server 2005 e versões anteriores, habilite o privilégio Instant File Initialization do Windows cedendo privilégios à conta de inicialização do SQL Server. Para versões anteriores ao Windows 2008, verifique se as configurações de alinhamento do setor estão corretas. O Windows 2008 e versões posteriores alinham os setores por padrão. Considerações gerais sobre armazenamento Considerações sobre desempenho versus capacidade Ao implementar o Microsoft SQL Server, sempre considere os requisitos de desempenho, proteção e capacidade. Para cargas de trabalho OLTP típicas, é mais provável que as medições em IOPS superem o requisito de capacidade para arquivos de banco de dados e arquivos de registro. Geralmente, os arquivos do banco de dados temporário estão vinculados à capacidade devido à natureza de baixa I/O da carga de trabalho. Em um ambiente OLAP, as medições de largura de banda em megabytes ou gigabytes são mais dominantes para arquivos de banco de dados, enquanto é mais provável que os arquivos do banco de dados temporário exijam um throughput (IOPS) mais elevado. Os arquivos de registro e do banco de dados de usuário devem ser bem protegidos para evitar perda de dados. Como o arquivo do banco de dados temporário só contém dados temporários e pode ser recriado na inicialização do SQL Server, a proteção para o banco de dados temporário não é uma alta prioridade. Quando o desempenho do banco de dados temporário é essencial (como no ambiente OLAP), é ideal que o banco use um flash drive de servidor como o XtremSF para minimizar a latência do armazenamento. Ao projetar o armazenamento para um tipo diferente de cargas de trabalho, considere o tipo de carga e seu padrão de I/O típico para arquivos do banco de dados, de registro e do banco de dados temporário. Calcule os requisitos de desempenho e capacidade para garantir que ambos sejam satisfeitos. Seleção de tipo de disco Uma das primeiras decisões-chave que você deve tomar ao projetar o armazenamento do SQL Server é a seleção dos tipos de disco que correspondem melhor a seus requisitos. Os tipos de disco apropriados para sua implementação do SQL Server dependem de uma série de fatores, inclusive o tamanho do banco de dados e os requisitos de IOPS. para o Microsoft Exchange Server 26 26

27 A Tabela 5mostra os tipos de disco que a oferece com sua família VNX de armazenamento unificado e armazenamento da série Symmetrix VMAX. A tecnologia Flash também é usada como o XtremSF e o XtremSW Cache. Tabela 5. Tipo de disco FC (Fibre Channel) Tipos de disco oferecidos pela Características Drives de disco confiáveis com altas velocidades de leitura/gravação. Consideração sobre seleções Ideais para altos requisitos de I/O, mas podem não ser apropriados para requisitos de alta capacidade SAS (Serial Attached SCSI) SATA SAS nearline (NL- SAS) Flash Uma melhoria dos drives SCSI tradicionais, os discos SAS oferecem alta capacidade com velocidade de I/O moderada. Discos com grande capacidade e velocidade de I/O menos exigente. Como os discos SATA, os discos NL-SAS são adequados para requisitos de I/O menos exigentes, mas de alta capacidade. Os flash drives apresentam a mais alta velocidade de I/O com baixo consumo de energia. Altamente adequados para ambientes SQL Server com altos requisitos de IOPS Apropriados para bancos de dados de grande porte com baixos requisitos de I/O. Mais adequados para data warehouse e banco de dados de conteúdo SharePoint Os discos NL-SAS podem aceitar bancos de dados de grande porte a um custo relativamente baixo. Os discos NL-SAS são, geralmente, a melhor escolha para bancos de dados maiores com baixos perfis de I/O. Em geral, os flash drives podem ser usados da seguinte maneira: No storage array como parte dos recursos de classificação de armazenamento automatizada por níveis, como FAST VP ou FAST Cache, para lidar com picos inesperados de I/O Em servidores como XtremSF e XtremSW Cache A também oferece o XtremIO de array de somente flash para o ambiente SQL Server mais exigente. Siga estas regras gerais ao selecionar tipos de discos: Para baixa IOPS, latência de disco aceitável e altos requisitos de capacidade do banco de dados, use discos SATA ou NL-SAS. Para alta IOPS, baixa latência de disco e altos requisitos de capacidade do banco de dados, use discos FC ou SAS. Para IOPS mais elevada e requisitos de latência de disco muito baixa, mas requisitos de menor capacidade do banco de dados, use flash drives no armazenamento com classificação por níveis ou FAST Cache. Para requisitos mais exigentes de IOPS e latência de disco, mas menor capacidade do banco de dados, use XtremSF, XtremSW Cache. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 27 27

28 Diferentes tipos de disco são compatíveis com IOPS com o mesmo requisito de latência. Leve isso em consideração ao calcular os requisitos de disco para seu ambiente. A tabela a seguir fornece dados de IOPS de disco aleatório da validação mais recente do SQL Server em armazenamento VNX e VMAX da. Estes resultados estão sujeitos a alterações com base em testes futuros. Obs.: a recomenda expressamente o uso dos valores da Tabela 6 ao calcular os requisitos de IOPS para a implementação do SQL Server e de storage arrays VNX e VMAX. Estes números fornecerão uma linha de base do desempenho típico aceitável, conforme mostrado na Tabela 4. Para aplicativos que requerem um melhor desempenho, adicione mais discos ou use armazenamento em cache de array, como o FAST Cache, ou armazenamento em cache de servidor, como o XtremSW Cache. Tabela 6. IOPS para I/O de leitura aleatória de 8 KB em vários tipos de disco em storage arrays da Tipo de disco IOPS por disco SAS de RPM 180 SAS de RPM 140 NL/SAS de RPM 70 SSD (Solid State Disk) A Tabela 7lista a IOPS para flash de servidor. Tabela 7. IOPS do SQL Server para modelos do XtremSF IOPS de aleatória XSF550 MLC * XSF550 MLC * XSF2200 MLC * XSF2200 MLC * XSF320 SLC XSF700 SLC Leitura Gravação R/W (70/30) * No modo de desempenho. A IOPS será mais baixa quando configurada no modo de capacidade padrão. Pools e tipos de RAID A seleção de um tipo apropriado de RAID para o ambiente é outra importante decisão para uma implementação bem-sucedida do SQL Server. É possível usar qualquer tipo de RAID caso haja discos suficientes para lidar com os requisitos de I/O e capacidade de armazenamento. Em geral, as decisões quanto ao tipo de RAID se baseiam em um conjunto de determinados requisitos. Para selecionar um tipo de RAID apropriado para o ambiente, considere seus requisitos específicos de desempenho, capacidade e disponibilidade. Os sistemas de armazenamento da são compatíveis com RAID 1/0, RAID 5 e RAID 6 usando flash drives, FC, SAS, NL-SAS e SATA. Cada tipo de RAID oferece diferentes níveis de desempenho, capacidade e proteção. para o Microsoft Exchange Server 28 28

29 RAID 1/0 oferece proteção de dados pelo espelhamento dos dados em outro disco. Isso resulta em melhor desempenho e impacto mínimo ou nulo sobre o desempenho em caso de falha do disco. Em geral, RAID 1/0 é a melhor escolha para o SQL Server, principalmente se forem usados drives SATA e NL-SAS. Os dados do RAID 5 são fracionados entre discos em frações de grande tamanho. As informações de paridade são armazenadas em todos os discos para que os dados possam ser reconstruídos. Isso pode oferecer proteção contra falha de disco único. Com uma alta penalidade de gravação, o RAID 5 é o mais adequado em ambientes com predominância de I/Os de leitura e nos quais bancos de dados de grande porte são implementados. No caso de flash drives SSD, essa preocupação em relação ao desempenho é eliminada, e a maioria dos ambientes com flash drives pode ser configurada como RAID 5 para dar suporte a altos requisitos de I/O com latência de disco muito baixa. Os dados do RAID 6 também são fracionados entre discos em frações de grande tamanho. No entanto, dois conjuntos de informações de paridade são armazenados em todos os discos para que os dados possam ser reconstruídos conforme necessário. O RAID 6 pode acomodar a falha simultânea de dois discos sem perda de dados. A Tabela 8 apresenta informações sobre desempenho, sobrecarga e utilização de armazenamento para cada tipo de RAID. Obs.: o valor de sobrecarga de RAID se torna importante ao efetuar cálculos de I/O para o número de discos necessários. RAID 5 e RAID 6 afetam o desempenho quando ocorrem falhas em um drive e ele precisa ser reconstruído. Na Tabela 8, o desempenho é comparado usando o mesmo número e o mesmo tipo de discos nas configurações de RAID. A utilização do armazenamento é comparada usando os mesmos tipos de disco nas configurações de RAID para gerar as mesmas IOPs com latência semelhante. Tabela 8. Características de desempenho do nível de RAID Nível de RAID Aleatório Leitura Gravações aleatórias Leituras sequenciais Gravações sequenciais Gravações RAID valor de sobrecarga Utilização do armazenamento RAID 1/0 Excelente Excelente Excelente Excelente 2 Baixa RAID 5 Excelente Moderada Boa Moderada 4 Alta RAID 6 Boa Ruim Boa Moderada 6 Média Pools de armazenamento são estruturas virtuais que permitem que os dados sejam movidos dinamicamente entre os diferentes níveis dos drives (de alto desempenho a menor custo/maior capacidade e vice-versa) de acordo com as atividades de negócios dos dados. Com os sistemas VNX e VMAX, os pools de armazenamento são totalmente automatizados para fins de autogerenciamento. O uso de pools de armazenamento simplifica o provisionamento de armazenamento. O provisionamento baseado em pools oferece benefícios semelhantes ao striping de metaluns entre muitas unidades. Porém, diferentemente das metaluns, os pools de armazenamento exigem planejamento e esforços de gerenciamento mínimos. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 29 29

30 Os pools de armazenamento são compatíveis com os mesmos níveis de proteção RAID que os grupos de RAID: RAID 5, RAID 6 e RAID 1/0. Pools com vários níveis e diferentes tipos de disco e RAID podem estar no mesmo pool de armazenamento. Os pools de armazenamento também fornecem serviços de dados avançados, como FAST VP, compactação e desduplicação, e as opções de proteção de dados, como VNX Snapshots. A maioria dos ambientes de banco de dados SQL Server pode se beneficiar de configurações baseadas em pool de armazenamento. Considerações sobre armazenamento de provisionamento virtual Os sistemas VMAX e VNX da oferecem provisionamento virtual, geralmente conhecido no setor como provisionamento thin. O provisionamento thin ou virtual pode simplificar o gerenciamento do armazenamento e reduzir seus custos aumentando a utilização da capacidade em muitos casos de uso do SQL Server. O provisionamento virtual permite que o SQL Server adquira capacidade além da que está fisicamente alocada. O armazenamento físico é alocado ao banco de dados "sob demanda" a partir de um pool compartilhado, conforme necessário. A capacidade do armazenamento físico é totalmente alocada durante a criação de thick-luns. Embora as thin-luns tenham inicialmente menos capacidade de armazenamento físico alocada a elas, o pool de armazenamento fornece armazenamento físico real que dá suporte a alocações de thin-luns, quando necessário.o armazenamento físico á automaticamente alocado apenas quando novos blocos de dados são gravados na thin-lun. As thick e thin-luns podem proporcionar as características de desempenho necessárias a qualquer carga de trabalho do SQL Server. Thin-LUN versus thick-lun Os dispositivos thin podem ser criados com uma capacidade aumentada, pois os dispositivos de dados fornecem o espaço de armazenamento real para os dados gravados neles. Para um sistema operacional de host, os dispositivos thin têm a mesma capacidade configurada que os dispositivos padrão, e o host interage com eles da mesma forma que os dispositivos padrão. A thin-lun pode ser usada na maioria dos ambientes com desempenho razoável, principalmente com FAST VP (VNX e VMAX) e/ou com o FAST Cache (no VNX). As principais considerações sobre desempenho relacionadas a thin-luns são: As thin-luns proporcionam economias de armazenamento significativas e acomodam o crescimento futuro. Ocorre uma pequena sobrecarga no desempenho quando uma LUN é expandida para acomodar as gravações recebidas. Para resumir, ao decidir se usará pools de armazenamento, thin-luns, thick- LUNs ou RAID para configuração de LUNs, considere o seguinte: Use pools de armazenamento para tirar proveito dos serviços de eficiência de dados (como FAST VP), compactação, desduplicação e outras opções baseadas em pool. Use thin-luns com pools para facilitar a configuração e o gerenciamento, aumentar a eficiência do espaço, obter economia de energia e capital e bancos de dados com consumo de espaço flexível com o decorrer do tempo. para o Microsoft Exchange Server 30 30

31 Use thick-luns para bancos de dados com requisitos de espaço previsíveis. Use grupos de RAID e LUNs tradicionais para bancos de dados que não exigem alterações de tamanho e requisitos de desempenho com o tempo, para colocar, de maneira precisa, objetos de dados lógicos em drives físicos e para separar dados fisicamente. Práticas recomendadas para dimensionamento de armazenamento As características de desempenho do SQL Server podem variar substancialmente de um ambiente para outro, dependendo do aplicativo. Essas características se inserem em duas categorias gerais: O OLTP gera cargas de trabalho com predominância de leituras aleatórias, e o data warehouse gera cargas de trabalho com predominância de leituras sequenciais, conforme descrito em Tabela 9. Em um ambiente OLTP, use IOPS de leitura/gravação (IO/s) para dimensionamento do armazenamento. Para um ambiente de data warehouse, use largura de banda (MB/s) para o dimensionamento do armazenamento. Para obter estimativas precisas do desempenho, execute testes em condições o mais próximas possível da situação real. Durante esses testes, use registros do monitor de desempenho para obter as características (como IOPS: leituras/segundo e gravações/segundo, largura de banda: MB/s) dos volumes usados para armazenar arquivos do banco de dados. Notas: Não use a média de contadores de IOPS obtida com o tempo como base para o projeto do armazenamento. A recomenda identificar o 90º percentil das amostras de IOPS e projetar o nível de desempenho. Isso permite que o sistema responda bem aos picos de demanda. Os requisitos de IOPS para um grupo de RAID devem ser calculados de maneira independente para leituras e gravações. Consideração sobre dimensionamento de banco de dados OLTP Dimensionamento para fins de desempenho Calcule o número de discos para o desempenho necessário com a seguinte fórmula: IOPS de gravação x sobrecarga do IOPS de leitura + desempenho do RAID Número de discos = IOPS por disco Obs.: talvez seja necessário ajustar o número de discos para atender aos requisitos para o nível de RAID selecionado. Por exemplo, um conjunto de RAID 1/0 de sete discos não é viável. Nesses casos, é necessário um conjunto de RAID 1/0 de oito discos. IOPS por disco é o número de IOPS do tipo de drive selecionado. A Tabela 6 em Seleção de tipo de disco fornece a IOPS por disco para diferentes tipos de disco recomendada para calcular as necessidades de disco para a configuração de RAID e de armazenamento hierárquico. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 31 31

32 Na configuração de armazenamento hierárquico, você também deve calcular os requisitos de capacidade para diferentes níveis. As seguintes ferramentas podem ajudar no projeto de armazenamento hierárquico: Storage Configuration Advisor para dimensionamento São necessários dados de desempenho históricos dos storage arrays. Para obter mais informações, consulte o site da. Workload Performance Assessment Tool Também conhecida como Mitrend, ela mostra o heat map do FAST VP. Para obter mais informações, consulte Ferramenta de dimensionamento do VSPEX (VNX) Para obter mais informações, consulte Dimensionamento para fins de capacidade Concluído o dimensionamento do desempenho, você deve considerar o requisito de armazenamento em termos de capacidade. Embora seja muito provável que o dimensionamento do banco de dados OLTP típico esteja vinculado ao desempenho, verifique o requisito de capacidade antes de concluir o projeto definitivo. Calcule o dimensionamento para fins de capacidade com base na configuração apresentada na Tabela 9. Tabela 9. Dimensionamento para fins de capacidade Tipo de RAID RAID sobrecarga para capacidade sobrecarga de RAID para desempenho (penalidade de gravação) Quantidad e mínima de drives Quantidade mínima de discos necessária para o tamanho da LUN 1/0 1/ x o tamanho da LUN 5 4/ /4 x o tamanho da LUN 6 4/ /4 x o tamanho da LUN Use a seguinte fórmula para calcular o número de discos para capacidade: Número de discos = Capacidade total necessária Sobrecarga de RAID para capacidade Obs.: ao calcular o tamanho da LUN, considere o aumento futuro do tamanho do banco de dados. Recomendamos que você reserve, pelo menos, 10% da capacidade para as LUNs de arquivos do banco de dados. Projeto final Use o maior número como o dimensionamento final para atender aos requisitos de desempenho e capacidade. para o Microsoft Exchange Server 32 32

33 Práticas recomendadas para o dimensionamento do FAST VP Em geral, uma pequena porcentagem da capacidade total utilizada é responsável pela maior parte da atividade de I/O em um determinado banco de dados. Isso é conhecido como skew de carga de trabalho. A análise de um perfil de I/O pode indicar que 85% de I/Os para um volume só envolvem 15% da capacidade. A capacidade ativa resultante é denominada conjunto de trabalho. Programas de software como o FAST VP e o FAST Cache podem manter o conjunto de trabalho no nível de desempenho mais elevado. As práticas seguintes são recomendadas para o dimensionamento do FAST VP: Preferencialmente, o conjunto de trabalho deve estar no nível mais elevado (FC/SAS/flash). Um conjunto de trabalho típico para uma carga de trabalho OLTP corresponde a 10% a 30% do arquivo de banco de dados. Dimensione o nível superior no FAST VP para garantir que o conjunto de trabalho possa ser migrado para o nível de desempenho mais alto. Os drives do FAST VP Performance Tier são versáteis ao lidar com um vasto espectro de perfis de I/O. Dessa forma, a recomenda ter drives do Performance Tier em cada pool. Drives de alta capacidade podem ajudar a otimizar o TCO e, quase sempre, compõem de 60% a 80% da capacidade de um pool. Perfis com baixa IOPS/GB e/ou cargas de trabalho sequenciais podem usar um número maior de drives de alta capacidade em um nível inferior. É importante determinar o skew de I/O antes de dimensionar os níveis do FAST VP. O skew SQL pode variar e depende do perfil real do SQL Server. Para a maioria das tarefas de dimensionamento do VNX, use apenas dois níveis: um nível de desempenho (FC/SAS/flash) e um nível de capacidade (SATA/NL-SAS). Considere uma carga de trabalho OLTP de skew de 85/15 e ajuste de acordo com o ambiente real: 85% de I/O com 15% de capacidade no nível de desempenho (FC/SAS/flash) 15% de I/O com 85% de dados no nível de capacidade (SATA/NL-SAS) No VMAX, pode haver até três níveis. Com uma carga de trabalho OLTP, considere 75/15/10 de skew ativo/dinâmico/inativo para I/O, em seguida, ajuste de acordo com o ambiente real: 10% de I/O e 75% de capacidade em SATA 15% de I/O e 15% de capacidade em FC 75% de I/O e 10% de capacidade em flash O Professional Services e parceiros qualificados podem ajudá-lo com o dimensionamento adequado dos níveis e dos pools a fim de maximizar o desempenho. Eles têm as ferramentas e o conhecimento para fazer recomendações específicas para a composição dos níveis com base em um perfil de I/O existente. Dimensionamento para fins de desempenho O cálculo de IOPS e discos é o mesmo fornecido para o grupo de RAID com skew: Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 33 33

34 Número de discos para o nível = IOPS de gravação x RAID por IOPS de leitura + sobrecarga de desempenho IOPS por disco de I/O para o nível Skew Obs.: é necessário arredondar cada nível para o próximo número de drives lógicos conforme o nível com o respectivo tipo de RAID específico. Por exemplo, para o RAID 5 (4+1), é necessário um conjunto de 10 discos em vez de um de sete discos. Cálculo baseado em capacidade Calcule os eixos dos discos com base na capacidade para cada nível com a seguinte fórmula: Capacidade total skew de capacidade para o nível Número de discos para o nível = Sobrecarga de capacidade de RAID Número de discos para o nível Capacidade total x skew de capacidade para o nível Sobrecarga de capacidade de RAID Projeto final Use o maior número para cada nível como o dimensionamento final para atender aos requisitos de desempenho e capacidade. Para obter detalhes sobre dimensionamento da classificação por níveis do FAST VP, consulte o Virtual Infrastructure for MS Applications enabled by Symmetrix VMAX and MS Hyper-V White Paper. Consideração sobre dimensionamento de banco de dados OLAP Para obter um desempenho de largura de banda previsível, a recomenda uma abordagem de componente básico considerando-se o seguinte: Largura de banda planejada Consumo de memória Número do CPU Dimensionamento do banco de dados Dimensionamento do banco de dados temporário Os princípios do projeto são os seguintes: Projetar tendo em vista a largura de banda e, em seguida, a capacidade do banco de dados. No caso de bancos de dados OLAP, para atingir o objetivo de concluir todas as consultas a fim de gerar relatórios pontuais, o projeto de armazenamento precisa cumprir a largura de banda necessária. Verificar o desempenho do disco. Para cargas de trabalho com I/O de somente leitura de grande porte sequencial (geralmente, 64 K ou mais), calcule a largura de banda para um determinado tamanho de I/O com a IOPS: Número de discos para o nível = Tamanho médio da I/O x IOPS de somente leitura para o Microsoft Exchange Server 34 34

35 Calcular o requisito de armazenamento de arquivos do banco de dados. Calcule o número de discos necessários para o desempenho da seguinte maneira: Largura de banda necessária Número de discos para o desempenho = Largura de banda por disco Calcule o número de discos necessários para a capacidade da seguinte maneira: Capacidade necessária Número de discos para capacidade = Sobrecarga de RAID para capacidade Arredonde para o próximo número de drives lógicos correspondente ao seu tipo de RAID específico para cada um dos cálculos acima. Para o armazenamento hierárquico, calcule as necessidades de armazenamento para a carga de trabalho OLTP com base no skew, conforme discutido em Práticas recomendadas para o dimensionamento do FAST VP. Usar a proporção 1:5 recomendada para o tamanho do banco de dados temporário. A recomenda um banco de dados temporário de 100 GB para cada arquivo de banco de dados de 500 GB em um ambiente OLAP. O tamanho real do banco de dados temporário depende do ambiente específico. Para obter detalhes sobre o projeto de componente básico OLTP, consulte Abordagem de projeto de componente básico para o data warehouse. Você também pode consultar o SQL SERVER 2012 DATA WAREHOUSE VNX5500 HB, VMware vsphere 5, Windows 2012 White Paper. Considerações sobre armazenamento de hipervisor Com a tecnologia de servidor atual reduzindo rapidamente o custo da capacidade de processamento, a maioria dos ambientes de servidores físicos se tornou subutilizada-, embora algumas funções devam ser localizadas em servidores separados para que os aplicativos do SQL Server funcionem corretamente. A virtualização pode otimizar os recursos do datacenter consolidando os recursos do servidor em poucos servidores físicos. Isso reduz o consumo de energia, economiza espaço, aumenta o retorno sobre o investimento, aumenta a capacidade de gerenciamento e apresenta novas opções de alta disponibilidade. O Windows SVVP (Server Virtualization Validation Program), que está disponível no site da Microsoft, especifica informações sobre o armazenamento compatível da para virtualização dos ambientes SQL Server. A virtualização de um ambiente SQL Server exige a adesão a algumas práticas recomendadas para um projeto de armazenamento exclusivo. Ao virtualizar um ambiente SQL Server hospedado em armazenamento da série Symmetrix VMAX ou da família VNX da, os clientes podem usar recursos como as ferramentas de migração em tempo real VMware vmotion e Microsoft Hyper-V. Esses recursos permitem a movimentação dos servidores virtuais entre diferentes plataformas de hardware de servidor sem interrupção dos aplicativos. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 35 35

36 Diretrizes gerais de virtualização Estas são as diretrizes gerais para aplicar a virtualização do Microsoft SQL Server: Siga os princípios gerais do projeto do SQL Server: Planeje o desempenho, a confiabilidade e a capacidade. Projete os perfis de usuário (como OLTP e OLAP). Dimensione as máquinas virtuais de acordo com a função do SQL Server (parte do SAP ou do SharePoint). O dimensionamento físico ainda é aplicável para calcular o número de discos ou o FAST VP. Recomendamos a instalação do PowerPath em hosts Hyper-V ou ESX físicos para balanceamento de carga, gerenciamento de caminho e detecção de falha de caminho de I/O. Consideração sobre recursos do sistema de máquinas virtuais: Dimensione os servidores físicos para acomodar o número de guests. Mantenha o número de núcleos físicos e vcpus em uma relação de 1:1. Certifique-se de que não existam CPUs superalocadas. Não exceda o tamanho do nó NUMA no servidor físico ao dimensionar máquinas virtuais. Para obter detalhes, consulte Usando Sistemas NUMA com ESX/ESXi. Reserve totalmente a RAM para as máquinas virtuais SQL Server para evitar o ballooning da memória. Entenda os limites do supervisor (Hyper-V e VMware): Memória máxima: 1 TB (ESXi 5.1, Windows 2012 Hyper-V) LUNs SCSI por máquina virtual: 256 (ESXi 5.1, Windows 2012 Hyper-V) Limites de processador VMware vsphere 5.1: 32 vcpus Windows 2012 Hyper-V: 64 vcpus Use páginas grandes no guest (inicie o SQL Server com uma marca de trilha T834) para um SQL Server de 64 bits, dedicado, para melhorar o desempenho. Ative os privilégios Bloquear páginas na memória para a conta de serviços do SQL Server. Considerações sobre AlwaysOn Availability Groups: Distribua as cópias dos AlwaysOn Availability Groups entre vários hosts físicos para minimizar o possível tempo de inatividade em caso de problemas no servidor físico. Se as máquinas virtuais do SQL Server em um AlwaysOn Availability Group fizerem parte de uma tecnologia de migração e clustering de failover baseado em host de hipervisor, configure as máquinas virtuais para não salvar/restaurar seu estado no disco quando movidas ou colocadas em off-line. Suporte da VMware para clusters do SQL Server para o Microsoft Exchange Server 36 36

37 Há limitações em relação aos clusterings FCI e AAG para VMware coforme indicado na Tabela 10. Tabela 10. Limitações da VMware para clusters do Microsoft SQL Server Recurso Disco compartilhado Disco não compartilhado Clustering da Microsoft em VMware MSCS com disco compartilhado Clustering do SQL SQL AlwaysOn Clustering de failover instância Balanceamento da carga de rede SQL AlwaysOn Disponibilidade Grupo Suporte ao vsphere Sim Sim Sim Sim Sim Suporte a VMware HA Sim 1 Sim 1 Sim 1 Sim 1 Sim 1 Suporte a vmotion DRS não não não Sim Sim Suporte ao Storage vmotion não não não Sim Sim Limites de nós MSCS 2 (5.1) 5 ( 5.5) 2 (5.1) 5 (5.5) 2 (5.1) 5 (5.5) O mesmo que SO/ap O mesmo que SO/ap Suporte a protocolos de armazenamento FC Sim Sim Sim Sim Sim In-guest OS iscsi Nativo iscsi Sim Sim Sim Sim Sim Sim 2 Sim 2 Sim 2 Sim Sim In-Guest OS SMB Sim 3 Sim 3 Sim 3 N/D N/D Disco compartilhado FCoE Sim 4 Sim 4 Sim 4 Sim Sim RDM Sim Sim Sim N/D N/D VMFS Sim 5 Sim 5 Sim 5 N/D N/D Para obter mais detalhes sobre limitações da VMware com a Microsoft, consulte a Base de conhecimento da VMware. Consideração sobre HA/DR: Desative as tecnologias de migração que salvam e migram o estado. Sempre migre máquinas virtuais ativadas ou completamente desligadas. Desative os recursos de ajuste automático baseados no hipervisor. 1 Quando regras de afinidade/antiafinidade DRS são usadas. 2 Somente vsphere Somente clustering de failover do Windows Server No vsphere 5.5, FCoE nativo é aceito. No vsphere 5.1 Update 1 e 5.0 Update 3, a configuração de cluster de dois nós com placas Cisco CNA (VIC 1240/1280) e driver versão é aceita no SO Guest de 64 bits do Windows 2008 R2 SP1. Para obter mais informações, consulte o guia de compatibilidade do hardware VMware: Cisco UCS VIC1240, Cisco UCS VIC Aceito apenas em configurações CIB (Cluster in a Box). Para obter mais informações, consulte a seção Considerações sobre clustering de armazenamento compartilhado deste artigo. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 37 37

38 Para obter o desempenho ideal com instâncias essenciais do SQL Server de Nível 1: Siga as mesmas diretrizes válidas para um ambiente físico, LUNs separadas para dados e registros. Garanta que cada servidor ESXi ou Hyper-V tenha, pelo menos, quatro caminhos (dois HBAs) para o armazenamento, com um total de quatro portas. Garanta que a conectividade com o storage array seja fornecida aos dois SPs para VNX ou em vários directors de front-end no VMAX. Coloque o armazenamento do SQL Server em discos separados do armazenamento físico do SO guest (VHD/VHDX ou VMDK). Para obter um desempenho aceitável com instâncias de nível de serviço de Nível 2 ou inferiores: Drives de disco rígido virtuais para LUNs de SO de VM poderão compartilhar uma LUN no nível do hipervisor (datastore para vsphere ou LUNs de nível do host para VHD/ VHDX no Hyper-V) com LUNs de registro e banco de dados SQL Server se a facilidade de implementação for a principal preocupação e o desempenho for secundário. Várias máquinas virtuais ou bancos de dados poderão compartilhar LUNs no nível do hipervisor (datastore para vsphere ou LUNs no nível do host para VHD/ VHDX no Hyper-V) se o nível de HA/DR for aceitável para o ambiente específico. A Microsoft dá outras informações e recomendações para a virtualização do SQL Server. Práticas recomendadas para o ambiente VMware vsphere Estas são algumas das práticas recomendadas gerais para implementar o SQL Server em um ambiente virtual VMware VSphere: Implemente máquinas virtuais de aplicativos em armazenamento compartilhado. Isso permite o uso dos recursos do vsphere como vmotion, HA e DRS. Crie sistemas de arquivos VMFS do vcenter para garantir o alinhamento de partições. Acrescente cerca de 5% de requisitos de CPU para sobrecarga do hipervisor. Ao usar VMFS para armazenamento de dados, formate arquivos VMDK como eagerzeroedthick (principalmente para arquivos de registro e banco de dados.) Use vários adaptadores PVSCSI e distribua os dispositivos de destino de maneira uniforme. Os adaptadores PVSCSI (Paravirtual SCSI) da VMware são drivers de armazenamento de alto desempenho que podem melhorar o throughput e reduzir o uso da CPU. Os adaptadores PVSCSI são mais adequados para ambientes SAN, nos quais hardware ou aplicativos geram alto throughput de I/O. A Figura 5 A mostra que o tipo de controlador SCSI foi alterado para Paravirtual para aumentar a eficiência do driver. O driver de controladora SCSI padrão é o LSI Logic SAS. As LUNs são distribuídas por todos os drivers SCSI. para o Microsoft Exchange Server 38 38

39 Figura 5. Controladoras SCSI Aumente a profundidade da fila de HBA no servidor ESXi para melhorar o throughput de placas HBA em servidores ESXi. Observamos um benefício em configurar a profundidade da fila do HBA como 64 (o padrão é 32 no ESXi 5.0 e 64 no ESXi 5.1). Os resultados podem variar em ambientes específicos. Notas: A maior profundidade de fila configurável para as portas HBA no ESXi 5.0 é 128 e no ESXi 5.1 é 256, se as LUNs associadas tiverem portas de servidor ESXi dedicadas. Para servidores ESXi 5.0 com várias máquinas virtuais, o valor de Disk.SchedNumReqOutstanding nas opções avançadas da VMware precisa corresponder à profundidade da fila. Para obter mais informações sobre a configuração do servidor ESXi, consulte o site da Base de conhecimento da VMware e o manual de desempenho do armazenamento dimensionável VMware ESX. VMFS versus RDM VMFS e RDM, geralmente, têm desempenho similar, com o RDM proporcionando um desempenho um pouco melhor. O VMFS pode ser usado na maioria dos ambientes, a menos que haja um requisito específico para clustering e replicação de snapshot. Consulte o site da VMware para obter detalhes. A Tabela 11 compara VMFS e RDM no ambiente da VMware para SQL Server. Tabela 11. VMFS versus RDM VMFS Melhor consolidação de armazenamento vários discos e máquinas virtuais por LUN VMFS; mas ainda dá suporte a uma máquina virtual por LUN Consolidação de máquinas virtuais em LUNs menor probabilidade de atingir o limite de LUN ESX de 255 Gerenciamento do desempenho: a IOPS combinada de todas as máquinas virtuais na LUN é inferior à classificação de IOPS da LUN Tamanho limitado da LUN (2 TB para o vsphere 5.1 e 62 TB para o vsphere 5.5) RDM Reforça o mapeamento 1:1 entre máquina virtual e LUN Maior probabilidade de atingir o limite de LUN ESX de 255 Não afetada pela IOPS de outras máquinas virtuais Tamanho ilimitado da LUN Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 39 39

40 VMFS Funciona bem para a maioria dos ambientes que não exigem RDM (Raw Device Mapping) RDM Necessário para clustering (disco de quorum); por exemplo, Clustering de Failover do SQL Necessário para tarefas de gerenciamento SAN, como backup e snapshots Microsoft Hyper-V Opções de armazenamento para SQL Server VHDX é o novo formato de disco rígido virtual introduzido no Windows Server 2012 Hyper-V; ele fornece maior capacidade de armazenamento e proteção de dados. VHD, o disco rígido virtual Windows Server 2008 Hyper-V, pode ser convertido em VHDX no Windows Server 2012 Hyper-V. Os arquivos de registro e banco de dados SQL Server podem residir em VHD ou VHDX. O VHDX pode ser criado em um CSV (Cluster Shared Volume) para tirar proveito dos recursos HA/DR fornecidos pelo Hyper-V. CSV é um recurso do clustering de failover, que foi introduzido no Windows Server 2008 R2 para uso com o Hyper-V. CSV é um disco compartilhado que contém um volume NTFS (NT File System) que é um volume acessível para operações de leitura e gravação a todos os nós em um cluster de failover do Windows Server. O disco PassThrough pode ignorar a camada de hipervisor e maximizar o desempenho dos discos subjacentes. NPIV (Virtualização de ID N_Port) é um recurso Fibre Channel virtual do Hyper-V introduzido no Windows Ele permite a conexão com o armazenamento Fibre Channel de uma máquina virtual. Com o NPIV, as cargas de trabalho virtualizadas podem usar investimentos existentes em Fiber Channel. Ele também dá suporte a muitos recursos relacionados, como SANs virtuais, migração em tempo real e MPIO (Multipath I/O). Esse recurso proporciona um desempenho de discos quase pass-through com proteção de nível do Hyper-V e migração fácil. O Virtual Fibre Channel para Hyper-V fornece o melhor sistema operacional guest com acesso direto a uma SAN usando um WWN (World Wide Name) padrão associado a uma máquina virtual. Os usuários do Hyper-V agora podem usar SANs Fibre Channel para virtualizar cargas de trabalho que requerem acesso direto a LUNs de SAN. As SANs Fibre Channel também permitem operar em novos cenários, como executar o recurso Clustering de Failover no sistema operacional guest de uma máquina virtual conectada ao armazenamento Fibre Channel compartilhado. Os storage arrays da oferecem recursos avançados de armazenamento que ajudam a transmitir determinadas tarefas de gerenciamento dos hosts para as SANs. O Virtual Fibre Channel apresenta um caminho de I/O alternativo, baseado em hardware, para a pilha de discos virtuais do software Windows. Isso permite usar recursos avançados, como snapshots de hardware, diretamente de máquinas virtuais Hyper-V. Para obter detalhes sobre o Virtual Fibre Channel do Hyper-V, consulte a Microsoft TechNet. para o Microsoft Exchange Server 40 40

41 Considerações sobre armazenamento de clustering do SQL Server O AAG (AlwaysOn Availability Groups, grupos de disponibilidade AlwaysOn), um recurso de alta disponibilidade e recuperação de desastres introduzido no SQL Server 2012, requer o WSFC (Windows Server Failover Clustering). Os AlwaysOn Availability Groups não dependem de uma FCI (Failover Clustering Instance) do SQL Server. Em uma FCI (Failover Clustering Instance) do SQL Server, os arquivos de registro e banco de dados SQL Server são compartilhados entre todos os nós do cluster, portanto, as LUNs de armazenamento que hospedam esses arquivos precisam estar acessíveis a todos os nós. Isso significa que todas as LUNs precisam ser configuradas e zoneadas para todos os nós do cluster simultaneamente. As LUNs de registro/banco de dados específicas só podem ser acessadas do nó que estiver executando ativamente a instância do SQL Server. Embora cópias primárias e secundárias dos bancos de dados não estejam compartilhando o armazenamento em AAGs (AlwaysOn Availability Groups, grupos de disponibilidade AlwaysOn), cada nó do cluster precisa ter seu próprio armazenamento configurado e zoneado para ele. A cópia do banco de dados no nó secundário de um AlwaysOn Availability Group poderá ser acessada se for configurada como cópia legível,, que é independente da cópia primária. Isso pode ser usado para habilitar a capacidade de geração de relatórios na cópia secundária para transmissão da cópia primária. A Figura 6 mostra a diferença entre FCI e AAG. Figura 6. FCI versus AAG As limitações do suporte de clustering do SQL Server em um ambiente VMware são detalhadas em Tabela 10. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 41 41

42 Diretrizes sobre projeto de armazenamento Symmetrix VMAX A série Symmetrix VMAX da é armazenamento high-end para o datacenter. O sistema pode ser dimensionado para enormes 2 PB e consolida mais cargas de trabalho em um espaço físico muito menor em comparação a outros arrays. A Arquitetura Symmetrix Virtual Matrix da dimensiona perfeitamente o desempenho, a capacidade e a conectividade sob demanda para atender a todos os requisitos dos aplicativos. O sistema aceita flash drives, Fibre Channel e SATA, além de classificação automatizada por níveis otimizada com FAST VP. O sistema também aceita servidores físicos e virtualizados, inclusive sistemas abertos, mainframes e servidores IBM. Considerações sobre projeto de hardware da série VMAX Algumas das mais importantes considerações sobre projeto para SQL Server em VMAX estão listadas abaixo: Ao criar LUNs, use menos hipervolumes, mas de tamanho maior, para melhorar o desempenho. Use, no mínimo, dois HBAs por servidor, com cada HBA conectado a, pelo menos, duas portas de director (em vários mecanismos VMAX, se possível). Para thick e thin-luns, use metavolumes fracionados. Considerações e práticas recomendadas sobre provisionamento virtual Com os recursos de formatação NTFS "compatível com thin" do Microsoft Windows e mecanismos de Instant File Initialization do Microsoft SQL Server, o SQL Server pode proporcionar o máximo de benefícios do provisionamento virtual com o Symmetrix. Dessa forma, os pools de thin-luns são recomendados para o SQL Server no Symmetrix VMAX. O desempenho de dispositivos thin é equivalente ao desempenho de dispositivos regulares (thick) no VMAX e, na maioria dos casos, o uso de thin-pools pode reduzir o requisito de armazenamento inicial. Veja a seguir um resumo das práticas recomendadas ao configurar o Microsoft SQL Server com provisionamento virtual no Symmetrix VMAX: Use o provisionamento virtual quando a superalocação do sistema de armazenamento for típica. Use provisionamento virtual se esperar um rápido crescimento no decorrer dos anos, mas com um tempo de inatividade limitado. Configure bancos de dados SQL Server com Instant File Initialization (esse é o padrão para o SQL Server 2012). Considere usar a ferramenta de limite de utilização de thin-pool para monitorar os thin-pools e evitar que eles fiquem sem espaço. Evite o provisionamento virtual para os seguintes ambientes: Sistemas onde alocações compartilhadas de um pool comum de dispositivos thin não atendem aos requisitos do cliente. Sistemas onde não é possível recuperar grandes quantidades de espaço excluído. Sistemas que não podem tolerar um aumento no tempo de resposta ocasional de cerca de 1 milissegundo de gravações em blocos não inicializados. para o Microsoft Exchange Server 42 42

43 Considerações e melhores práticas do FAST VP para um sistema de armazenamento VMAX O FAST VP proporciona ao SQL Server uma administração reduzida e uma resolução mais rápida de problemas de I/O e espaço. Principalmente com cargas de trabalho OLTP, o FAST VP proporciona um uso eficiente do armazenamento e transfere os dados acessados com mais frequência para o nível de desempenho mais elevado. Estas são algumas considerações e práticas recomendadas ao usar o FAST VP: Evite colocar LUNs de registro em um nível flash porque os registros geram, na maior parte, gravações sequenciais e não se beneficiarão de um dispositivo flash. Associe as LUNs do banco de dados ao nível FC para começar com o FAST VP e forneça armazenamento suficiente para ajustar a capacidade se os dados do host precisarem ser transferidos para o nível superior. Ao usar FAST VP com AlwaysOn Availability Groups, coloque cópias do grupo de disponibilidade do mesmo banco de dados em pools diferentes para obter uma melhor disponibilidade. Os registros podem ser fixados em um nível específico quando colocados no mesmo pool de armazenamento com LUNs de arquivos de dados. Execute o dimensionamento de acordo com as Práticas recomendadas para o dimensionamento do FAST VP. Obs.: as proporções de skew podem variar e dependem do perfil específico do SQL Server. Diretrizes sobre projeto de armazenamento VNX A família VNX oferece inovação e recursos corporativos líderes do setor para armazenamento de file e block em uma solução dimensionável e fácil de usar. Essa plataforma de armazenamento de última geração combina hardware sofisticado e flexível com software avançado de eficiência, gerenciamento e proteção para suprir as demandas das empresas da atualidade. A família VNX inclui a série VNXe, desenvolvida especificamente para o gerente de TI em ambientes iniciais, e a série VNX, projetada para atender aos requisitos de alto desempenho e alta capacidade de expansão de empresas de médio e grande porte. A Suíte FAST é um recurso de software avançado que fornece maior flexibilidade para gerenciar o aumento dos requisitos de desempenho e capacidade do ambiente SQL Server. A Suíte FAST faz uso de drives SSD, SAS e configuração de armazenamento NL-SAS para equilibrar as necessidades de desempenho e armazenamento. A Suíte FAST inclui FAST Cache e FAST VP. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 43 43

44 A Suíte Application Protection automatiza cópias consistentes com aplicativos e permite restaurar para níveis de serviço definidos. As funções de usuário habilitam o gerenciamento de cópias com autoatendimento, ao mesmo tempo em que melhoram a visibilidade dos pontos de recuperação de todos os aplicativos. Os alertas são gerados automaticamente, proporcionando uma resolução rápida das lacunas de recuperação. A geração de relatórios integrada pode comprovar conformidade com as políticas de proteção. Os aplicativos compatíveis abrangem Oracle; Microsoft SQL Server, SQL Server, SharePoint, VMware e Hyper-V. A Suíte Application Protection abrange: Para a série VNX: Replication Manager, AppSync e Data Protection Advisor for Replication Analysis Para a série VNXe: Replication Manager Considerações e práticas recomendadas para FAST Cache O FAST Cache aumenta o cache do sistema de armazenamento ampliando a funcionalidade do DRAM cache, associando dados acessados com frequência ao SSD. Os recursos do FAST Cache variam de 73 GB a 2 TB, o que é consideravelmente maior do que o cache DRAM disponível dos sistemas de armazenamento existentes. Se um segmento de dados específico for acessado com frequência pelo aplicativo do usuário, esse fragmento será automaticamente promovido para o FAST Cache, que o copia dos drives de disco rígido nos flash drives. O acesso subsequente ao mesmo fragmento é efetuado nos tempos de resposta do flash drive, impulsionando, dessa forma, o desempenho do sistema de armazenamento. O FAST Cache é mais adequado para cargas de trabalho aleatórias com uso intenso de I/O. Um banco de dados OLTP típico com esse tipo de perfil pode se beneficiar intensamente do FAST Cache para melhorar o desempenho e o tempo de resposta. Monitore os grupos de arquivos do banco de dados SQL Server e habilite o FAST Cache nos pools de armazenamento altamente ativos onde esses dados estão localizados. O FAST Cache: uma Análise Detalhada, disponível no site de Suporte on-line da, fornece mais detalhes sobre conceitos do projeto do FAST Cache, planejamento e diretrizes de uso. Os testes sugerem que a inclusão do FAST Cache resulta em um aumento de 300% das TPS (Transactions per Second, transações por segundo) para uma carga de trabalho SQL OLTP usando o mesmo número de drives de disco rígido no back-end. O Unified Storage para Microsoft SQL Server 2008: Habilitado pela Arquitetura de Referência do CLARiiON e do FAST Cache, disponível no site de Suporte on-line da, fornece mais detalhes sobre como criar uma solução com o FAST Cache. Ao usar o FAST Cache, aguarde tempo suficiente para que o cache se aqueça, a fim de utilizar integralmente o cache. Em nossos testes com cargas de trabalho OLTP, o FAST Cache levou cerca de 1 a 2 horas para se aquecer. O tempo de aquecimento depende do tipo e da quantidade de drives de disco rígido de back-end, do tamanho do FAST Cache e do tamanho do conjunto de trabalho. O Unisphere tem vários contadores do FAST Cache que você pode monitorar para obter a utilização e o tempo de aquecimento ideais. O CLARiiON, Celerra Unified, and VNX FAST Cache White Paper, disponível no site brazil.emc.com, oferece mais informações. para o Microsoft Exchange Server 44 44

45 Considerações e práticas recomendadas para FAST VP De acordo com os analistas do setor, 60% a 80% dos dados de um banco de dados operacional são inativos e aumentam com tamanho do banco de dados. Drives de rotação de alta capacidade e baixo custo são a escolha ideal para dados inativos, enquanto os drives de alto desempenho são adequados para dados acessados com frequência. A classificação e o armazenamento manuais dos dados no nível correto é uma tarefa complexa e desafiadora e, geralmente, requer tempo de inatividade para mover os dados. O FAST VP move, automaticamente, dados acessados com frequência para um armazenamento físico mais rápido de um pool e transfere os dados usados com menos frequência para um armazenamento físico menos caro. Usando o FAST VP, você pode: Controlar quando o FAST VP pode mover os dados para impedir o impacto nas solicitações de I/O do host durante períodos conhecidos de alto uso do sistema. Melhorar o desempenho geral do sistema sem investir em drives físicos de alto desempenho adicionais. Aplicar o FAST VP a qualquer ou a todas as LUNs de banco de dados baseadas em pool em um sistema de armazenamento. Se as LUNS de registro precisarem estar no mesmo pool de LUNs do banco de dados, fixe-as no nível de SAS e desative a realocação de dados para essas LUNs. Em uma carga de trabalho OLTP, fixe o banco de dados temporário no nível de SAS e desative a realocação de dados para essas LUNs. Defina a política FAST como Start High then Auto Tier (padrão). Noções Básicas sobre a Caracterização do Desempenho do OLTP do Microsoft SQL Server para a Série VNX da, disponível no site de Suporte on-line da, fornece mais detalhes sobre o uso do FAST VP com SQL Server. O FAST VP opera em segundo plano, enquanto as LUNs estão on-line e disponíveis para acesso de host. A velocidade de movimentação dos dados pode ser controlada para minimizar o impacto no desempenho geral do sistema (você pode configurar a taxa de realocação como alta, média ou baixa). FAST Cache versus FAST VP O FAST Cache impulsiona imediatamente o desempenho para padrões de acesso aleatório e dados de pico, enquanto o FAST VP permite que o sistema de armazenamento mova dados inativos para um nível de armazenamento de custo mais baixo. O FAST Cache opera em unidades de 64 KB, enquanto o FAST VP opera em fragmentos de 1 GB. O FAST VP pode promover metadados thin e os dados de usuário mais acessados para o nível mais alto, enquanto o FAST Cache promove os metadados para melhorar o desempenho das thin-luns. O FAST Cache e o FAST VP podem funcionar juntos em um banco de dados SQL Server para melhorar o desempenho, obter uma utilização mais elevada da capacidade e reduzir os requisitos de energia e resfriamento. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 45 45

46 Estas são as práticas recomendadas ao usar o FAST Cache e o FAST VP: Quando um número limitado de Flash drives estiver disponível, use flash drives para criar o FAST Cache primeiro. O FAST Cache é global e pode beneficiar vários pools no sistema de armazenamento. O FAST Cache usa fragmentos de 64 KB, enquanto o FAST VP usa fragmentos de 1 GB, o que resulta em benefícios de melhor desempenho e menor tempo de reação para alterações nos padrões de uso. Use flash drives para criar um nível de desempenho do FAST VP para um pool específico para garantir o desempenho dos dados de missão crítica. O nível do FAST VP é dedicado a um pool de armazenamento e não é compartilhado com outros pools de armazenamento no mesmo storage array. Considerações sobre server flash Visão geral do XtremSF O XtremSF é uma placa de hardware discreta de server flash que se encaixa em qualquer servidor montado em rack dentro do envelope de alimentação de um só slot PCIe, disponível com um amplo conjunto de recursos emlc e SLC. Ele pode ser implementado: Como armazenamento local que se encaixa no servidor para oferecer alto desempenho Em combinação com o software de armazenamento em cache no servidor XtremSW Cache a fim de melhorar o desempenho do storage array em rede, mantendo, ao mesmo tempo, o nível de proteção exigido por ambientes de aplicativos críticos Práticas recomendadas de projeto do XtremSF O SLC e o MLC NAND XtremSF oferecem recursos que atendem a diferentes tipos de aplicativos os que requerem alto desempenho a um custo por bit atraente (MLC) e os que são menos sensíveis aos custos e buscam um desempenho melhor com o tempo (SLC). Em um data warehouse de alta demanda ou um ambiente OLAP e, às vezes, em um ambiente OLTP onde o banco de dados temporário é muito utilizado, o XtremSF pode ser usado como armazenamento de banco de dados temporário para reduzir a contenção desse banco e, dessa maneira, melhorar a largura de banda. O XtremSF é mais adequado para bancos de dados SQL Server com uma proporção de leitura/gravação de 70% a 90% e com proteção de dados no nível do SQL Server. Com placas maiores do XtremSF, é possível encaixar um banco de dados inteiro em uma placa do XtremSF. Os casos de uso que podem se beneficiar do XtremSF local estão detalhados no XtremSF Performance Acceleration for Microsoft SQL Server 2012 White Paper. para o Microsoft Exchange Server 46 46

47 Visão geral do XtremSW Cache O XtremSW Cache é o software de armazenamento em cache de servidor da para placas flash PCIe que preenche o XtremSF com dados a fim de usá-lo como um cache. O XtremSW Cache foi projetado para seguir estes princípios básicos: Desempenho: reduza a latência e aumente o throughput para melhorar drasticamente o desempenho do aplicativo. Inteligência: adicione outro nível de inteligência estendendo a tecnologia FAST baseada em array para o servidor. Proteção: ofereça desempenho com proteção usando a alta disponibilidade e a recuperação de desastres do armazenamento em rede da. As cargas de trabalho do SQL Server que mais podem se beneficiar do XtremSW Cache são: Aplicativos que têm altas proporções de carga de trabalho de leitura-paragravação. A eficácia máxima é obtida quando os mesmos fragmentos de dados são lidos muitas vezes e raramente gravados. Os aplicativos com um reduzido conjunto de trabalho, que recebem o impulso máximo possível. Aplicativos com cargas de trabalho de leitura predominantemente aleatórias. Cargas de trabalho sequenciais que tendem a ter um conjunto de dados ativo significativamente maior (como data warehousing) em proporção ao tamanho do XtremSW Cache disponível se beneficiam pouco do XtremSW Cache. Aplicativos com um alto grau de simultaneidade de I/O (ou seja, vários threads de I/O). Aplicativos com tamanhos menores de I/O (8 KB ou menos), mas que geram tamanhos de I/O grandes. O software XtremSW Cache permite que você ajuste recursos, como o tamanho da página e os tamanhos máximos de I/O, o que ajuda muito nesses ambientes a acelerar I/Os específicas e ignorar outras I/Os (como I/Os de leitura de backup). O XtremSW Cache pode acelerar operações de leitura, enquanto todas as operações de gravação são gravadas no storage array e não são afetadas pelo XtremSW Cache. Em muitos casos, é possível observar aprimoramento no desempenho do throughput de gravação à medida que o XtremSW Cache descarrega as operações de leitura, permitindo que o array manipule mais operações de gravação como um benefício secundário. O XtremSW Cache pode não ser adequado para aplicativos sequenciais ou com muita atividade de gravação, como data warehousing, mídia de fluxo contínuo ou aplicativos de big data. Para resumir, você pode usar o XtremSF como o armazenamento local para aceleração das leituras e das gravações, dados temporários e grandes conjuntos de trabalho, enquanto o XtremSF com XtremSW Cache pode ser usado para a aceleração das leituras de dados essenciais com reduzidos conjuntos de trabalho que requerem proteção de dados. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 47 47

48 Práticas recomendadas de projeto do XtremSW Cache Ao trabalhar na configuração de armazenamento básico, determine qual SQL Server precisa da aceleração do XtremSW Cache. Em um ambiente SQL Server OLTP típico: Use o XtremSF com XtremSW Cache para aceleração de leituras de dados essenciais com conjuntos de trabalho reduzidos o suficiente para se encaixarem no cache. Use XtremSW Cache Performance Predictor para a análise de benefícios inicial do SQL Server com XtremSW Cache. As LUNs dos arquivos de dados de banco de dados, que apresentam atividades intensas de leitura, geralmente têm uma carga de trabalho intensa, sujeita a um skew de leitura elevado, e são boas candidatas para o XtremSW Cache. Os arquivos de dados do SQL Server OLTP apresentam leituras aleatórias constantes e contribuem para a duração geral dos tempos de transação. Os arquivos de dados também apresentam picos regulares de atividade de gravação durante uma operação de checkpoint. Ao usar o XtremSW Cache para armazenar leituras em cache e evitar uma carga de trabalho de I/O no array da, você possibilita que o array consuma picos de gravação com mais rapidez e evita atrasos de leitura nas transações. As LUNs de registro e banco de dados temporário em bancos de dados OLTP apresentam atividades intensas de gravação e normalmente não se beneficiam do XtremSW Cache. Em ambientes SQL Server AlwaysOn, os bancos de dados secundários não precisam ser acelerados, a menos que um requisito de desempenho específico justifique o uso do XtremSW Cache. Defina o tamanho da página como 64 KB no XtremSW Cache para acomodar a I/O elevada para o banco de dados SQL Server. Se não houver expectativa de aumento da carga de trabalho após a implementação do XtremSW, não haverá necessidade de recursos adicionais do sistema, como memória ou CPU. Quando a redundância for necessária, coloque, pelo menos, duas placas XtremSF na infraestrutura de servidores. Em geral, a desduplicação não traz benefícios para o padrão de I/O do SQL Server. Práticas recomendadas de projeto do XtremSW Cache em um ambiente virtualizado Estas são algumas das práticas recomendadas relativas ao XtremSW Cache em um ambiente virtualizado: Quando a redundância for necessária, coloque, pelo menos, duas placas XtremSF na infraestrutura de servidores de hipervisor. Se o vmotion for necessário, calcule a capacidade e o posicionamento do XtremSF de maneira que a capacidade restante do XtremSF e dos servidores ainda possa atender às configurações do XtremSW Cache de todas as máquinas virtuais durante a execução do vmotion. para o Microsoft Exchange Server 48 48

49 Por exemplo, se 10 máquinas virtuais forem configuradas para usar 100 GB do XtremSW Cache, o que requer um total de 1 TB de capacidade do XtremSW Cache, durante a execução do vmotion, os servidores restantes no cluster virtualizado com o XtremSW Cache devem viabilizar, pelo menos, 1 TB de espaço no cache. Se os aplicativos precisarem apenas de uma pequena parte da capacidade da placa XtremSF para cada máquina virtual, as máquinas virtuais com esses aplicativos poderão compartilhar a mesma placa física, e o melhor posicionamento para elas é no mesmo host ESXi ou Hyper-V. Nos casos em que um determinado aplicativo exija toda a capacidade disponível da placa XtremSF, o host deverá dedicar essa placa específica à máquina virtual. É possível instalar várias placas XtremSF no mesmo servidor, se necessário. Várias placas XtremSF podem ser configuradas para o mesmo hipervisor a fim de criar vários dispositivos de cache para a máquina virtual. Para cargas de trabalho de aplicativos específicas, selecionadas para usar o recurso split-card, parte da placa pode ser configurada para atender a necessidades de armazenamento em cache da máquina virtual; a outra parte pode ser configurada como armazenamento XtremSF para atender à necessidade de um datastore temporário, como espaço de armazenamento do banco de dados temporário. Para essa configuração, são necessárias outras considerações de portabilidade da máquina virtual no ambiente virtualizado, pois agora a máquina virtual depende do armazenamento local para o servidor em questão. O tamanho mínimo do XtremSW Cache vdisk é 20 GB para qualquer máquina virtual que precise de aceleração de cache flash. Colocar apenas os VHDXs que requerem aceleração do XtremSW Cache nas LUNs configuradas com o XtremSW Cache. Todos os VHDXs na LUN configurada com o XtremSW Cache serão acelerados. Considerações sobre dimensionamento do XtremSF e do XtremSW Cache Recomendações sobre dimensionamento estão disponíveis para cada tipo de aplicativo. Os ambientes são diferentes, portanto também são as implementações. As configurações a seguir são as mínimas recomendadas para cada aplicativo, com base em nossos testes em uma carga de trabalho de banco de dados e aplicativos típica. Na maioria dos casos, a inclusão de mais placas XtremSW Cache proporciona um melhor desempenho até o tamanho do cache se equiparar ou superar o tamanho do conjunto de trabalho. Para determinar o tamanho ideal para um aplicativo e um ambiente específicos, considere o nível de desempenho necessário e o custo. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 49 49

50 A Tabela 12 faz recomendações sobre o XtremSW Cache para cada aplicativo. A proporção entre cache e armazenamento 6 depende, em grande parte, do conjunto de trabalho ativo do banco de dados e será alterada com base no uso real. Essas recomendações são baseadas em nossos testes realizados em um ambiente controlado. Seu ambiente pode ser diferente, portanto, use os números fornecidos como diretriz. Tabela 12. Cache recomendado para cada aplicativo Aplicativo Tipo de banco de dados Proporção leiturapara-gravação SQL Server OLTP 90:10 1:10 SQL Server OLTP 70:30 1:5 Relação do XtremSW Cache/armazenamento recomendada SharePoint Conteúdo/ localização 100% de leitura 1:5 SQL Server OLAP 100% de leitura 1:5 (banco de dados temporário no XtremSF: tamanho do banco de dados) Para aplicativos SQL Server OLAP, como um ambiente de data warehouse, o emlc XtremSF (autônomo ou no modo split-card) pode ser usado como o banco de dados temporário para aprimorar o desempenho das consultas. Considere, pelo menos, 200 GB de espaço de banco de dados temporário para cada 1 TB de espaço do banco de dados. Para obter detalhes de todas as práticas recomendadas de projeto e configuração relativas ao XtremSF e ao XtremSW Cache, consulte o Guia do Projeto do VSPEX com XtremSF e XtremSW Cache. Esse documento é para VSPEX, mas os princípios do projeto e as práticas recomendadas se aplicam à maioria dos ambientes. Automação com ESI O ESI ( Storage Integrator) para Windows Suite é um conjunto de ferramentas para o Microsoft Windows e os administradores de aplicativos Microsoft. A suíte inclui o ESI para Windows, o ESI PowerShell Toolkit, o ESI Service, o ESI Management Packs para SCOM (System Center Operations Manager) e o ESI Service PowerShell Toolkit. ESI para Windows Fornece a capacidade de visualizar, provisionar, monitorar e gerenciar o armazenamento de block e file para o Microsoft Windows. O ESI dá suporte às séries Symmetrix VMAX e VNX da. O ESI também é compatível com o provisionamento de armazenamento e a detecção de máquinas virtuais Windows em execução no Microsoft Hyper-V, no Citrix XenServer e no VMware vsphere. 6 A relação do XtremSW Cache/armazenamento é a relação entre o cache e o tamanho do armazenamento do banco de dados. Se a relação for de 1:10, então, para cada 10 GB de dados, forneça, pelo menos, 1 GB de XtremSW Cache. para o Microsoft Exchange Server 50 50

51 Conforme mostrado na Figura 7, o ESI simplifica o gerenciamento do armazenamento para Windows e aplica, automaticamente, algumas práticas recomendadas com configuração de armazenamento, simplificando, dessa forma, a implementação do armazenamento para Windows. Figura 7. ESI para gerenciamento de armazenamento do Windows ESI Management Packs para Systems Center Operations Manager 2012 Ative o gerenciamento de infraestrutura de armazenamento em uma só interface do usuário. Com a integração com o SCOM 2012, os administradores do Windows podem detectar ativos de armazenamento, mapear objetos físicos e lógicos, gerenciar alertas e abranger estados de integridade, com parâmetros configuráveis no System Center PSToolkit (PowerShell Toolkit) É um utilitário avançado, projetado para administradores e usuários do Windows para ajudar no gerenciamento de sistemas de armazenamento. Os cmdlets do PSToolkit permitem que os administradores do sistema obtenham informações do sistema de armazenamento, criem ou excluam pools, grupos e volumes de armazenamento e permitem também que eles os mapeiem e os associem aos servidores host disponíveis. Esse toolkit permite que os administradores criem, com eficiência, scripts automatizados para criação e exclusão dinâmicas das máquinas virtuais, conforme necessário aos usuários. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 51 51

52 Proteção do SQL Server Visão geral A Microsoft aprimorou seus recursos de alta disponibilidade e proteção de dados nativos do SQL Server no nível do banco de dados para o SQL Server 2012, introduzido o recurso AlwaysOn Availability Groups. A oferece uma série de produtos e opções de proteção de dados que complementam o AG e podem ajudar a proteger ainda mais seu ambiente do SQL Server contra a perda de um banco de dados, servidor ou um local completo. Várias opções de recuperação de desastres e alta disponibilidade do SQL Server 2012 são descritas nesta seção. Os sistemas de armazenamento da oferecem uma grande variedade de recursos para proteção e alta disponibilidade do SQL Server. As tecnologias de replicação da, como snapshots/clones do TimeFinder, do SRDF e do VNX, fornecem a melhor proteção de dados do setor. O RecoverPoint com proteção contínua e ferramentas de gerenciamento de replicação, como o AppSync e o Replication Manager, fornecem proteção para o SQL Server no nível do aplicativo. Você pode tirar proveito da tecnologia da nos processos de backup do SQL Server para: Reduzir o impacto no sistema de produção durante o processamento de backup. Criar imagens de backup consistentes. Integrar processos de backup e recuperação do SQL Server. AlwaysOn Availability Groups No evento de uma falha de hardware ou software, várias cópias de banco de dados em um AlwaysOn Availability Group viabilizam a alta disponibilidade com failover rápido e sem perda de dados. Isso elimina o tempo de inatividade do usuário final, que se trata de um custo significativo para recuperar um backup point-in-time passado de um disco ou uma fita, conforme mostrado na Figura 8. É possível estender os AlwaysOn Availability Groups a vários locais e fornecer resiliência contra falhas no datacenter. Ele fornece replicação no nível do banco de dados e failover automatizado. Figura 8. AlwaysOn Availability Groups do SQL Server para o Microsoft Exchange Server 52 52

53 Proteção de dados nativa do SQL Server Se for necessária uma cópia point-in-time passada de um banco de dados, você poderá usar o SQL Server para criar uma cópia tardia em um ambiente de AG. Isso poderá ser útil se uma corrupção lógica for replicada entre os bancos de dados do AlwaysOn Availability Group, resultando no retorno de um point-in-time anterior. Isso também será útil se um administrador excluir acidentalmente os dados do usuário. A tem a capacidade de fornecer os mesmos níveis de proteção, senão melhores, mas usa bem menos armazenamento com a aplicação de snapshots. Cópias recuperáveis versus reinicializáveis As tecnologias de replicação da podem criar dois tipos diferentes de cópias de banco de dados, ou seja, recuperáveis e reinicializáveis. Você pode usar uma das tecnologias ou ambas para satisfazer as necessidades de RPO de backup e outros requisitos. Cópia recuperável do banco de dados Cópia recuperável do banco de dados é um backup no qual são aplicados registros ao banco de dados e que acessa qualquer ponto no tempo após a criação da cópia. No caso de uma falha no banco de dados de produção, é possível recuperar o banco de dados não apenas para o ponto no tempo do último backup, mas também acessar as transações subsequentes até o momento da falha. Esse recurso é muito importante para o banco de dados SQL Server, bem como para muitos outros requisitos de negócio. A Tabela 13 lista as três maneiras de criar uma cópia recuperável de um banco de dados SQL Server. Tabela 13. Metodologia do SQL Server para criar uma cópia recuperável do banco de dados Metodologia de backup Backup de fluxo contínuo VDI VSS Descrição Instrução T-SQL ou backup do SQL Server nativo Virtual Device Interface para software de terceiros Volume Shadow Copy Service para software de terceiros- Compatível Backup do SQL nativo, Networker VMAX/VNX/VNXe Networker, Replication Manager, AppSync, RecoverPoint VMAX/VNX/VNXe Networker, Replication Manager, AppSync, RecoverPoint Os três tipos de backup são integrados ao SQL Server e são considerados backups dinâmicos. O SQL Server registra o backup quando ele ocorre. Cópia reinicializável do banco de dados Quando uma cópia de banco de dados é criada em um nível de armazenamento sem nenhuma integração no nível do banco de dados, o SQL Server pode usar a cópia para executar uma recuperação de falhas e trazer o banco de dados até o ponto no tempo em que a cópia foi realizada. Isso é considerado uma cópia reinicializável do banco de dados. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 53 53

54 Nesse caso, todas as transações registradas como confirmadas e gravadas no registro de transações, com suas páginas de dados correspondentes nos arquivos de dados, são refeitas. Em seguida, o SQL Server vai desfazer ou reverter as alterações registradas, mas que não foram confirmadas (como páginas sujas submetidas a flush por uma gravação lenta). Isso resulta em um estado de banco de dados com um ponto no tempo consistente em termos transacionais. O backup do registro de transações adicional não pode ser aplicado a um banco de dados nesse estado, fazendo com que, dessa forma, o banco de dados seja recuperado apenas para o ponto no tempo do backup. Uma cópia reinicializável do banco de dados é considerada uma cópia estática do banco de dados. Não há registro do backup no SQL Server. A tecnologia Consistency da pode ser usada para criar cópias reinicializáveis de um banco de dados SQL Server de origem. Esse tipo de tecnologia não é invasivo para as operações do banco de dados de produção e ocorre inteiramente no nível do storage array. As imagens reinicializáveis representam imagens consistentes dependentes de gravação de todos os objetos relacionados que foram definidos no grupo de consistência. Estruturas VDI e VSS para replicação do backup O VMAX, o VNX e o VNXe da também implementam a tecnologia de consistência integrada com a tecnologia de snapshot VDI e a estrutura VSS para criar uma cópia recuperável do banco de dados. O RecoverPoint, o Replication Manager, e o AppSync são desenvolvidos com base nessas tecnologias a fim de fornecer proteção de dados adequada a diferentes ambientes. Produtos de alta disponibilidade e proteção de dados da para o SQL Server Embora a proteção de dados nativa do SQL Server seja suficiente para alguns clientes, a maioria ainda requer recursos de backup e restauração completos para bancos de dados SQL Server. A oferece uma grande variedade de opções para fornecer alta disponibilidade e proteção de dados com o SQL Server. A Solução de proteção do SQL Server no Apêndice D fornece detalhes da solução, inclusive alguns dos produtos de proteção listados para o SQL Server. A Tabela 14 lista as opções de banco de dados SQL Server. Tabela 14. Opções de alta disponibilidade e proteção de dados da Categoria Disponibilida de contínua Ferramenta/ sistema reutilização Descrição RecoverPoint CDP Síncrono Proteção de recuperação local CRR Assíncrono Replicação contínua remota VMAX/VNX com um divisor RecoverPoint incorporado CLR CDP/CRR/CLR Concurrent Local and Remote Data, dados locais e remotos simultâneos Combina CDP e CRR Os arrays VMAX e VNX têm opções com um divisor RecoverPoint incorporado que funciona como disponibilidade contínua nativa para o Microsoft Exchange Server 54 54

55 Categoria Recuperação de replicação rápida point-in-time Backup e restauração point in time eficientes Ferramenta/ sistema reutilização Descrição VMAX SRDF Replicação contínua AppSync Replicação Uma proteção de dados de somente de autoatendimento, orientada por SLAs snapshot no VNX (Service-Level Agreements, contratos de nível de serviço) simples para gerenciamento de armazenamento para SQL Server Também funciona com o RecoverPoint no VNX Nenhum agente necessário Replication Manager VMAX TimeFinder Snapshot/Clone, cópia de SAN para VMAX e VNX Espelhado CG Clone Snapshot Um software de proteção de dados completo É necessário instalar o agente no SQL Server Operações de controle e monitoramento gerais para BCVs (Business Continuance Volumes) Grupos de consistência As sessões de clone, geralmente, consomem o mesmo tamanho de LUNs de produção, mas não geram impacto depois de criadas Os snapshots consomem menos espaços que os clones, mas gerarão mais impacto nas LUNs de produção se os dados forem alterados com frequência nas LUNs VNX Clone As sessões de clone, geralmente, consomem o mesmo tamanho de LUNs de produção, mas não geram impacto depois de criadas Snapshot Os snapshots consomem menos espaços que os clones, mas gerarão mais impacto nas LUNs de produção se os dados forem alterados com frequência nas LUNs Avamar NetWorker Solução de hardware e software completa Solução de software de backup e restauração tradicionais A desduplicação de tamanho variável reduz significativamente o tempo de backup armazenando somente alterações diárias exclusivas e, ao mesmo tempo, mantendo backups completos diários para propiciar restauração imediata em uma só etapa Centraliza, automatiza e acelera o backup e a recuperação de dados com uma grande variedade de opções de proteção de dados Cada produto tem seus próprios benefícios e considerações. A decisão depende dos requisitos de nível de serviço de cada caso de uso. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 55 55

56 Os produtos de snapshot e clone baseados em hardware são integrados à tecnologia Microsoft VDI e VSS há muitos anos. O Symmetrix TimeFinder e o VNX SnapView (ou snapshot avançado na versão posterior) permitem snapshots point-in-time locais e clones de dados para operações de backup e recuperação. Esses produtos proporcionam operações de backup simples e que não causam interrupções, com snapshots que economizam espaço ou cópias de clone FULL block a block de seus bancos de dados e registros. Com esses produtos, os backups e as restaurações podem ocorrer em segundos. O Replication Manager permite o gerenciamento de tecnologias de replicação point-in-time da para SQL Server por meio de um console de gerenciamento centralizado. O Replication Manager coordena todo o processo de replicação de dados, desde a detecção e a configuração até o gerenciamento de várias réplicas baseadas em disco e consistente com os aplicativos. É possível detectar os bancos de dados de forma automática, com gerenciamento simplificado para agendamento de replicação, gravação, catalogação e autoexpiração. A recomenda expressamente um método robusto para habilitar backups e restaurações rápidos do banco de dados SQL Server. O Replication Manager, o Avamar e o Networker oferecem recursos para registrar o truncamento e a montagem de bancos de dados para hosts alternativos. Mesmo que o recurso de AAG nativo do Microsoft SQL Server 2012 seja usado, a recomenda expressamente uma estratégia sólida e alternativa de proteção de dados point-in-time do SQL Server para a proteção contra eventos de corrupção lógica. Tecnologias de replicação O SQL Server requer recursos de sistema dedicados. Quando um mecanismo de proteção é implementado no ambiente SQL, considere o impacto no desempenho do SQL Server causado por isso. RecoverPoint O RecoverPoint replica dados para proteger o ambiente SQL Server de desastres. Ele fornece três opções: A proteção de recuperação local (CDP) fornece proteção síncrona capturando cada transação em um banco de dados e gravando-a simultaneamente em um local de armazenamento secundário. Replicação remota contínua (CRR) é uma proteção assíncrona que pode replicar dados em qualquer distância. Proteção de dados remota e local simultânea (CLR), que combina os métodos de replicação CDP e CRR a fim de fornecer proteção local e remota a um ambiente SQL Server. O RecoverPoint proporciona bom dimensionamento e pode ser implementado em ambientes SQL Server muito grandes. Ele pode fornecer uma cópia reinicializável contínua do banco de dados de usuário e dos arquivos de registros de quase qualquer ponto no tempo. Os arrays VNX e VMAX mais recentes têm o divisor RecoverPoint incorporado. As Notas técnicas RecoverPoint Replicating Microsoft SQL Server, disponíveis no site de Suporte on-line da, especifica mais informações. para o Microsoft Exchange Server 56 56

57 TimeFinder O TimeFinder compreende recursos de continuidade dos negócios que permitem a execução de operações de controle em pares de dispositivos em um ambiente de replicação local com a seguinte funcionalidade: TimeFinder/espelhamento - operações de controle e monitoramento gerais para BCV (Business Continuance Volumes) TimeFinder/CG - grupos de consistência TimeFinder/Clone - sessões de cópia de clone TimeFinder/Snap - sessões de cópia de snapshot Esses recursos podem ser usados pelo storage manager ou acoplados a outro software de replicação de dados a fim de fornecer cópias de snapshots e clones VDI ou VSS integradas ao SQL server. Clone/snapshot VNX A Suíte Local Protection combina snapshots e clones com recuperação point-intime com recursos de reversão do tipo DVR para continuidade de negócios em armazenamento baseado em blocos, possibilitando a recuperação de aplicativos de produção com exposição mínima dos dados. Os proprietários de aplicativos podem ajustar os objetivos de ponto de recuperação com base nas condições críticas dos dados e executar recuperação mais rápida por meio de recursos de autoatendimento. As cópias dos dados de produção podem ser usadas no desenvolvimento, em testes, em ferramentas de suporte a decisões, geração de relatórios e aceleração de backup: SnapView SnapSure RPSE CDP (RecoverPoint/SE Continuous Data Protection) Ferramentas de gerenciamento de replicação A Suíte Application Protection automatiza a criação de cópias de banco de dados reinicializáveis consistentes com aplicativos, de maneira que o banco de dados SQL Server possa ser recuperado para níveis de serviço definidos. Para cópias recuperáveis de banco de dados, é necessário fazer backup dos registros de transações do SQL Server separadamente: Para que a série VNX inclua o Replication Manager/AppSync e o Data Protection Advisor for Replication Analysis. Para que a série VNXe inclua o Replication Manager/AppSync. Para que a série VMAX inclua o Replication Manager/AppSync. Para obter a capacidade de recuperação point-in-time para o replication manager ou o AppSync, os backups completos realizados com o snapshot ou clones precisam ser combinados com os backups de registros do SQL Server. Restoring a Database to a Point Within a Backup, disponível na Biblioteca Microsoft MSDN, especifica mais informações sobre recuperação point-in-time. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 57 57

58 Recuperação de desastres em vários locais Considerações Os requisitos mais importantes para a implementação de uma solução de recuperação de desastres de vários locais geralmente no SLA (Service Level Agreement, contrato de nível de serviço) são: RTO (Recovery Time Objective, objetivo de tempo de recuperação): por quanto tempo o usuário final do SQL Server pode tolerar a interrupção do serviço. RPO (Recovery Point Objective, objetivo de ponto de recuperação): qual nível de perda de dados pode ser tolerado. Custo: custo da solução para viabilizar o SLA em questão. Com uma solução de replicação sincronizada, os dados só são reconhecidos quando os dados do local remoto são confirmados: Vantagem: perda de dados nula (0 RPO) em qualquer momento. Desvantagem: isso pode desacelerar o ambiente de produção com um link lento a uma longa distância. A replicação sincrônica a distâncias maiores que 200 km pode não ser viável. Uma solução de replicação sincronizada não terá a limitação de distância porque os dados serão confirmados antes que o local remoto envie o reconhecimento: Vantagem: nenhuma limitação para a distância de replicação. Desvantagem: pode ocorrer perda de dados. A quantidade de dados/volumes protegidos é outra consideração sobre o projeto de proteção de vários locais: Todos os dados são replicados. Pode ser configurado no local remoto para iniciar automaticamente quando o failover for necessário, fornecendo RTO instantâneo. A transferência de mais dados pela rede pode degradar o desempenho da produção. Escolha apenas arquivos de registro e banco de dados de usuário para replicação. A transferência de menos dados pela rede significa melhor desempenho da produção e menos perda de dados. Menos dados no grupo de consistência pode prolongar o tempo e o procedimento de recuperação (RTO mais longo). Para obter o mais alto nível de RTO e RPO, escolha a solução sincronizada, possivelmente com produto de clustering geograficamente disperso. Isso fornecerá soluções de perda de dados nula com RTO extremamente pequeno, com a maioria dos processo automatizada (VMAX SRDF/CE). É necessário investimento em links rápidos entre os locais. Para um nível mais alto de RTO e RPO, o VPLEX fornece resultados semelhantes com arrays heterogêneos no local remoto. O RecoverPoint, o Replicator e o restante das tecnologias de replicação de vários locais da podem fornecer RTO e RPO muito bons, com o mínimo de intervenção do usuário, para ativar o local remoto quando a recuperação de desastres é necessária. para o Microsoft Exchange Server 58 58

59 Tecnologias de replicação de vários locais Para ampliar o recurso de configurações de cluster de failover de um só local do Windows e fornecer proteção de vários locais adicional, a fornece as seguintes soluções: VMAX SRDF/Cluster Enabler para produto de clustering geograficamente disperso MSCS. O RecoverPoint fornece proteção remota síncrona e assíncrona. A proteção assíncrona pode replicar dados em qualquer distância. O VPLEX fornece acesso a uma só cópia de dados em diferentes locais geográficos de maneira simultânea, permitindo uma migração transparente de máquinas virtuais em execução entre datacenters. A Suíte VNX Remote Protection fornece proteção por meio do Replicator, do MirrorView e do RecoverPoint/SE CRR (Continuous Remote Replication). O VNXe Replicator fornece proteção remota para iscsi e NAS VNX Remote Protection Suite A VNX Remote Protection Suite fornece replicação de block e file unificada, fornecendo recuperação de desastres para ambientes NAS e SAN. Ela fornece proteção de recuperação de desastres para qualquer host e aplicativos sem compromisso com reversão imediata tipo DVR para qualquer ponto no tempo. Os recursos incluem compactação e desduplicação para redução da largura de banda WAN, objetivos de ponto de recuperação específico do aplicativo e opções de replicação para configurações de um para muitos. Essa suíte da série VNX inclui o Replicator, o MirrorView/A, o MirrorView/S e o RecoverPoint/SE CRR (Continuous Data Protection, proteção contínua de dados). Essa suíte da série VNXe inclui o Replicator (iscsi e NAS). O MirrorView repica as LUNs de banco de dados SQL Server em locais remotos para recuperação de desastres. A replicação MirrorView é transparente para o host. Se houver falhas no sistema de armazenamento de produção ou no host de produção, a replicação remota facilita o failover para a imagem de espelhamento secundária. O software MirrorView oferece dois produtos de espelhamento complementares: O MirrorView/S pode espelhar, de modo síncrono, imagens de dados das LUNs do host de produção para armazenamento secundário em um local remoto em tempo real. Isso oferece perda de dados nula se houver uma falha no local de produção. O MirrorView/A oferece replicação de longa distância com base em um modelo de atualização incremental periódica. Ele atualiza periodicamente a cópia remota dos dados com todas as alterações que ocorreram na cópia local desde a última atualização. Isso pode resultar em perda de dados nula se houver uma falha no local de produção. O MirrorView funciona bem em ambientes SQL Server de pequeno a médio portes. O Business Continuity for Microsoft SQL Server 2008 Enabled by CLARiiON and MirrorView /A White Paper no site da especifica mais informações sobre o MirrorView. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 59 59

60 Ferramentas para automação de reinício O Microsoft FCI (Failover Clustering Instance) fornecerá automação de reinício ativando o local secundário de forma automática se o servidor do local principal se tornar inativo. O VMAX SRDF/CE para MSCS fornece uma solução de clustering geograficamente dispersa, com um alto nível de automação que fornece perda de dados nula e RTO extremamente pequeno para a recuperação de desastres do SQL Server em um local diferente no nível de instância. Os AlwaysOn Availability Groups fornecem recuperação de desastres para servidores em vários locais com uma opção de failover automático no nível de banco de dados se o banco de dados principal se tornar inativo. Ferramentas de automação de instâncias virtualizadas O SRM (Site Recovery Manager) do vcenter fornece recuperação de desastres automatizada para recuperação rápida e eficiente de aplicativos essenciais, como SQL Server, simplificando a recuperação e eliminando o erro humano do processo. A arquitetura de referência e projeto de exemplo em Proteção da solução SRM do vcenter fornece detalhes da configuração do SRM. Opções de recuperação de desastres para o SQL Server 2012 A oferece várias opções de DR para SQL Server A Tabela 15 descreve algumas opções mais usadas. Cada opção tem vantagens e desvantagens. A melhor opção para um ambiente é determinada por seus requisitos de DR específicos. Tabela 15. Ofertas de recuperação de desastres da para o SQL Server Oferta Método de replicação Descrição AlwaysOn Availability Groups Portabilidade do banco de dados Mudança de servidor/local Replicação contínua nativa do SQL Server RecoverPoint VPLEX RecoverPoint VPLEX VMAX SRDF/Cluster Enabler Replicator Incorporada ao SQL Server 2012 para alta disponibilidade e recuperação de desastres Apenas os dados do SQL Server são replicados. Requer alterações do DNS no failover para a réplica secundária Os dados do SO e do SQL Server são replicados, e o failover inclui início do servidor, alteração do IP e atualização do DNS Recomendações adicionais de backup Siga estas recomendações adicionais para backups do SQL Server a fim de reduzir a degradação do desempenho: Com cargas de trabalho de médias a altas, não faça backups diretamente do SQL Server de produção. Em vez disso, monte um clone ou um snapshot point-in-time em outro servidor e faça os backups desse servidor ou com uma cópia secundária em um AlwaysOn Availability Group. Agende os backups para que ocorram fora dos horários de pico sempre que possível. para o Microsoft Exchange Server 60 60

61 AlwaysOn para HA/DR O AlwaysOn Availability Group é uma solução de replicação nativa contínua do Microsoft SQL Server incorporada ao SQL Server 2012 para alta disponibilidade e recuperação de desastres. A implementação dos AlwaysOn Availability Groups se ajusta perfeitamente às soluções baseadas em flash da, como FAST VP, FAST Cache, flash XtremSW Cache e XtremSF. AlwaysOn com FAST Suite Quando os AlwaysOn Availability Groups são configurados como parte do plano de HA e DR para o banco de dados SQL Server, os seguintes itens são práticas recomendados para o projeto de cópia secundária dos AlwaysOn Availability Groups: Se a cópia secundária não precisar dar suporte a altas cargas de trabalho de geração de relatórios, ela poderá residir em um armazenamento de nível inferior se puder dar suporte, com eficiência, à carga de trabalho necessária na ocorrência de um failover. Quando o FAST VP ou o FAST Cache está habilitado para a cópia secundária, é possível aprimorar a carga de trabalho de somente leitura. Se a cópia secundária não compartilhar o pool com a principal, não haverá impacto no local principal. Isso também possibilita o mais alto nível de desempenho quando um failover requer a cópia secundária. O Mission Critical Infrastructure for Microsoft SQL Server 2012 White Paper fornece uma arquitetura de referência e projeto de exemplo e outros detalhes de implementação. AlwaysOn com flash XtremSW Cache/XtremSF Quando o lado de flash do servidor é implementado, a intensificação do desempenho das cargas de trabalho do SQL Server permite um desempenho muito melhor com latência extremamente baixa. As práticas recomendadas e as considerações sobre projeto para o XtremSW Cache e o XtremSF são as seguintes: O XtremSW Cache, geralmente, só precisa ser configurado no local principal, a menos que o local secundário exija uma intensificação do desempenho na carga de trabalho de somente leitura (somente quando a carga de trabalho é aleatória) ou quando é necessário um melhor desempenho para failovers para o local secundário. Se as cópias secundárias nos AlwaysOn Availability Groups também tiverem o XtremSF com uma rede alta velocidade e curta distância, a cópia sincronizada poderá ser implementada com nenhum impacto no servidor de produção e mínima perda de dados na ocorrência de um failover. Várias cópias secundárias dos AlwaysOn Availability Groups geram menos impacto no servidor de produção quando o XtremSF é usado para os locais principal e secundário com um link de rede rápido. O XtremSW Cache pode ser usado em conjunto com o FAST Suite de armazenamento para impulsionar ainda mais o desempenho do SQL Server. O XtremSF Acceleration for Microsoft SQL Server 2012 White Paper fornece mais detalhes sobre o projeto e a implementação do XtremSF. O Infrastructure for High Performance Microsoft and Oracle Database System White Paper fornece mais detalhes sobre o projeto e a implementação do XtremSW Cache. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 61 61

62 Conclusão Resumo Este documento destaca os principais pontos de decisão no planejamento de uma implementação do SQL Server com sistemas de armazenamento da. Várias opções de configuração estão disponíveis para se ajustarem à maioria dos ambientes. Os produtos de gerenciamento de dados e armazenamento da são projetados para proporcionarem um gerenciamento flexível de ambientes SQL Server e atenderem às suas necessidades dos negócios. As práticas recomendadas de projeto de armazenamento do SQL Server estão em desenvolvimento constante. Com a rápida evolução da tecnologia de armazenamento, as práticas recomendadas tradicionais podem não se aplicar a todas as configurações. Este documente apresenta as práticas recomendadas atuais da para implementar o SQL Server com a família VNX de armazenamento unificado ou a série de armazenamento Symmetrix VMAX da. Essas diretrizes podem ajudá-lo a obter um ambiente do SQL Server eficiente, de alto desempenho e altamente disponível, que atenda às suas necessidades. Este paper apresenta os seguintes conceitos, princípios e fórmulas para ajudá-lo a: Entender as características de I/O e largura de banda do SQL Server. Aplicar práticas recomendadas relativas ao SQL Server e à série de armazenamento VNX ou VMAX. Utilizar um componente básico de armazenamento do SQL Server. Calcular os requisitos de I/O, capacidade e largura de banda de armazenamento. Validar seu projeto de armazenamento geral. Familiarizar-se com as várias opções de proteção de dados do SQL Server. Informações adicionais Consulte seu especialista em SQL Server da para obter orientações adicionais para a implementação do Microsoft SQL Server com a família VNX ou a série de armazenamento da série Symmetrix VMAX da. para o Microsoft Exchange Server 62 62

63 Apêndice A: Data Protection Advisor for Replication Analysis Visão geral Assistentes Data Collection and Discovery Detecção e coleta de dados O DPA/RA (Data Protection Advisor for Replication Analysis) automatiza a coleta de dados de aplicativos, hosts e arrays; monitora exposições de maneira constante e envia alertas relativos a SLAs que podem ser perdidos e falhas nos objetivos de proteção. O monitoramento de dispositivos e aplicativos é automatizado com os assistentes Data Collection e Discovery, que configuram o DPA/RA com uma série de questões sobre o dispositivo ou o aplicativo a ser monitorado. Depois de definir um dispositivo ou um aplicativo com os assistentes, um ou mais nós são automaticamente adicionados à exibição Configuration e ao monitoramento de dados para quando o coletor é iniciado. Neste exemplo, os arrays VNX são remotamente detectados e monitorados do coletor em execução no servidor DPA/RA. O sistema VNX é monitorado quanto à capacidade de recuperação e à geração de relatórios de análise. A detecção de storage arrays do DPA/RA requer a instalação do Solutions Enabler. Para instalar o Solutions Enabler, use as seguintes etapas: 1. Instale o Solutions Enabler no servidor DPA/RA. 2. Crie um arquivo de texto com as seguintes informações, uma linha por array (neste exemplo, o nome do arquivo é Clar.txt): <SPA IP> <SPB IP> <Username> <Password> 3. Para registrar o VNX, execute o seguinte comando no servidor DPA/RA: 4. Para verificar se o VNX foi adicionado com êxito, execute o seguinte comando: Detectando storage arrays Para detectar storage arrays com o DPA/RA, siga estas etapas: 1. Na barra de ferramentas do DPA/RA, selecione Tools, em seguida, escolha Discovery Wizard. 2. Selecione Storage Arrays, vá para o painel Import Source e clique em Next. O assistente Discovery exibe uma lista de todos os storage arrays. Selecione os storage arrays a serem importados e clique em Next. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 63 63

64 3. Selecione uma programação (Schedule) para a solicitação de coleta de dados de capacidade de recuperação e clique em Finish. Configurando o Data Protection Advisor para monitoramento do Microsoft SQL Server Para configurar o DPA/RA para o monitoramento do SQL Server, use as seguintes etapas: 1. Na barra de ferramentas do DPA/RA, selecione Tools e, em seguida, escolha Data Collection Wizard. 2. Clique em Host e em Next. O painel Host Details é exibido. Figura 9. Data Collection Wizard 3. Especifique o nome, a descrição e o tipo de SO do host. 4. Em Collector Location (Figura 10), escolha Yes para Is there or will there be a Collector installed on the Host?, Figura 10. Collector Location para o Microsoft Exchange Server 64 64

65 5. Para colher dados do SO sobre a utilização da memória e o desempenho da CPU, em Data Gathering: a. Para Do you want to gather system information?, escolha Yes. b. Para Do you want to monitor applications on this host?, escolha Yes. c. Selecione Microsoft SQL Server, conforme mostrado em Figura 11. Figura 11. Coleta de dados 6. Para adicionar uma instância do SQL Server, no painel Data Gathering, clique em Add. A caixa de diálogo Add SQL Server Instance é exibida. Especifique as credenciais aplicáveis do SQL Server e feche a caixa de diálogo. A Figura 12 mostra que o SQL Server foi adicionado com êxito à configuração do DPA/RA. Figura 12. Exibição do servidor de banco de dados do DPA/RA Exibindo e relatando lacunas e exposições O DPA/RA fornece um mapa gráfico intuitivo do relacionamento entre o host e o armazenamento. O DPA/RA apresenta as lacunas da capacidade de recuperação e exposições por meio de relatórios e exibições para solução de problemas. O DPA/RA pode monitorar várias condições de erro de replicação. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 65 65

66 A Figura 13 mostra a configuração para configurar um relatório agendado, enquanto a Figura 14 mostra os detalhes de exposição relativos ao SQL Server. Isso associa o armazenamento ao RecoverPoint e, em seguida, à máquina virtual SQL Server, que reside no cluster ESX. Figura 13. O Scheduled Report Editor mostra sistemas SQL Server monitorados Figura 14. Detalhes de exposição sobre o SQL Server A partir desse ponto, o DPA/RA detecta que falta na configuração um volume de aplicativos, a réplica está incompleta e talvez não seja possível recuperar o aplicativo. Em seguida, você pode verificar a configuração e corrigi-la adequadamente. para o Microsoft Exchange Server 66 66

67 Apêndice B: Ferramentas para monitoramento do desempenho, ajuste e dimensionamento do SQL Server Visão geral O SQL Server pode ser monitorado em muitos níveis, de cima para baixo, inclusive: Aplicativo que usa o SQL Server para transações, banco de dados SQL Server, host Windows que hospeda o SQL Server, Hypervisor (se virtualizado) e a camada de armazenamento na qual residem todos os dados. A recomenda coletar dados de desempenho durante a execução das cargas de trabalho de produção. Em alguns casos, as características das cargas de trabalho são alteradas periodicamente (por exemplo, um sistema pode efetuar OLTP durante o dia, ETL e geração de relatórios à noite e backup de madrugada). Nesse caso, é necessário capturar todas as fases do dia, para que você possa dimensionar um sistema a fim de atender a todas as fases da produção. Na execução de um cluster de failover Windows, a recomenda coletar dados de todos os nós simultaneamente, de maneira que os dados de desempenho sejam coletados mesmo durante um failover de cluster. A também recomenda coletar e analisar contadores que indiquem pressão da CPU e da memória na máquina física ou virtual, pois esses fatores podem afetar o desempenho do armazenamento. Por exemplo, a inclusão de memória em um servidor pode reduzir, de maneira significativa, a I/O de armazenamento, ou a remoção de um gargalo da CPU pode aumentá-la drasticamente. A Tabela 16 lista as ferramentas para cada nível de uso. Tabela 16. Ferramentas usadas para monitoramento do desempenho, ajuste e dimensionamento do SQL Server serviço Ferramenta Origem/Links Descrição Aplicativo DBclassify ( ains/zettapoint/index.htm) Monitora constantemente os dados, obtém seus padrões e o comportamento passado e, em seguida, classifica-os e move-os de acordo com as prioridades dos negócios. Perfcollect Avaliação do desempenho das cargas de trabalho da ( ( Automatiza a coleta de dados de desempenho relacionados ao SQL Server. Usado principalmente para o dimensionamento do ambiente virtual e do armazenamento. Também conhecido como Mitrend. Ferramenta on-line e automatizada de avaliação do desempenho das cargas de trabalho, que correlaciona e exibe as principais informações de desempenho relacionadas ao dimensionamento. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 67 67

68 serviço Ferramenta Origem/Links Descrição PAL Performance Analyzer of Logs código aberto ( PAL) Útil para problemas de desempenho da solução de problemas. Banco de dados SQL Server Ferramenta de dimensionament o do VSPEX SQL ( o/emc) Pode ser usada para definir a VSPEX Proven Infrastructure recomendada para o SQL Server virtualizado com base nos requisitos do usuário. T-SQL Microsoft (é fornecida com a instalação do SQL Server) Fornece procedimentos armazenados do sistema Transact-SQL para criar rastreamentos em uma instância do SQL Server Database Engine. SQL Server profiler Microsoft (serviços de análise do SQL Server) Fornece captura e reprodução do SQL Trace em uma interface gráfica do usuário. SQL DTA (Database Tuning Advisor) Microsoft (serviços de análise do SQL Server) O DTA fornece ao SQL Server sugestão de ajuste como indexação e particionamento. DMVs (Dynamic Management Views) Microsoft (serviços de análise do SQL Server) As Dynamic Management Views são estruturas de consulta que expõem informações sobre operações do servidor local e integridade do servidor. Host Windows Perfmon Monitor de desempenho do Windows (é fornecido com a instalação do Windows Server) O Perfmon pode rastrear as características de desempenho das cargas de trabalho do SQL Server. Hipervisor VMware Interface gráfica do vsphere Client Guia do vsphere Client Principal ferramenta para rastrear o desempenho e configurar dados para um ou mais hosts ESX/ESXi. Resxtop/Esxtop ESX/ESXi Fornece uma matriz de desempenho, mas requer acesso à raiz. Hyper-V Perfmon Monitor de desempenho do Windows Fornece uma matriz de desempenho para o Hyper-V e máquinas virtuais. Storage/Server Cache Unisphere Analyzer incluído nos sistemas de armazenamento da Fornece monitoramento do desempenho para sistemas de armazenamento da. Ferramenta XtremSW Cache Performance Predictor arch/?product_id=25208&te xt=predictor Fornece uma ferramenta de previsão de desempenho para que o XtremSW Cache examine e avalie o ambiente SQL Server para o XtremSW Cache. para o Microsoft Exchange Server 68 68

69 serviço Ferramenta Origem/Links Descrição Storage Configuration Advisor Disponível por meio da pré e pós-venda da - - Auxilia na definição das políticas de classificação por níveis para um ambiente existente; o Tier Advisor monitora a I/O e recomenda configurações das políticas de classificação por níveis. Ferramentas no nível do aplicativo DBclassify O DBclassify é uma solução de otimização de banco de dados que reduz o custo total de propriedade do armazenamento de banco de dados, enquanto melhora o desempenho dos aplicativos de negócios. O DBclassify monitora constantemente os dados, obtém os padrões e o comportamento passado e, em seguida, classifica-os e move-os de acordo com as prioridades dos negócios. O DBclassify é ideal para organizações de TI que enfrentam desafios orçamentários e relativos ao gerenciamento e ao desempenho, associados ao aumento da complexidade dos bancos de dados. O DBclassify analisa e diferencia dados estruturados a fim de proporcionar total visibilidade do uso real do banco de dados. Por meio de um processo de análise completo, o DBclassify rastreia e classifica automaticamente cada objeto do banco de dados (tabelas, índices e partições), com base na frequência de acesso e em informações de espera de I/O. Além disso, o DBclassify associa cada objeto do banco de dados a usuários e aplicativos com base no uso real. Usando uma fórmula de classificação exclusiva, o DBclassify é uma solução de classificação por níveis ideal para bancos de dados de toda a empresa, oferecendo recomendações sobre classificação por níveis para o objeto, o espaço de tabelas ou o nível do arquivo, além de funcionar como o mecanismo de política para a tecnologia FAST. Em ambientes SQL Server, os dados são coletados com uma conexão de banco de dados remota em vez de um agente baseado em servidor monitorado. O coletor processa execuções no servidor de repositório do DBclassify e extrai informações do banco de dados monitorado. A Figura 15 mostra a arquitetura do DBclassify para SQL Server. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 69 69

70 Figura 15. Arquitetura do DBclassify SQL Server As práticas recomendadas com o DBclassify são as seguintes: Implemente o DBclassify antes de um upgrade/migração importante para fazer benchmark do perfil de I/O atual. Capture as cargas de trabalho de pico para fazer uma análise detalhada da I/O. Gere uma política de FAST VP baseada em níveis variados de porcentagens limite e capacidade de armazenamento hierárquico. Crie filtros de negócios que reflitam os processos e as cargas de trabalho dos clientes. Analise os dados de uso com base nos filtros de negócios. Classifique os dados de uso nas categorias ativos, dinâmicos ou inativos. Crie um perfil e faça benchmark da atividade de I/O em todos os níveis para todos os bancos de dados. Agrupe bancos de dados na classificação baseada na importância. Crie um perfil e faça benchmark da capacidade de classificação por níveis do armazenamento pela classificação do banco de dados. Você pode obter mais informações sobre o DBclassify no site do DBclassify: É possível obter essa ferramenta com o revendedor ou o engenheiro de sistemas da. para o Microsoft Exchange Server 70 70

71 Perfcollect A fornece uma ferramenta automatizada denominada Perfcollect, que está disponível gratuitamente. O Perfcollect automatiza a coleta de contadores de CPU, memória, armazenamento e do SQL Server, além de outras informações de configuração que auxiliam no dimensionamento do ambiente virtual e do armazenamento. A ferramenta pode ser executada em qualquer servidor Windows 2003 ou posterior. Você pode analisar manualmente as informações do monitor de desempenho com o monitor de desempenho do Windows. Workload Performance Assessment Tool A Workload Performance Assessment Tool está disponível aos parceiros da. Essa ferramenta on-line automatizada correlaciona e exibe informações de desempenho essenciais relacionadas ao dimensionamento. É possível obter essa ferramenta com o revendedor ou o engenheiro de sistemas de pré-venda da. PAL Você pode usar a ferramenta PAL (Performance Analyzer of Logs) de código aberto para solucionar problemas de desempenho (em vez do dimensionamento para migrações). É possível usar os dados coletados com o Perfcollect com a ferramenta PAL, que pode ser baixada do site CodePlex. Ferramentas no nível do banco de dados SQL Server Ferramenta de dimensionamento VSPEX SQL Server A ferramenta de dimensionamento VSPEX SQL Server está disponível para dimensionar a VSPEX Proven Infrastructure para SQL Server 2012 virtualizado com base nos requisitos do usuário. Você também pode usar a estimativa de dimensionamento para outros ambientes virtualizados em armazenamento VNX da. A Figura 16 a Figura 20 fornecem resultados de exemplo do dimensionamento de um banco de dados OLTP de 500 GB com, no máximo, IOPS e 10% de crescimento anual em um sistema VNX5400 com RVMs (Reference Virtual Machines, máquinas virtuais de referência). Figura 16. Configuração do VSPEX Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 71 71

72 Figura 17. Requisitos do disco VSPEX Figura 18. Entradas do SQL Server 2012 (instância nº 1) Figura 19. Requisitos de recursos do SQL Server 2012 Figura 20. Requisitos do disco SQL Server Transact-SQL O Microsoft SQL Server fornece procedimentos armazenados do sistema Transact-SQL para criar rastreamentos em uma instância do banco de dados SQL Server. Esses procedimentos armazenados do sistema podem ser usados em seus próprios aplicativos para criar rastreamentos manualmente, em vez de usar o SQL Server Profiler. Isso permite que você elabore aplicativos personalizados específicos às necessidades de sua empresa. A Tabela 17 lista os procedimentos armazenados para rastrear uma instância do SQL Server Database Engine. Tabela 17. Procedimentos armazenados do Transact-SQL para rastreamento do SQL Server Procedimento armazenado fn_trace_geteventinfo (Transact-SQL) fn_trace_getinfo (Transact-SQL) sp_trace_create (Transact-SQL) sp_trace_generateevent (Transact-SQL) Tarefa executada Retorna informações sobre eventos incluídos em um rastreamento. Retorna informações sobre um rastreamento específico ou todos os rastreamentos existentes. Cria uma definição de rastreamento. O novo rastreamento estará em um estado parado. Cria um evento definido pelo usuário. para o Microsoft Exchange Server 72 72

73 Procedimento armazenado sp_trace_setevent (Transact-SQL) sp_trace_setstatus (Transact-SQL) fn_trace_getfilterinfo (Transact-SQL) sp_trace_setfilter (Transact-SQL) Tarefa executada Adiciona uma classe de evento ou uma coluna de dados a um rastreamento ou a remove dele. Inicia, para ou fecha um rastreamento. Retorna informações sobre filtros aplicados a um rastreamento. Aplica um filtro novo ou modificado a um rastreamento. Rastreamento Microsoft SQL fornece mais detalhes. SQL Server Profiler O SQL Server Profiler é uma interface avançada utilizada para criar e gerenciar rastreamentos e analisar e reproduzir seus resultados. Os eventos são salvos em um arquivo de rastreamento que pode ser analisado posteriormente ou utilizado para reproduzir uma série específica de etapas ao tentar diagnosticar um problema. O SQL Server Profiler pode ser usado para as seguintes tarefas: Percorrer consultas de problemas para encontrar a causa. Encontrar e diagnosticar consultas de execução lenta. Capturar a série de instruções Transact-SQL que levou a um problema. Diagnosticar um problema em um servidor de teste reproduzindo o rastreamento salvo. Monitorar o desempenho do SQL Server para ajustar as cargas de trabalho. Correlacionar os contadores de desempenho para diagnosticar problemas. Microsoft SQL Server Profiler fornece mais detalhes. SQL Server Database Engine Tuning Advisor O Microsoft DTA (Database Engine Tuning Advisor) analisa bancos de dados e faz recomendações para otimizar o desempenho das consultas. O DTA pode ser usado para selecionar e criar o conjunto ideal de índices, exibições indexadas ou partições de tabelas sem a necessidade do conhecimento de um especialista na estrutura do banco dados nem nos componentes internos do SQL Server. Com o DTA, você pode executar as seguintes tarefas: Solucionar problemas do desempenho de um consulta de problema específica Ajustar um grande conjunto de consultas em um ou mais bancos de dados Realizar uma análise 'e se' exploratória de possíveis alterações do projeto físico Gerenciar o espaço de armazenamento Para obter mais informações sobre como ajustar o projeto do banco de dados físico para cargas de trabalho de banco de dados, consulte Database Engine Tuning Advisor. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 73 73

74 SQL Server Dynamic Management Views As SQL Server DMVs (Dynamic Management Views) são estruturas de consulta que expõem informações sobre operações do servidor local e integridade do servidor. A estrutura de consultas inclui interface para conjuntos de linhas de esquema e informações de monitoramento sobre uma instância do Analysis Services. Ferramenta no nível do host Windows Monitor de desempenho do Windows (Perfmon) O Windows Perfmon rastreia as características de desempenho das cargas de trabalho em execução em máquinas físicas e virtuais, bem como no Hyper-V. Ele pode ser usado para exibir o desempenho atual e também é possível configurá-lo para registrar dados de desempenho em um arquivo para exibição e processamento posteriores. Como a coleta é feita no mesmo ambiente operacional que o aplicativo, o monitor de desempenho reflete com maior precisão o desempenho conforme ele é visualizado pelo aplicativo. A Tabela 18 lista os contadores mais úteis para avaliar a atividade e o desempenho do armazenamento em ambientes block (Fibre Channel, iscsi e SAS), que você pode visualizar nos conjuntos de contadores PhysicalDisk ou LogicalDisk. Tabela 18. Contadores úteis para avaliar o desempenho do armazenamento em ambientes SAN Contador Média de segundos do disco/transferência Média de segundos do disco/leitura Média de segundos do disco/gravação Média de bytes do disco/transferência Bytes de disco/segundo Leituras do disco/segundo Gravações do disco/segundo Recurso medido Latência geral do armazenamento Latência de leitura Latência de gravação Tamanho do I/O Throughput I/O/sec de leitura I/O/segundo de gravação para o Microsoft Exchange Server 74 74

75 O SQL Server também aceita o protocolo SMB para bancos de dados e registros de transações, que requer o conjunto de contadores SMB Client Shares, conforme mostrado na Tabela 19. Tabela 19. Contadores úteis para avaliar o desempenho do armazenamento em ambientes NAS Contador Média de solicitações de dados por segundo Média de leituras por segundo Média de gravações por segundo Média de bytes de dados por solicitação Solicitações de dados por segundo Solicitações de leitura por segundo Solicitações de gravação por segundo Recurso medido Latência geral do armazenamento Latência de leitura Latência de gravação Tamanho do I/O Throughput I/O/sec de leitura I/O/segundo de gravação A Microsoft definiu latências de armazenamento geralmente aceitáveis. A Tabela 20 lista diretrizes para investigação adicional; determinados aplicativos podem se beneficiar de latências menores ou tolerar latências maiores. Tabela 20. Diretrizes de latência para armazenamento de dados em ambientes OLTP SQL Server Carga de trabalho Latência média Latência máxima Banco de dados <20 ms de leitura <50 ms de leitura Registros de transações <10 ms de gravação <50 ms de gravação Partição de sistema/página <10 ms de leitura/gravação <10 ms de leitura/gravação O contador PLE (Page Life Expectancy) é um bom indicador de pressão da memória (mínimo de 300 ms). É possível encontrar mais informações sobre contadores do monitor de desempenho relacionados ao SQL Server e ao armazenamento aqui: Monitoramento de desempenho do SQL Server. Ferramentas no nível do hipervisor Principais métricas para monitorar ESX No ambiente VMware, as seguintes abordagens são as duas maneiras de monitorar o desempenho do ESX/ESXi: Interface gráfica do vsphere Client: Principal ferramenta para observar o desempenho e configurar dados para um ou mais hosts ESX/ESXi Não requer altos níveis de privilégio para acessar os dados Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 75 75

76 Resxtop/Esxtop: Fornece acesso a dados de desempenho detalhados para um host ESX/ESXi Fornece acesso rápido a um grande número de métricas de desempenho Requer acesso no nível da raiz É executado no modo interativo, lote ou reprodução A Tabela 21 mostra as principais métricas para monitorar hosts e máquinas virtuais do ambiente ESXi. Tabela 21. Principais métricas para monitorar hosts e máquinas virtuais ESXi Recurso Medição Descrição CPU % USADO CPU usada o intervalo de coleta (%) Memória Disco %RDY %SYS Troca (entrada), troca (saída) MCTLSZ (MB) Leituras/s, gravações/s DAVG/cmd KAVG/cmd Tempo de CPU gasto no estado pronto (somente máquina virtual) Porcentagem de tempo gasto no kernel de máquina virtual do ESXServer O host ESX de memória faz a troca (entrada/saída) do/para o disco (por máquina virtual, ou cumulativo pelo host) Quantidade de memória recuperada do pool de recursos por meio de ballooning Leituras e gravações emitidas no intervalo de coleta Latência média (ms) do dispositivo (LUN) Latência média (ms) no kernel de máquina virtual, também conhecida como tempo de fila GAVG/cmd Latência média (ms) no guest. GAVG = DAVG +KAVG Rede MbRX/s, MbTX/s PKTRX/s, PKTTX/s %DRPRX, %DRPTX Quantidade de dados transmitidos por segundo Pacotes transmitidos por segundo Pacotes descartados por segundo para o Microsoft Exchange Server 76 76

77 Principais métricas para monitorar Hyper-V O desempenho do Hyper-V pode ser monitorado com o Perfmon. A Tabela 22 mostra as principais métricas para monitorar hosts e máquinas virtuais do ambiente ESXi. Tabela 22. Principais métricas para monitorar hosts e máquinas virtuais Hyper-V Recurso Medição Descrição CPU \Processador(*)\% de tempo do processador \Processador lógico do hipervisor Hyper- V(_Total)\% total de tempo de execução Tempo de ocupação da CPU Menos de 60% consumido = íntegro 60% - 89% consumido = monitorar ou cuidado 90% - 100% consumido = crítico, o desempenho será afetado negativamente Memória Disco Rede \Memória\Mbytes disponíveis \Memória\páginas/s \Disco lógico(*)\média de s/leitura, \Disco lógico(*)\média de s/gravação \Interface de rede(*)\total de bytes/s A quantidade de memória física disponível para o host Hyper-V 50% de memória livre disponível ou mais = íntegro 25% de memória livre disponível = monitorar 10% de memória livre disponível = advertência Menos de 5% de memória livre disponível = crítico, o desempenho será afetado negativamente Mede a frequência na qual as páginas são lidas ou gravadas no disco para resolver falhas em páginas fixas. Menos de 500 íntegro = monitorar ou cuidado Mais de = crítico, o desempenho será afetado negativamente Latência de leitura e gravação. 1 ms a 15 ms = íntegro 15 ms a 25 ms = advertência ou monitorar 26 ms ou mais = crítico, o desempenho será afetado negativamente A porcentagem de utilização de rede Menos de 40% da interface consumida = íntegro 41% - 64% da interface consumida = monitorar ou cuidado 65% - 100% da interface consumida = crítico, o desempenho será afetado negativamente Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 77 77

78 Recurso Medição Descrição Interface de rede(*)\compriment o da fila de saída O comprimento da fila de saída mede o número de threads que estão aguardando no adaptador de rede0 = íntegro 1-2 = monitorar ou cuidado Mais de 2 = crítico, o desempenho será afetado negativamente Para obter informações detalhadas sobre a implementação do hyper-v, consulte o Virtualizing SQL Server 2008 using VNX Series and Microsoft SQL Server 2008 R2 Hyper-V White Paper. Ferramentas no nível do cache de armazenamento/s ervidor Unisphere Analyzer O Unisphere Analyzer é uma ferramenta de monitoramento do desempenho para storage arrays. Essa ferramenta não só mostra o desempenho específico do armazenamento como também coleta e mostra algumas informações no nível do servidor e da máquina virtual. Para obter mais detalhes, consulte o Unisphere Unified Storage Management Solution White Paper. XtremSW Cache Performance Predictor O XtremSW Cache Performance Predictor é uma ferramenta que pode ser usada para calcular os benefícios da implementação do XtremSW Cache em um ambiente específico. A ferramenta é executada em duas etapas: 1. Coleta de dados no lado do host usando ferramentas de coleta de rastreamento comuns. 2. Análise do rastreamento em um host ou em qualquer laptop que atenda aos requisitos do sistema. A ferramenta simula a maneira como o XtremSW Cache funciona e gera o arquivo de saída em PDF. Não é necessário adquirir nenhuma placa nem software para executar essa ferramenta gratuita, que pode ser executada em todos os sistemas operacionais compatíveis com o XtremSW Cache (Windows e Linux). Ela cria um conjunto de quadros e gráficos para mostrar se o XtremSW Cache pode beneficiar o ambiente e, em seguida, calcula o aprimoramento do desempenho com base em: Tempo de resposta observado do host Capacidade usada pelo host Nível de skew para o Microsoft Exchange Server 78 78

79 A Figura 21 mostra o conjunto de desempenho e a configuração de cache de um exemplo de PDF de resultado da ferramenta. Figura 21. Exemplo de resultado do XtremSW Cache Performance Predictor: coleta de dados de desempenho Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 79 79

80 A Figura 22 mostra a saída da ferramenta e a distribuição de I/O do disco. É possível usar essas informações para definir o tamanho da página e o tamanho máximo de I/O do XtremSW Cache real para um melhor desempenho se necessário (o padrão para tamanho de página é 8 KB e o tamanho máximo de I/O é de 64 KB). Figura 22. Exemplo de resultado do XtremSW Cache Performance Predictor: Distribuição de tamanho de I/O A Figura 23 mostra a análise de leitura de cache. Se a ferramenta fornecer uma taxa de acesso ao cache muito alta, o dispositivo sob carga é um bom candidato para aceleração do XtremSW Cache. Figura 23. Exemplo de resultado do XtremSW Cache Performance Predictor: previsão do acesso ao cache para o Microsoft Exchange Server 80 80

81 A Figura 24 mostra uma estimativa da melhoria do desempenho que o disco pode obter com a aceleração do XtremSW Cache. Este é um resultado simulado e serve como uma boa referência de como o aplicativo se beneficiará da aceleração do XtremSW Cache. Figura 24. Exemplo de resultado do XtremSW Cache Performance Predictor: previsão de latência de disco O XtremSW Cache Performance Predictor deve ser usado como uma ferramenta de planejamento ao projetar o XtremSW Cache tendo-se em vista o melhor desempenho. Storage Configuration Advisor O Storage Configuration Advisor é uma nova Suíte SRM (Storage Resource Management) que oferece um dos mais completos sistemas de gerenciamento de aplicativos a armazenamento do setor, proporcionando uma percepção comum do gerenciamento no nível do serviço, das prioridades e das tarefas à medida que os clientes criam sua infraestrutura em nuvem. O pacote SRM combina os produtos ProSphere, Storage Configuration Advisor e o recém-adquirido Watch4net em um só pacote facilmente consumível de monitoramento e geração de relatórios. Esse pacote oferece desempenho, capacidade e gerenciamento de configuração em escala para a e seleciona storage arrays de terceiros, para file e block. O Storage Configuration Advisor proporciona as seguintes vantagens: Gerenciamento de políticas de práticas recomendadas O Storage Configuration Advisor fornece modelos incorporados em torno das práticas recomendadas comuns do setor, a fim de permitir que você defina e modifique as políticas que se alinham aos requisitos operacionais. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 81 81

82 Rastreamento de alterações O Storage Configuration Advisor gera alertas quando ocorrem problemas que colocam níveis de serviço em risco por meio do rastreamento de alterações contínuo e a validação de configuração. Análise da configuração O Storage Configuration Advisor valida o alinhamento da infraestrutura com políticas organizacionais e práticas recomendadas do setor a fim de vincular os problemas de configuração a alterações associadas. Validação da matriz de suporte da O Storage Configuration Advisor baixa automaticamente a matriz de suporte da e verifica a conformidade da SAN com as recomendações do E-Lab. A Figura 25 mostra o painel de controle do Storage Configuration Advisor. Figura 25. Interface do Storage Configuration Advisor para o Microsoft Exchange Server 82 82

83 O painel de controle do Storage Configuration Advisor fornece um snapshot de alto nível da quantidade e do impacto da alteração no ambiente, conforme mostrado na Figura 26. Figura 26. Painel de controle do Storage Configuration Advisor. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 83 83

84 Apêndice C: Ferramentas de geração de carga de trabalho do SQL Server Visão geral Em geral, é recomendável testar uma carga de trabalho em uma nova plataforma de computação, rede ou armazenamento antes de migrar a carga de trabalho de produção. A Tabela 23 destaca algumas ferramentas normalmente usadas para validar subsistemas de armazenamento para o SQL Server. Obs.: investigue os conjuntos de ferramentas específicos dos aplicativos antes de selecionar os conjuntos específicos do SQL ou de armazenamento destacados na Tabela 23. Por exemplo, você pode usar o Microsoft VSTS (Visual Studio Team Test System) para simular cargas de trabalho SharePoint completas, inclusive o componente SQL Server. Tabela 23. Ferramentas comuns para validação do subsistema de armazenamento SQL Server Ferramenta Benefícios Desvantagens SQL Profiler IOMeter SQLIO Duplica, com precisão, a carga de trabalho SQL Simula o skew Enfatiza a CPU e a memória Simples de configurar Capacidade de ajuste Aleatório/sequencial Taxa de leitura/gravação Não exige conhecimento de DBA Pode sobrepor cargas de trabalho que não sejam SQL (como backups) Fácil de configurar Revela, com rapidez, os limites da infraestrutura Relativamente complexo Requer conhecimento de DBA para ser executado Exige privilégio de administrador SQL Dificuldade de replicar o skew Dificuldade de medir sequencialmente Não enfatiza a CPU com precisão Não pode aproximar as cargas de trabalho de produção Não enfatiza a CPU com precisão SQLIOSim Testa a estabilidade de I/O Não pode validar o desempenho do subsistema de disco Quest BenchMark factory Pode simular cargas de trabalho do tipo TPCC, TPCE e TPCH Uma ferramenta completa, comercialmente compatível, que também fornece assistência técnica Uma carga de trabalho simulada que trabalha com o SQL Server de maneira que todos os recursos do sistema sejam testados Taxa de licença alta A instalação e a configuração da ferramenta são demoradas É necessário instalar o SQL Server no servidor para testá-la para o Microsoft Exchange Server 84 84

85 Introdução às ferramentas SQL Server Profiler O SQL Server Profiler é o método mais preciso disponível para replicar uma carga de trabalho. Os administradores de banco de dados podem usar o SQL Server Profiler para capturar rastreamentos e reproduzi-los em um sistema autônomo. A principal desvantagem é que as cargas de trabalho em camadas ocorrem fora do contexto do SQL Server (como backups). Você pode usar o Microsoft SQL Server Profiler para capturar as instruções Transact-SQL enviadas ao SQL Server e os conjuntos de resultados do SQL Server para essas instruções. Para obter informações sobre como usar o SQL Server Profiler, consulte o artigo sobre o SQL Server Profiler site Microsoft MSDN. IOMeter O IOMeter é uma ferramenta de código aberto usada para medir o desempenho da I/O do disco. Com o IOMeter, o administrador pode criar, com rapidez, um ou mais trabalhadores que simulem uma carga de trabalho personalizada. Em geral, a carga de trabalho é medida com um monitor de desempenho ou uma ferramenta baseada em array. As desvantagens são a dificuldade de medir (e, dessa forma, replicar) as características de desempenho do armazenamento, como o skew e sequencialmente, componentes com muita pressão no lado do servidor, como a CPU e a memória. O site IOMeter apresenta detalhes. SQLIO A ferramenta SQLIO foi desenvolvida pela Microsoft para avaliar a capacidade de I/O de uma determinada configuração. Como sugere o nome da ferramenta, o SQLIO é um recurso valioso para medir o impacto da I/O do sistema de arquivos no desempenho do SQL Server. O SQLIO é uma ferramenta útil para verificar, com rapidez, os limites de leitura e gravação de um subsistema de disco. Ela compartilha as mesmas desvantagens do IOMeter, mas é bem menos configurável. O SQLIO pode ser executado de maneira a criar uma I/O sequencial ou aleatória, uma I/O de bloco pequeno ou grande e uma I/O de leitura ou gravação, mas não simultaneamente. Por exemplo, usar o IOMeter para recriar uma carga de trabalho de banco de dados que gere I/Os de 32 KB, 80% aleatórias com uma proporção de leitura/gravação de 75:25 é trivial, enquanto que usar o SQLIO para fazer o mesmo é impossível. Você pode baixar o SQLIO em SQLIOSim O SQLIOSim é uma ferramenta projetada para verificar a estabilidade e não o desempenho de um subsistema de I/O. A ferramenta é útil para verificar a conectividade completa e a estabilidade antes ou após a implementação quando há suspeita de falhas no subsistema do disco ou na rede de armazenamento. Para obter detalhes e baixar o SQLIOSim, consulte o site da Microsoft: Quest Benchmark Factory O Quest Benchmark Factory está disponível para gerar bancos de dados e cargas de trabalho para bancos de dados, inclusive o banco de dados SQL Server. Essa ferramenta fornece cargas de trabalho TPCC, TPCE e TPCH com registro do desempenho para cargas de trabalho específicas em execução. A assistência técnica está disponível quando se adquire a licença. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 85 85

86 Apêndice D: Projetos de armazenamento de exemplo e arquiteturas de referência Visão geral A última etapa da fase de implementação da pré-produção do SQL Server é validar o armazenamento para a configuração correta e manutenção das cargas compatíveis. As arquiteturas de referência da e os white papers sobre o projeto do armazenamento do SQL Server estão disponíveis no site da e no site da Microsoft. Este exemplo demonstra um projeto detalhado para armazenamento multinível da carga de trabalho OLTP do SQL Server em um ambiente em nuvem maior em sistemas de armazenamento VMAX e outros aplicativos. Para obter detalhes, consulte o Virtual Infrastructure for Microsoft Applications White Paper. Projeto de armazenamento do Microsoft SQL Server no VMAX com FAST VP Para manter a flexibilidade, o desempenho e a granularidade da recuperação, verifique se o dimensionamento do armazenamento e a configuração de backend do SQL são os ideais. Esta seção fornece o dimensionamento do SQL Server em uma configuração do FAST VP. Fase 1 Coletar os requisitos do usuário A Tabela 24 apresenta a configuração do SQL que atende aos requisitos do usuário. Tabela 24. Requisitos do usuário para a configuração do SQL Item Número total de usuários Equipamento do usuário Usuários do banco de dados por servidor ; ; respectivamente Total de IOPS Número de bancos de dados 3 Perfil de banco de dados RPO RTO Ativo/dinâmico/inativo Remoto < 5 minutos, local = 6 horas 60 minutos Proporção de leitura/gravação 85:15 Backup/restauração necessários Sim (VSS de hardware) Fase 2 Projetar a arquitetura de armazenamento com base nos requisitos do usuário A recomenda calcular os discos para o SQL Server a fim de satisfazer os requisitos de I/O e, em seguida, calcular os requisitos de espaço. O cálculo a seguir é do dimensionamento para esta solução. para o Microsoft Exchange Server 86 86

87 Cálculo de IOPS Calcule a IOPS da seguinte forma: A I/O total para usuários é % = = IOPS Calcule a I/O de back-end para os requisitos da política do FAST VP para cada nível. Neste exemplo, o dimensionamento do FAST VP é baseado no skew da I/O de 75% SATA, 15% FC e 10% flash: Total de I/O de back-end para RAID 1/0 SATA = (10% de 7.200) = (720 0,85) + 2 (720 0,15) = 828 Total de I/O para RAID 5 FC = (15% de 7,200) = ( ,85) + 4( ,15) = 1,566 Total de I/O para RAID 5 flash = (75% de 7.200) = ( ,85) + 4 ( ,15) = 7,308 O total final de I/O de back-end equivale a Os discos SATA necessários para atender a 808 I/O em uma configuração de RAID 1/0 são 828/50= ~17 arredondado para 18 para RAID 1/0 Os discos FC necessários para atender a I/Os em uma configuração de RAID 5 são / 130= ~12 Os discos Flash necessários para atender a I/Os em uma configuração de RAID 5 são 7.308/1800= ~4 Obs.: no cálculo do desempenho, o nível mais rápido precisa atender ao número máximo de I/Os. Da perspectiva de dimensionamento de I/O, usando as configurações da política mencionadas acima, os seguintes discos seriam necessários para o ambiente: Dezoito drives SATA de 7.200, 2 TB Doze drives FC de 10.00, 600 GB Quatro flash drives de 200 GB Cálculo de capacidade Tamanho do banco de dados de usuário Ativo é 200 GB Dinâmico é 300 GB Inativo é 600 GB Calcule o tamanho da LUN do banco de dados com base nos tamanhos de banco de dados de usuário: Tamanho da LUN do banco de dados = <Tamanho do banco de dados> + Requisito de porcentagem de espaço livre x (20%) Ativo é % = 360 GB Dinâmico é % = 480 GB Inativo é % = 840 GB Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 87 87

88 Calcule os tamanhos do banco de dados temporário e de registro para cada um dos bancos de dados. Os tamanhos do registro e do banco de dados temporário são calculados como 20% do tamanho do banco de dados: Tamanho do registro e do banco de dados temporário O banco de dados ativo é 20% de 300 = 60 GB O banco de dados dinâmico é 20% de 400 = 80 GB O banco de dados inativo é 20% de 700 = 140 GB O registro do banco de dados de usuário e o banco de dados temporário são colocados em LUNs separadas para cada banco de dados. Com base nisso, as LUNs de registro são dimensionadas em 120 GB para os bancos de dados ativos e dinâmicos, e 140 GB para os bancos de dados inativos: O tamanho total do banco de dados é a soma dos bancos de dados = GB A capacidade utilizável disponível por drive SATA de 2 TB é GB A capacidade utilizável disponível por drive FC de , 600 GB é 536 GB O skew da política FAST usado é o total de 75% SATA, 15% FC e 10% flash Capacidade de cada nível: SATA = ,75 = GB FC = ,15 = 368 GB Flash = ,1 = 245 GB Requisito de disco é <Capacidade total> / <Capacidade utilizável> Discos necessários para cada nível: SATA (espelhado) = 4 FC (RAID5 3+1) = 4 Flash (RAID5 3+1) = 4 Obs.: no cálculo da capacidade, o nível mais lento precisa hospedar a maior parte dos dados. Da perspectiva de dimensionamento da capacidade, usando as configurações da política mencionadas acima, os seguintes discos são necessários para o ambiente: Quatro drives SATA de 7.200, 2 TB Quatro drives FC de , 600 GB Quatro flash drives de 200 GB para o Microsoft Exchange Server 88 88

89 A melhor configuração é baseada nos requisitos de I/O e capacidade, conforme mostrado na Tabela 25. Tabela 25. Práticas recomendadas de configuração baseadas nos requisitos de capacidade e I/O Banco de dados SQL Server de 1 TB (200 GB, 300 GB, 500 GB) Número de discos necessários para satisfazer a I/O e a capacidade Tamanhos de thin-lun (banco de dados) Tamanhos de thin-lun (registro) 18 drives STA de 7.200, 2 TB 12 drives FC de , 600 GB 4 flash drives de 200 GB Ativo é 360 GB Dinâmico é 480 GB Inativo é 840 GB Ativo é 120 GB Dinâmico é 120 GB Inativo é 140 GB Abordagem de projeto de componente básico para o data warehouse Esta solução descreve um armazenamento de projeto de componente básico de um data warehouse para flexibilidade e capacidade de expansão do desempenho. Para obter detalhes, consulte o SQL Server 2012 Data Warehouse White Paper. Considerações sobre os componentes básicos A infraestrutura que dá suporte ao data warehouse, inclusive o servidor, a rede, o armazenamento e o aplicativo, deve oferecer uma solução robusta, avançada e flexível. Este projeto é para data warehouses em um ambiente virtualizado que proporciona um desempenho previsível. Você deve considerar os critérios a seguir para este projeto. Largura de banda proporcional e preditiva Projete tendo em vista a largura de banda e não a capacidade do banco de dados. Neste exemplo, para atingir a conclusão de todas as consultas DSS no pacote de teste em uma janela de 12- a 14-horas, a largura de banda desejada é 100 MB/s para um banco de dados de 500 GB, 200 MB/s para um banco de dados de 1 TB ou 400 MB/s para um banco de dados de 2 TB. Verificar o desempenho do disco. Para uma carga de trabalho DSS com uma I/O sequencial de somente leitura de 64 K, os discos SAS de 10 K, 600 GB, usados neste exemplo fornecem IOPS média de 320 e largura de banda de 20 MB/disco. A largura de banda pode ser calculada para um determinado tamanho de I/O com a IOPS: Largura de banda = tamanho médio de I/O IOPS Calcular os requisitos de armazenamento de componente básico. Com uma carga de trabalho DSS de I/O de somente leitura, em uma configuração de RAID 5 ( 4+1), os discos SAS de , 600 GB necessários seriam: Número de discos = largura de banda necessária/largura de banda por disco Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 89 89

90 Para o componente básico de 500 GB com largura de banda de 100 MB/s, seriam necessários cinco discos SAS de , 600 GB. Para um componente básico de banco de dados de 1 TB com 200 MB/s de largura de banda, seriam necessários 10 discos. Para um componente básico de 2 TB com 400 MB/s de largura de banda, seriam necessários 20 discos. Capacidade de expansão da máquina virtual Os requisitos de capacidade de expansão da máquina virtual são: Os recursos da máquina virtual, inclusive vcpu e alocação de memória, devem fazer parte do componente básico. O componente básico deve permitir o dimensionamento vertical (inclusão de um componente na mesma máquina virtual) e o scale out (inclusão do componente básico em outra máquina virtual), tudo com o mínimo de degradação do desempenho. Recursos suficientes Verifique se o projeto de componente básico dos discos e da memória é usado de maneira suficiente da seguinte forma: A utilização do disco usa, de maneira suficiente, o recurso do disco com espaço para qualquer atividade possível de pico do disco. A utilização da memória do sistema dá suporte à carga de trabalho projetada com as atividades de pico de carga previstas. A utilização do processador da vcpu dá suporte à carga de trabalho projetada e todas as atividades de pico de carga previstas. O projeto do banco de dados temporário tem capacidade e desempenho suficientes para dar suporte à carga de trabalho de consultas do banco de dados. A carga de trabalho DSS tem alta demanda relativa para o banco de dados temporário. Utilização balanceada do disco Crie LUNs de banco de dados no máximo de barramentos possível para evitar uma carga de trabalho não balanceada. Essa alocação pode gerar benefícios de alta disponibilidade. Detalhes sobre os componentes básicos Os componentes básicos listados aqui são projetados da seguinte maneira: A largura de banda planejada é 100 MB/s por LUN (R5 4+1 discos SAS de , 600 GB). Use mais discos para o componente básico se desejar uma largura de banda maior. Neste exemplo, o tamanho do banco de dados dimensionado para cada LUN (R5 4+1) é 500 GB. Para um banco de dados de 1 TB, duas LUNs (10 discos) são criadas para os arquivos do banco de dados. Para um banco de dados de 2 TB, quatro LUNs (20 discos) são criadas. Para dar suporte à largura de banda planejada de 100 MB/s por LUN, atribua, no mínimo, duas vcpus e 8 GB de memória proporcionalmente ao componente básico. Ou uma vcpu e 4 GB de memória por 50 MB/s de largura de banda. para o Microsoft Exchange Server 90 90

91 A Figura 27 mostra os três componentes básicos usados neste exemplo com base neste princípio de projeto. A Tabela 26 lista os detalhes para os três componentes básicos. Figura 27. Tabela 26. Três componentes básicos testados As configurações dos componentes básicos Configuração Componente básico de 500 GB Componente básico de 1 TB Componente básico de 2 TB Tamanho do banco de dados Largura de banda planejada (MB/s) Projeto de LUN do banco de dados Projeto de registro Projeto do banco de dados temporário Configuração de disco 500 GB 1 TB 2 TB LUN de dados de 2 TB 8 arquivos de dados de 80 GB 1 LUN de registro (arquivo de registro de 5 GB de tamanho) 1 LUN de dados (1 arquivo de dados de 100 GB) 1 LUN de registro (2 arquivos de registro de 2 GB) 2 LUNs de dados de 2 TB 8 arquivos de dados de 126 GB 1 LUN de registro (arquivo de registro de 12 GB de tamanho) 1 LUN de dados (2 arquivos de dados de 100 GB) 1 LUN de registro (2 arquivos de registro de 2 GB) 4 LUNs de dados de 2 TB 16 arquivos de dados de 126 GB 1 LUN de registro (arquivo de registro de 12 GB de tamanho) 1 LUN de dados (4 arquivos de dados de 100 GB) 1 LUN de registro (2 arquivos de registro de 2 GB) 5 discos SAS 10 discos SAS 20 discos SAS Memória (GB) vcpu (2,4 GHz) Obs.: as LUNs de registro em um ambiente de data warehouse não são extremamente utilizadas, portanto, vários componentes básicos na mesma máquina virtual podem compartilhar a mesma LUN de registro. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 91 91

92 A Tabela 27 define os requisitos mínimos para os componentes básicos e as máquinas virtuais neste exemplo. Tabela 27. Projeto de componente básico por máquina virtual Memória (GB) CPU (núcleo) Número de discos RAID 5(4+1) Mínimo /TB /(100 MB/s) GB (100 MB/s) TB (200 MB/s) TB (400 MB/s) TB (800 MB/s) TB (800 MB/s) Implementando componentes básicos A Figura 28 mostra as duas maneiras de implementar componentes básicos: Projeto de dimensionamento vertical que coloca os componentes básicos na mesma máquina virtual. Projeto de scale-out que coloca os componentes básicos em outra máquina virtual. Figura 28. Componentes básicos de dimensionamento vertical e scale-out Projeto de dimensionamento vertical Com o projeto de dimensionamento vertical, é possível economizar o custo da licença do SO. para o Microsoft Exchange Server 92 92

93 Como as vcpus e os recursos de memória são incorporados no projeto modular, esses recursos crescem proporcionalmente com a implementação dos componentes básicos para as mesmas máquinas virtuais necessárias para dar suporte ao componente básico em questão. Projeto de scale-out Em uma implementação de componentes básicos, a vcpu e a capacidade da memória do servidor ESXi deve ser considerada para dar suporte ao número de componentes básicos desejados. Os recursos do sistema, como vcpu e memória, estão no componente básico. Adicionar um componente básico a um dimensionamento vertical (à mesma máquina virtual) ou scale-out (a uma máquina virtual separada) requer os mesmos recursos, a menos que seja construído abaixo do requisito mínimo para uma máquina virtual. Dessa maneira, quando há componentes básicos pequenos (como um banco de dados com menos de 1 TB e 200 MB/s de largura de banda), talvez seja melhor usar o modelo de dimensionamento vertical para reduzir o desperdício de recursos do sistema da máquina virtual, como memória e CPU. Em um ambiente médio, como o desta solução, as organizações devem considerar cuidadosamente a abordagem mais adequada para elas. Projeto de alocação de LUNs e máquinas virtuais SQL Server A Tabela 28 e Figura 29 mostram a configuração de máquina virtual e atribuição de discos para diferentes bancos de dados usados neste exemplo. Tentamos várias maneiras de projetar e implementar um componente básico com desempenho razoável. Figura 29. Implementação de componentes básicos da solução Obs.: em uma das máquinas virtuais, cinco bancos de dados com vários requisitos de tamanho e largura de banda estavam executando cargas de trabalho pesadas simultaneamente. Dessa maneira, eles disputariam recursos e poderiam ter contenções no horário de pico. Mesmo nesse caso, o SQL Server na máquina virtual mantém um bom desempenho. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 93 93

94 Tabela 28. Implementação de componentes básicos na máquina virtual e no servidor ESXi Host Alocação CPU (núcleo) ESXi 01 (40 núcleos, 256 GB de RAM) Memória (GB) Tamanho do banco de dados (TB) Número de discos Largura de banda (MB/S) VM VM ESXi 02 (80 núcleos, 512 GB de RAM) VM , , VM Total 4 máquinas virtuais de novembro Solução de proteção do SQL Server Esta solução implementou uma proteção contínua para o SQL Server usando o RecoverPoint com Replication Manager e vcenter SRM. Para obter detalhes, consulte Continuous Data Protection for Microsoft SQL Server Enabled by RecoverPoint, Replication Manager, and VMware White Paper. RecoverPoint Esta seção descreve a configuração necessária para o RecoverPoint ao implementar a proteção. Processo de replicação local (CDP) A Figura 30mostra o processo RecoverPoint CDP (Continuous Data Protection) que replica, de maneira síncrona, os dados dos volumes de produção (origem) nos volumes de destino locais, enquanto mantém a recuperação reversível por meio do armazenamento de registro em diário. para o Microsoft Exchange Server 94 94

95 Figura 30. Fluxo de dados da replicação local RecoverPoint (CDP) Processo de replicação remota (CRR) A Tabela 22 mostra o processo RecoverPoint CRR (Continuous Remote Replication) que replica blocos de dados em um storage array de local remoto. Os dados são replicados de maneira síncrona por uma conexão Fibre Channel de 200 kms/ 4 ms ou assíncrona, por uma conexão IP que, neste exemplo, foi testada em 64 ms/6.400 km, ida e volta. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 95 95

96 A Figura 31 mostra uma comparação entre os processos CDP e CRR com replicação RecoverPoint remota. Figura 31. Tabela 29. Fluxo de dados da replicação remota RecoverPoint (CRR) Os processos CDP e CRR para replicação local e remota RecoverPoint: Operações Uma gravação na LUN protegida pelo RecoverPoint O divisor divide a gravação Reconhecimento Gravações do carimbo de data e hora e bookmarks no registro Fluxo de dados CDP (replicação local RecoverPoint) Gravação interceptada pelo divisor RecoverPoint. Envia-a simultaneamente para o volume de produção e o RPA local As gravações são reconhecidas do RPA e da LUN de produção imediatamente. O RPA grava os dados no volume de registro, juntamente com metadados de carimbo de data e bookmarks. Fluxo de dados CRR (replicação remota RecoverPoint) Gravação interceptada pelo divisor RecoverPoint. Envia-a simultaneamente para o volume de produção e o RPA local. Replicação assíncrona: As gravações são reconhecidas do RPA e da LUN de produção imediatamente. Replicação remota síncrona: O reconhecimento (ACK) é feito quando a gravação é recebida no local remoto. O RPA local une a gravação às outras gravações, sequências e carimbos de data. O pacote é compactado e transmitido com um checksum para entrega por IP ao RPA remoto. para o Microsoft Exchange Server 96 96

97 Operações Concluído Fluxo de dados CDP (replicação local RecoverPoint) N/D N/D Depois que os dados são armazenados com segurança no registro, os dados com consistência de ordem de gravação são distribuídos na réplica local. Fluxo de dados CRR (replicação remota RecoverPoint) O RPA remoto recebe o pacote, verifica o checksum para garantir que não tenham ocorridos danos na transmissão e descompacta os dados. O RPA remoto grava os dados no volume de registro. Depois que os dados são gravados no volume de registro, eles são distribuídos para os volumes remotos. A ordem de gravação é preservada durante essa distribuição. Grupos de consistência Grupo de consistência é um container lógico no RecoverPoint que garante que todos os dispositivos dentro desse grupo estejam consistentes (fidelidade à ordem de gravação) entre si. O RecoverPoint versão 3.3 dá suporte a até 128 grupos de consistência. Para máquinas virtuais SQL Server, as políticas Resource Allocation Priority são definidas com base nos requisitos de volume: OS/Page File o sistema operacional e os volumes de arquivos de página com relacionamento natural são mantidos juntos. Com uma taxa de alteração muito baixa, a política Resource Allocation Priority é definida como Normal. Banco de dados temporário/bancos de dados de sistema banco de dados temporário e bancos de dados de sistema são replicados para ativar todas as máquinas virtuais no local remoto. Então, como o banco de dados de sistema não é tão alterado e o banco de dados temporário é recriado sempre que a instância do SQL Server é reiniciada, isso pode ser descartado, então, defina Resource Allocation Priority como Low. Dados/registros os dados do usuário são os mais importantes do ambiente, então, defina Resource Allocation Priority como Critical. A Figura 32 mostra o relacionamento entre os volumes Windows NTFS, seus grupos de consistência relevantes e as configurações da política de grupo de consistência que foram definidas para as políticas locais e remotas. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 97 97

98 Figura 32. Volumes Windows para mapeamento de grupos de consistência RecoverPoint Ao usar CLR para cada grupo de consistência, foram configurados três registros: dois no local de produção para dar suporte a CDP e CRR e um no local de recuperação para CRR. Conjuntos de grupos O recurso RecoverPoint Group Sets permite bookmarking consistente em vários grupos de consistência. É possível executar um conjunto de grupos para conter grupos de consistência para uma só máquina virtual. Para acessar uma cópia dos dados replicados, ative Image Access em cada grupo de consistência pelo tempo necessário (Figura 33). Os três grupos de consistência são revertidos para a mesma imagem de destino para garantir que os volumes no local de recuperação de desastres sejam máquinas virtuais TPCE1 totalmente consistentes e que o servidor possa ser reiniciado em um estado consistente com falhas. Figura 33. RecoverPoint Management Console grupos de consistência para o Microsoft Exchange Server 98 98

99 Dimensionamento do registro janelas de proteção Uma consideração crítica é o dimensionamento dos registros do RecoverPoint. Eles precisam ter características de desempenho e capacidade para lidar com o desempenho total das gravações e armazenar todas as gravações da LUN que estiver sendo protegida. As duas perguntas mais importantes são: Qual taxa de alteração a LUN de origem gera? Qual janela de retenção é necessária? Para calcular a capacidade de registro, a taxa de alteração deve ser medida nas LUNs de produção. Os contadores Perfmon são definidos em cada SQL Server para capturar a largura de banda de gravação em MB/s (megabytes por segundo). É possível determinar os dados por segundo com o Unisphere Analyzer, enquanto a guia Stats fornece uma janela point-in-time para ver o que cada controladora de armazenamento está fazendo. A fórmula de dimensionamento do volume de registro é: Tamanho do registro = (Dados por segundo) (Tempo de reversão necessário em segundos) (1 tamanho do registro do lado de destino) x % do registro devem ser reservados para o registro do lado de destino e 5%para as necessidades internas do sistema. Por exemplo, para dar suporte a um requisito de reversão de 24 horas ( segundos), com 5 Mb/s (megabits por segundo) de novas gravações de dados nos volumes de replicação em um grupo de consistência, o cálculo é: = MB = GB (~70 GB) (1 0.2) x 1.05 Para a solução, todos os registros foram dimensionados para ativar o RecoverPoint para fazer a reversão de, pelo menos, sete dias. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento para o Microsoft Exchange Server 99 99

100 Integrando o RecoverPoint com VMware vcenter A exibição vcenter Servers exibe dados do vcenter Server por meio da interface gráfica do usuário do RecoverPoint. Além de exibir os ESX Servers e todas suas máquinas virtuais, datastores e drives RDM, a exibição vcenter Servers também mostra o status de replicação de cada volume. O status de proteção de cada máquina virtual machine é medido várias vezes por hora. Essa janela é atualizada quando uma nova máquina virtual é criada ou o status de proteção de uma máquina é alterado. A exibição vcenter Servers destina-se apenas ao monitoramento (somente leitura). Por exemplo, conforme mostrado em Figura 34, o RecoverPoint Management Application indica que todos os volumes relevantes para TPCE1 e TPCH2 foram replicados com êxito. Os respectivos grupos de consistência, a cópia que está sendo replicada e os conjuntos de replicação associados são mostrados na Figura 34. Figura 34. Exibição vcenter Servers no RecoverPoint Management Application Failover do RecoverPoint Quando ocorre uma falha em uma máquina virtual, o processo de failover do RecoverPoint pode ser usado para fazer o failover a fim de ativar o local de recuperação de desastres. para o Microsoft Exchange Server

101 Figura 35. Processo de failover do RecoverPoint Neste cenário (conforme mostrado em Figura 35), use as seguintes etapas na Tabela 30 para o failover quando ocorrer uma falha em uma máquina virtual no local de produção. Tabela 30. Etapas de failover Processo de failover do RecoverPoint Habilite o acesso à imagem para o bookmark mais recente. Verifique se o failover está definido como a réplica remota. Verifique se o armazenamento remoto está totalmente acessível ao ESX Server. Registre a máquina virtual do local remoto. Inicie a máquina virtual. Detalhes Isso fornece acesso à imagem de leitura/gravação da cópia CRR para os ESX Servers remotos e permite a montagem dos volumes VMFS no vcenter remoto. No RecoverPoint Management Application ou no Unisphere Management Console, escolha failover to the remote replica. Verifique novamente todo o armazenamento no ESX Server remoto por meio do console do vcenter remoto. Clique com o botão direito do mouse no arquivo VMX no datastore VMFS da LUN do SO para registrar a máquina virtual e escolha Inventory the virtual machine. Conecte a vnic à rede para habilitar novamente o acesso IP à máquina virtual e ao banco de dados. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento 101 para o Microsoft Exchange Server 101

102 Você pode realizar failback encerrando a máquina virtual no local remoto e repetindo as etapas acima para o local de produção. Esta solução permite a total portabilidade de suas instâncias do SQL Server entre os locais. Sub-rede diferente Se estiver ocorrendo o failover da máquina virtual para um cluster vsphere em outra sub-rede (por exemplo, de x para x), será necessário criar um switch distribuído no cluster ESX de produção com as mesmas propriedades que o switch virtual distribuído real para o local de recuperação de desastres. Para configurar o failover para outra sub-rede, é necessário atribuir uma vnic no switch fictício para as máquinas virtuais SQL Server em produção. Conforme mostrado em Figura 36, um switch fictício é criado no vcenter Server do local de produção. Em seguida, a máquina virtual é configurada com uma segunda vnic no switch de recuperação de desastres virtual fictício. Isso permite que a máquina virtual faça failover perfeitamente para o local remoto sem nenhuma configuração de rede adicional para o local de recuperação de desastres. O switch de DR fictício, configurado para a segunda NIC na máquina virtual, permite o failover para outra sub-rede no lado de DR. Nenhuma NIC física é conectada a esse switch. Figura 36. A vnic é configurada e conectada Quando a máquina virtual fizer failover para o local de recuperação de desastres, essa NIC será conectada à rede especificada (sqluce1.com), conforme mostrado em Figura 37. Em seguida, a vnic do local de produção terá uma rede não identificada porque o switch de produção configurado no local de recuperação de desastres só estará presente para fins de configuração e não estará ativo na rede. para o Microsoft Exchange Server

103 Rede sqluce1.com O motivo disso é que uma NIC física está conectada ao switch DR no local de DR. Quando a máquina virtual PCE1 fizer failover para DR, ela se conectará ao domínio Figura 37. Local de recuperação de desastres conectado à rede sqluce1.com Replication Manager Esta seção descreve a configuração necessária para o Replication Manager ao implementar a proteção. Integrando o Replication Manager ao SQL Server Para dar suporte ao SQL Server, o Replication Manager usa a API de snapshot da VDI (Virtual Device Interface) do SQL Server para snapshots rápidos, on-line, consistentes com aplicativos, de bancos de dados SQL Server de classe empresarial, muito ativos, com sobrecarga insignificante de host. O Replication Manager permite que você execute as seguintes tarefas com uma interface simples, orientada por assistente: Especificar quais instâncias, bancos de dados e grupos de arquivos correspondentes serão replicados. Garantir que os dados possam ser replicados com segurança e rapidez. Restabelecer a operação normal do banco de dados depois de criar a réplica. Montar ou recuperar um banco de dados em outro host para outras operações, como testes, geração de relatórios ou data mining. Recuperar, com rapidez, um banco de dados no host de produção na ocorrência de danos nos dados. Conjuntos de aplicativos e tarefas para o Microsoft SQL Server O Replication Manager usa o conceito de conjuntos de aplicativos como containers para definir quais dados proteger (por exemplo, Banco de dados 1) e tarefas como uma maneira de proteger esses dados (por exemplo, imagem de bookmark do RecoverPoint). Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento 103 para o Microsoft Exchange Server 103

104 Consistência de aplicativos do Microsoft SQL Server Neste exemplo, as tarefas do Replication Manager foram configuradas para proteger os bancos de dados de usuário do SQL Server, definindo a opção Replica Type como Full, Online with advanced recovery using VDI. Essa opção replica todo o banco de dados e o registro de transações. Geralmente, esse tipo de réplica é usado quando ela é considerada um backup do banco de dados ou quando a réplica é montada para um produto de terceiros a fim de criar um backup do banco de dados. Para levar o banco de dados a um ponto no tempo que seja mais recente que a réplica, esse tipo de réplica permite que você restaure os registros de transações, supondo-se que você tenha feito backup desses registros de transações. O Replication Manager usa snapshots habilitados para VDI para criar esse tipo de réplica, garantindo dados consistentes com aplicativos. Obs.: os bancos de dados do sistema (master, MSDB e modelo) não devem ser localizados no mesmo volume que os bancos de dados de usuário. O Microsoft SQL Server não é compatível com a VDI, nem com a tecnologia de snapshots para restaurar bancos de dados de sistema. Configurando o Replication Manager para se comunicar com o vcenter e o RecoverPoint O Replication Manager pode replicar, montar e restaurar um datastore VMFS no nível da LUN. Não é necessário instalar o agente nem o software Replication Manager no servidor ESXi nem na máquina virtual. Todas as operações são executadas por meio do host proxy VMware do vcenter e do Replication Manager, que pode ser um host físico ou virtual. O host proxy deve ser registrado no servidor Replication Manager com as credenciais do gerenciamento do vcenter. O host proxy VMware do Replication Manager se comunica com o vcenter pela porta 443. O Replication Manager pode mapear os volumes VMFS associados às LUNs. O host proxy compartilha as mesmas máquinas virtuais que o servidor Replication Manager neste exemplo. O Replication Manager também pode detectar as LUNs replicadas pelo RecoverPoint. A comunicação com o RecoverPoint é efetuada por meio do agente do Replication Manager instalado nas máquinas virtuais montadas e de produção. Reassinatura do Logical Volume Manager A replicação VMFS exige que a reassinatura do LVM (Logical Volume Manager) seja habilitada nos servidores ESX montado e de produção. A reassinatura do LVM permite que a VMware grave uma nova assinatura nas LUNs, quando necessário. Esse switch deve ser habilitado para o Replication Manager de maneira que o VMFS possa se tornar visível para o ESX Server nas LUNs replicadas. Essa configuração também deve ser habilitada no ESX Server de produção a fim de efetuar a restauração para esse ESX Server a qualquer momento. O seguinte comando deve ser emitido nos ESX Servers usados para montar réplicas: esxcfg-advcfg -s 1/LVM/EnableResignature Para obter mais informações sobre esse tópico, consulte no Guia de Administradores do Replication Manager, a seção Configuração da VMWare. para o Microsoft Exchange Server

105 Detectando o appliance RecoverPoint e o storage array Esta solução usa o divisor RecoverPoint de armazenamento, o que permite ao storage array detectar o armazenamento RecoverPoint no Replication Manager. É necessário fornecer suas credenciais de armazenamento para concluir essa tarefa de detecção. Depois de configurar as credenciais para, ao menos, um agente de host do Replication Manager, uma operação de detecção do storage array também detecta o divisor RecoverPoint. Recuperando um banco de dados de usuário SQL Server Neste exemplo, a simulou um desastre de um banco de dados de produção ativo e testou a solução efetuando a recuperação para um ponto no tempo específico. Para o teste, é excluída uma tabela de um banco de dados OLTP às 14:16:00. Trata-se de uma tabela essencial para a funcionalidade do banco de dados, denominada Accounts Permissions Table. Os usuários não conseguem acessar os dados sem ela, então, às 14:16:00, a empresa na qual o banco de dados estava atendendo se torna inativa. Em seguida, o banco de dados inteiro foi excluído para simular um erro humano, e o banco de dados inteiro é perdido às 14:16:15. O Replication Manager é a única interface necessária para recuperar o banco de dados, porque ela coordena todas as operações em todos os níveis da pilha de soluções, inclusive o SQL Server, o Windows Server, o VMware, o armazenamento e o RecoverPoint, para administrar o processo de recuperação. A interface orientada por assistente é útil para recuperar um banco de dados transacional essencial aos negócios, garantindo a adesão a todas as práticas recomendadas para uma restauração bem-sucedida. Esta solução restaurou, com eficiência, o banco de dados de usuário com a cópia CRR do local remoto e ajustou o relógio para um segundo antes da ocorrência do desastre, às 14:15:59. O Replication Manager acessou uma imagem do banco de dados no momento exato especificado e recuperou o banco, o que resultou em um RPO de um segundo. A optou por recuperar todos os arquivos e grupos de arquivos do banco de dados. O Replication Manager levou 3 minutos e 26 segundos para terminar o processo de recuperação, deixando o banco de dados desconectado, o que permite ao DBA conectar o banco dados com a integridade garantida antes de permitir o acesso dos usuários. Uma vez conectado o banco de dados, os usuários on-line conseguiram acessar os dados às 14:21:45, e foi feito backup da unidade de negócios. Esta solução produziu um RPO de um segundo e um RTO de menos de quatro minutos. O nível de recuperação é extremamente poderoso, permitindo que você cumpra SLAs (Service Level Agreements, contratos de nível de serviço) rigorosos. Isso permite recuperar, com facilidade e rapidez, bancos de dados OLTP altamente transacionais e essenciais aos negócios, com o mínimo de etapas. SRM do VMware vcenter Esta seção descreve a configuração do SRM do VMware vcenter ao implementar a proteção. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento 105 para o Microsoft Exchange Server 105

106 Integrando o SRM do vcenter com o RecoverPoint O SRM do vcenter reduz o RTO de recuperação de desastres contando com a replicação baseada em bloco para reduzi-lo. O SRA do RecoverPoint é usado para mapear as solicitações de SRM do vcenter para as ações apropriadas do RecoverPoint. O SRM do vcenter e o RecoverPoint automatizam o processo de recuperação das máquinas virtuais, tornando-o tão simples quanto pressionar um botão. O usuário não interage com o console do RecoverPoint; em vez disso, o SRM do vcenter SRM automatiza todo o processo de failover. A integração entre o RecoverPoint e o SRM do vcenter é controlada pelo SRA (Storage Replication Adapter) do RecoverPoint. O RecoverPoint é responsável por replicar todas as alterações das LUNs de produção nas réplicas remotas no local de recuperação de desastres. O SRA do RecoverPoint é instalado nos mesmos servidores que estão executando o vcenter Server e o plug-in SRM do vcenter nos locais de produção e recuperação de desastres. O SRA do RecoverPoint dá suporte às funções do SRM do vcenter, como failover e testes de failover, usando o RecoverPoint para replicação. Configurando o grupo de consistência para o gerenciamento pelo SRM do vcenter Depois de criar o grupo de consistência e instalar o SRM do vcenter, é necessário configurar o grupo de consistência para ser gerenciado pelo SRM do vcenter. Para isso, use as configurações de políticas no RecoverPoint Management Application, conforme mostrado na Figura 38. Figura 38. Configurando o grupo de consistência para o gerenciamento pelo SRM do vcenter para o Microsoft Exchange Server

107 Proteção da solução SRM do vcenter Neste exemplo, o SRM do vcenter está protegendo as máquinas virtuais SQL Server. O Replication Manager é necessário no local de produção para proteção, montagem e restauração do local. O local de recuperação de desastres contém seus próprios servidores virtuais vcenter e Active Directory, portanto, não há necessidade de replicá-los. A Figura 39 mostra como o SRM do vcenter protege os SQL Servers usando a integração do RecoverPoint pela automatização das etapas necessárias. Figura 39. Procedimento de proteção do SRM do vcenter SRM para o local de produção O SRM do vcenter requer configuração nos locais de produção e recuperação. O local de produção requer a seguinte configuração: Conexão para estabelecer a comunicação do SRM do vcenter SRM entre os vcenter Servers Gerenciadores de array para detectar dispositivos replicados Mapeamentos de inventário para mapeamentos de pastas, rede e recursos específicos do local Grupos de proteção para organizar máquinas virtuais em seus respectivos datastores para recuperação O local de recuperação requer que você configure um plano de recuperação criando um runbook automatizado do processo de recuperação. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento 107 para o Microsoft Exchange Server 107

108 Configurando grupos de proteção do SRM do vcenter Grupo de consistência do RecoverPoint é um conjunto de dados dos volumes de armazenamento conectados a SAN nos locais de produção e recuperação de desastres. Grupo de proteção do SRM do vcenter é um grupo de máquinas virtuais que fazem failover juntas (durante o failover de teste ou real). Quando o SRM do vcenter realiza um failover, ele instrui o RecoverPoint a atuar nas LUNs de todas as máquinas virtuais do grupo de proteção. No entanto, o RecoverPoint usa grupos de consistência para definir grupos de LUNs que são replicadas juntas. Depois de configurar, com êxito, a conexão, os gerenciadores de array e os mapeamentos de inventário, é necessário configurar os grupos de proteção, conforme mostrado na Figura 40. Figura 40. Configuração de grupos de proteção no vsphere Client Para esta solução, foram criados quatro grupos de proteção, dois para cada máquina virtual TPCE e dois para as máquinas virtuais TPCH. Em cada grupo de proteção, você pode especificar a prioridade de recuperação para cada máquina virtual. Modificando a prioridade de inicialização de uma máquina virtual Talvez você não deseje que todas as máquinas virtuais sejam reiniciadas simultaneamente na recuperação. Assim sendo, a configurou as máquinas virtuais TPCE como alta prioridade, pois elas são mais importantes para os negócios (conforme mostrado na Figura 41), e deixou as máquinas virtuais TPCH em uma configuração de baixa prioridade. para o Microsoft Exchange Server

109 Figura 41. Selecionando a prioridade de recuperação das máquinas virtuais Personalizando os endereços IP do local de recuperação Ao fazer failover para outro datacenter, alguns ajustes são necessários nas configurações de IP do host devido a diferenças de infraestrutura. Ao fazer failover de uma configuração inteira, isso pode envolver a atualização das configurações de várias máquinas virtuais. O SRM do vcenter fornece um utilitário de personalização de IP em massa (dr-ipcustomizer.exe) para atualizar, de maneira automática, as configurações IP para máquinas virtuais recuperadas. O utilitário gera um arquivo CSV que contém as configurações de IP de todas as máquinas virtuais que estão configuradas para o failover do SRM do vcenter. Você pode editar esse arquivo para especificar as configurações de IP do local de recuperação e, em seguida, executar novamente o utilitário para carregar as novas configurações para o servidor vcenter do local de recuperação. Para esta solução, o utilitário foi usado para atualizar as configurações de IP do local de recuperação da seguinte maneira: 1. Faça log-on no servidor vcenter o local de recuperação. 2. Execute o utilitário dr-ip-customizer.exe e especifique o nome e o local para o arquivo CSV, conforme necessário. 3. Edite o arquivo CSV para fornecer as configurações de IP para as máquinas virtuais no local de recuperação. A imagem a seguir mostra o arquivo editado para esta solução. 4. Execute o utilitário para carregar as novas configurações para o servidor vcenter do local de recuperação, conforme mostrado. Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento 109 para o Microsoft Exchange Server 109

110 Obs.: se você excluir ou recriar um grupo de proteção, deverá repetir esse procedimento para reaplicar as personalizações de IP. Configurando os planos de recuperação do SRM do vcenter Os planos de recuperação estão localizados no local de recuperação e definem as etapas para recuperar máquinas virtuais. Os planos de recuperação do SRM do vcenter podem usar o recurso de acesso à imagem do RecoverPoint para testar o processo de failover sem causar interrupções. Dessa maneira, garante-se que a imagem secundária seja consistente e possa ser utilizada. Testando planos de recuperação de desastres para garantir que a recuperação seja confiável. Tradicionalmente, esse exercício era complexo, demorado e dispendioso. Com o SRM do vcenter, é possível superar esses obstáculos viabilizando testes realistas e frequentes dos planos de recuperação e eliminando as causas comuns de falhas durante a recuperação. Quando são incluídos vários grupos de proteção em um só plano de recuperação, todas as máquinas virtuais associadas se tornam disponíveis para recuperação como parte de um plano de recuperação único. A Figura 42 mostra a primeira etapa da execução do plano de recuperação. Figura 42. Executando o plano de recuperação Conforme mostrado na Figura 43, a máquina virtual priorizada está sendo recuperada (reiniciada) antes das outras máquinas no mesmo plano de recuperação. para o Microsoft Exchange Server

111 Figura 43. Priorizando a recuperação da máquina virtual Quando o processo de failover é concluído, o SRM do vcenter exibe um relatório resumido da recuperação, conforme mostrado na Figura 44. Figura 44. Relatório resumido do failover Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento 111 para o Microsoft Exchange Server 111

112 Configurando o failover do SRM do vcenter com o CLR do RecoverPoint Depois que o SRM do vcenter conclui o plano de recuperação com êxito e todos os sistemas voltam a funcionar, você deve completar as seguintes etapas manuais para retomar a replicação integral do CRR do local de recuperação de desastres para o local de produção: 1. Verifique se o grupo está no modo de manutenção e está sendo gerenciado pelo RecoverPoint, apenas com o monitoramento do SRM. 2. Defina a cópia da réplica remota do RecoverPoint como produção no local de recuperação de desastres, conforme mostrado na Figura 45. Figura 45. Definindo a cópia da réplica remota do RecoverPoint como a cópia de produção 3. Como o CDP também estava no local de produção antes do failover, remova uma das cópias de dados da réplica no local de produção, conforme mostrado na Figura 46. Figura 46. Removendo a réplica local para o Microsoft Exchange Server

113 Depois de definir a cópia do CRR como sua cópia de produção, será solicitado que você escolha uma cópia dos dados no local de produção para ser removida. Você deverá, então, decidir se usará a cópia de produção ou a cópia do CDP como o destino para o CRR, o que é feito removendo-se a cópia desnecessária, conforme mostrado na Figura 47. Figura 47. Removendo a cópia desnecessária dos dados Como parte de uma configuração do CLR do RecoverPoint, o local de produção anteriormente hospedava as cópias de produção e de dados do CDP. Essa nova configuração de replicação do RecoverPoint é CRR, portanto, é possível ter apenas uma cópia de destino dos dados no local de produção. Essas definições não afetam a recuperação das máquinas virtuais no local de recuperação de desastres. Elas são específicas do RecoverPoint e são necessárias para reconfigurar os novos relacionamentos do CRR no local de produção. Caso um desastre impeça o acesso ao local de produção, estas etapas não serão necessárias até que a comunicação com o local seja restabelecida. Se a comunicação com o local de produção ainda estiver disponível após a recuperação, será possível elaborar um script dessas etapas na CLI do RecoverPoint. Como parte de um failover controlado, esses comandos podem ser incluídos como uma operação pós-script no plano de recuperação do SRM do vcenter. O resultado da reconfiguração do grupo de consistência é uma replicação objetiva do CRR do RecoverPoint do local de recuperação de desastres para o local de produção, conforme mostrado na Figura 48. Figura 48. Reconfiguração do grupo de consistência Microsoft Exchange: Práticas recomendadas de armazenamento e Guia de Projeto para armazenamento 113 para o Microsoft Exchange Server 113