Alta disponibilidade nativa do Microsoft SQL Server com o XtremIO

Transcrição

1 Alta disponibilidade nativa do Microsoft SQL Server com o XtremIO Ampliando a funcionalidade do Microsoft SQL Server com o EMC XtremIO Storage Array RESUMO Este white paper examina a eficiência do armazenamento e o desempenho do Microsoft SQL Server ao usar os recursos AlwaysOn disponíveis com o Microsoft SQL Server 2012 & 2014 no EMC XtremIO Storage Array. Janeiro 2016 EMC WHITE PAPER

2 Para saber mais sobre como os produtos, serviços e soluções da EMC ajudam a resolver seus desafios de negócios e de TI, entre em contato com seu representante local ou revendedor autorizado, acesse nosso site brazil.emc.com ou explore e compare produtos na EMC Store. Copyright 2015 EMC Corporation. Todos os direitos reservados. A EMC 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 contidas nesta publicação são fornecidas no estado em que se encontram. A EMC 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 EMC descrito nesta publicação exigem uma licença de software. Para uma lista mais atualizada de produtos da EMC, consulte Produtos no site brazil.emc.com. Todas as marcas comerciais aqui mencionadas pertencem a seus respectivos proprietários. Número da peça H

3 ÍNDICE RESUMO EXECUTIVO... 5 Público-alvo... 5 INTRODUÇÃO... 5 Resultados... 5 ALTA DISPONIBILIDADE DO MICROSOFT SQL SERVER... 6 FCIs (Failover Cluster Instances, instâncias de cluster de failover) do AlwaysOn... 6 AlwaysOn Availability Groups (AAG)... 6 Modos de disponibilidade... 6 Escolhendo um modelo de proteção... 7 Capacidade do XtremIO para alterar o modelo de armazenamento não compartilhado... 8 CONFIGURAÇÕES DE ARQUITETURA DO ALWAYSON... 9 Instâncias de cluster de failover do AlwaysOn com Snapshots graváveis do XtremIO... 9 Soluções de replicação bidirecional do AlwaysOn com Snapshots graváveis do XtremIO Instância de cluster de failover do AlwaysOn combinada com AGs e Snapshots graváveis do XtremIO VALIDAÇÃO Cenários de validação Monitorando a métrica de desempenho Bancos de dados de testes Ambiente de testes Configuração do SQL Server

4 Projeto de armazenamento Propagação de cópias de banco de dados Usando snapshots do XtremIO para propagação de réplica secundária Taxa de desduplicação de cópias de banco de dados primário e secundário Monitoramento de Availability Groups Mantendo o desempenho em modo de confirmação síncrono Cenário com vários bancos de dados e vários AGs com cópia de Snapshot gravável Resumo de validação CONCLUSÃO Resultados REFERÊNCIAS Documentação da EMC White papers Documentação de produtos Documentação da Microsoft

5 Resumo executivo Atualmente, eficiência, desempenho e proteção são primordiais em datacenters modernos, nos quais os administradores precisam diminuir os custos de armazenamento e, ao mesmo tempo, garantir acordos rigorosos de SLAs para seus clientes, incluindo a proteção de ambientes de bancos de dados altamente confidenciais do OLTP (Online Transaction Processing) hospedados no Microsoft SQL Server. Como aprimoramento das opções de alta disponibilidade nativa para SQL Servers, a Microsoft introduziu as ofertas do AlwaysOn no SQL Server Essas ofertas incluem FCIs (Failover Cluster Instances, instâncias de cluster de failover) que oferecem aprimoramentos para instâncias do SQL Server em cluster e o recurso AAG (AlwaysOn Availability Groups), que apresenta uma melhoria para espelhamento e envio de logs de bancos de dados. O AAG, em especial, oferece uma solução de recuperação de desastres e alta disponibilidade que permite maximizar a disponibilidade de um ou mais bancos de dados de usuário com uma solução de replicação bidirecional, mesmo em vários locais e várias sub-redes. A vantagem do AlwaysOn Availability Groups em relação à oferta de alta disponibilidade da Microsoft da AlwaysOn FCI é a capacidade de ter cópias secundárias acessíveis e legíveis de bancos de dados de produção, e não o modelo de bancos de dados ativo/passivo da FCI. Isso pode resultar no uso mais equilibrado do hardware do datacenter e permitir uma solução de replicação bidirecional nativa. Entretanto, o uso de AG (Availability Group, grupo de disponibilidade) aumentará o requisito para armazenamento devido ao número de cópias mantidas. Como os custos de armazenamento são confidenciais, isso leva a práticas em que as cópias secundárias podem ser armazenadas em plataformas de menor desempenho, resultando em uma queda de desempenho em cenários de failover. Além disso, cópias secundárias somente atendem a cargas de trabalho graváveis. Portanto, se uma cópia gravável (destrutiva) dos dados for necessária, é preciso implementar processos de força bruta, o que pode aumentar ainda mais os requisitos de capacidade e o custo. O recurso de Inline Data Reduction sempre ativo do XtremIO resolve esses problemas com a consolidação de cópias de bancos de dados, sem penalidades de capacidade, ao mesmo tempo que fornecer um SLA esperado de uma plataforma totalmente flash. Os snapshots instantâneos sem nenhuma cópia do XtremIO oferecem cópias graváveis (destrutivas) de banco de dados, nas quais cargas de trabalho de teste/desenvolvimento, de geração de relatórios e analíticas podem ser feitas sem impacto no ambiente de produção. Público-alvo Este white paper destina-se a arquitetos de soluções de armazenamento e de banco de dados atualmente trabalhando com ou pensando em implementar o Microsoft SQL Server 2012/2014 da EMC XtremIO Storage array. O documento apresenta informações sobre a implementação de soluções de alta disponibilidade que também permitem ampliar a funcionalidade do MS SQL Server para fornecer snapshots graváveis e destrutivos dos dados de produção. Introdução Este documento registra recursos das ofertas do SQL Server AlwaysOn da Microsoft de FCIs (Failover Cluster Instances, instâncias de cluster de failover) e de Availability Groups (AG) para fornecer HA (High Availability, alta disponibilidade) nativa para o SQL Server 2012 e Além disso, também destaca como as vantagens de eficiência do XtremIO podem estender ainda mais a funcionalidade de ambientes do SQL Server, fornecendo snapshots graváveis de bancos de dados para cargas de trabalho analíticas e de teste/desenvolvimento. O SQL Server Enterprise Edition é necessário para usar os recursos de alta disponibilidade do AlwaysOn, o que pode não ser uma opção para alguns clientes. Para esses casos, os snapshots instantâneos sem nenhuma cópia ainda estão disponíveis para estender a funcionalidade do SQL Server Standard Edition e fornecer as mesmas cópias graváveis destrutivas. Como o documento concentra-se nesse assunto, há poucas informações sobre o produto genérico. Para obter mais detalhes, consulte os documentos e as informações listadas nas Referências, na página 28, que estão disponíveis no site do XtremIO. Resultados A Instância de cluster de failover e a tecnologia do Grupo de disponibilidade do AlwaysOn para SQL Server oferecem melhorias significativas aos níveis de proteção nativa do SQL Server em termos de facilidade de uso, monitoramento e desempenho, em comparação às ofertas de proteção do SQL Server nativas preexistentes. A desduplicação de cópias de banco de dados secundário do XtremIO, junto com o recurso de compactação, fornece capacidade significativa de economizar na implantações de Grupos de disponibilidade do AlwaysOn. Os snapshots do XtremIO superam a limitação de cópias secundárias somente leitura e permitem a criação de cópias de snapshot graváveis de bancos de dados de produção, mesmo quando esses bancos de dados são protegidos na replicação síncrona. Os snapshots do XtremIO podem estender a funcionalidade do SQL Server, mesmo sem a obrigatoriedade de escolha do licenciamento empresarial. 5

6 Alta disponibilidade do Microsoft SQL Server A Microsoft oferece uma série de opções de configuração de soluções de alta disponibilidade para SQL Server tanto no banco de dados do aplicativo como no nível de instância. Este documento concentra-se nas ofertas de AlwaysOn que estão disponíveis no SQL Server 2012/2014: FCIs (Failover Cluster Instances, instâncias de cluster de failover do AlwaysOn) AlwaysOn Availability Groups (AAG) O espelhamento e o envio de registro são opções disponíveis se a edição do SQL Server for anterior à A Microsoft aconselha que o Espelhamento de banco de dados seja removido em futuras versões e recomenda que os usuários passem a usar o AlwaysOn Availability Groups. Se você estiver usando uma versão do SQL Server que não é compatível com os recursos do AlwaysOn, o Envio de logs pode ser uma opção. FCIs (Failover Cluster Instances, instâncias de cluster de failover) do AlwaysOn Para configurações do AlwaysOn FCI, uma única instância do SQL Server é instalada em vários nós de WSFC (Windows Server Failover Cluster, cluster de failover do Windows Server). A funcionalidade do WSFC fornece alta disponibilidade no nível de instância e acesso por meio do nome do cluster. Esse modelo oferece uma solução ativa/passiva em armazenamento compartilhado, conforme mostrado na Figura 1. Figura 1. FCI do Microsoft SQL Server AlwaysOn Availability Groups (AAG) Os AlwaysOn Availability Groups permitem um ambiente de failover para um conjunto específico de bancos de dados primários e 1 a 8 conjuntos de bancos de dados secundários correspondentes, dependendo da versão do SQL Server. Da mesma forma que o AlwaysOn Failover Clustering, os AlwaysOn Availability Groups exigem que as instâncias do SQL Server sejam configuradas em nós do WSFC, mas com as instâncias restantes e sendo apresentadas à rede como computadores separados com failover no nível de uma réplica de disponibilidade. Os requisitos de armazenamento empregam um modelo de disco não compartilhado. Para obter um exemplo de um grupo de disponibilidade, consulte o panorama de antes na Figura 2. Modos de disponibilidade Cada grupo de disponibilidade tem uma das configurações de modo de disponibilidade a seguir, que determina se a réplica primária deve aguardar a confirmação de uma transação em um banco de dados até que a réplica secundária correspondente tenha gravado o registro de transações no disco (fortalecimento do registro). Modo de confirmação assíncrono - A réplica primária confirma uma transação sem conhecimento de que uma réplica de confirmação assíncrona fortaleceu o registro. Enquanto esse modo minimiza a latência das transações, permitindo que os bancos de dados secundários tenham atrasos em relação aos primários, ele pode resultar em perda de dados. Modo de confirmação síncrono - A réplica primária aguarda confirmação de que uma réplica secundária com confirmação síncrona fortaleceu o registro antes de confirmar uma transação. Apesar desse modo aumentar a latência das transações, ele protege contra perda de dados. Isso significa que, enquanto os bancos de dados secundários estiverem em estado síncrono em relação ao banco de dados primário, as transações confirmadas estarão totalmente protegidas. 6

7 Para obter mais informações sobre AlwaysOn Availability Groups, consulte msdn.microsoft.com. Tabela 1 Comparação entre a Instância de cluster de failover do AlwaysOn e Availability Groups Recurso Nós em uma FCI Réplicas em um Availability Group Usa o cluster do WSFC Sim Sim Tipo de armazenamento Compartilhado Não compartilhado Realiza um failover de armazenamento Sim Não Nível de proteção Instância Banco de dados Número de nós/réplicas Padrão: 2 Enterprise e Datacenter: 16 Cópias secundárias legíveis Não Sim Configurações de política de failover aplicáveis Quórum do WSFC Configurações do Availability Group Específico do FCI SQL Server (inclusive principal) SQL Server (inclusive principal) Quórum do WSFC Configurações do Availability Group Failover de recursos Servidor, instância e banco de dados Apenas banco de dados Escolhendo um modelo de proteção Ao escolher entre a FCI e os AGs do AlwaysOn, o fator mais importante a considerar (além de preferências do usuário e outros fatores), são os requisitos de armazenamento de cada modelo. Embora a FCI ofereça um modelo de armazenamento compartilhado, ela deixa o usuário com nós ativos/passivos e sem acesso aos dados por meio dos nós passivos. Portanto, o hardware que hospeda as cópias passivas fica ocioso. Por outro lado, o modelo de AG permite configurar cópias da réplica secundária para permitir operações como somente leitura cargas de trabalho, backup de cópias secundárias, etc., o que aumenta os requisitos de armazenamento lógico e físico devido a um modelo de armazenamento não compartilhado. Figura 2. AlwaysOn Availability Groups do SQL Server 7

8 Capacidade do XtremIO para alterar o modelo de armazenamento não compartilhado A hospedagem de ambientes do MS SQL Server no XtremIO é a escolha óbvia para hospedar cargas de trabalho altamente transacionais com latências extremamente baixas. No entanto, os usuários devem aprender sobre os recursos exclusivos do XtremIO Storage Array. A capacidade do XtremIO de compactar e desduplicar várias cópias do mesmo banco de dados elimina a desvantagem do AAG e altera a utilização da capacidade do modelo não compartilhado usado para grupos de disponibilidade. A Figura 2 exibe o estado de antes e o de depois para demonstrar como o XtremIO muda o espaço ocupado pelo armazenamento para grupos de disponibilidade. Enquanto no passado pode ter havido preocupações com hospedagem de volumes de cluster ativo/passivo (ou primário/secundário no caso de AAG) na mesma estrutura de disco subjacente, o XDP (XtremIO Data Protection) permite que o usuário confie nessa opção. O XDP é a primeira proteção de dados nativa de flash do mundo que oferece menor sobrecarga de capacidade, proteção de dados superior e melhor resistência do flash, bem como desempenho em comparação a qualquer algoritmo RAID. Isso ocorre porque cada instância do SQL Server em um grupo de disponibilidade requer que seu próprio conjunto de volumes de array seja provisionado como volumes NTFS. A Figura 3 apresenta uma visão conceitual de como o XtremIO é capaz de desduplique e compacte esses volumes para proporcionar economia significativa de espaço. Figura 3. Mapeamento do Volume do XtremIO para Volumes de NTFS do Windows A Figura 3 demonstra como Volumes de NTFS de cópia secundária de Volumes de NTFS de cópia primária de banco de dados são combinados com eficiência em um só, e como os snapshots obtidos desses volumes são realmente gratuitos, sendo apenas uma operação de metadados em memória. Apenas as diferenças de dados entre várias cópias são contadas como uso de espaço adicional para os dados desduplicados e compactados originais e, mesmo assim, os dados exclusivos tiram proveito da economia de compactação. Por exemplo, se um snapshot é obtido da réplica da cópia primária e provisionado como uma cópia gravável (destrutiva), o espaço de armazenamento adicional para o array só será consumido para o volume de dados que é alterado e manipulado e, mesmo nessa situação, apenas durante a vida útil do snapshot. Outro fator importante a considerar é a funcionalidade adicional que XtremIO traz para o MS SQL Server, não importando a versão do SQL Server que está sendo usada. Enquanto as Instâncias de Cluster de failover fornecem uma cópia em standby dinâmico dos dados de produção, cópias do Availability Group de banco de dados secundário podem ser configuradas como cópias da réplica secundária gravável. No entanto, em muitas situações uma cópia gravável pode ser inadequada. Portanto, a capacidade de ter uma cópia gravável (destrutiva) dos dados normalmente será mais útel. Conforme mostrado na seção Depois da Figura 2, o XtremIO oferece uma flexibilidade muito ampliada de ambientes SQL. Esses snapshots graváveis instantâneos sem salvar cópias consomem apenas o armazenamento para gravar as alterações dos dados originais e somente durante a vida útil snapshot. Para obter exemplos de como incorporar esse recurso, consulte Configurações de arquitetura do AlwaysOn na página 9. 8

9 Configurações de arquitetura do AlwaysOn Esta seção fornece detalhes sobre a opção de configuração mais simples disponível com o AlwaysOn. Instâncias de cluster de failover do AlwaysOn com Snapshots graváveis do XtremIO As Instâncias de cluster de failover do AlwaysOn da Microsoft permitem várias cópias em standby dinâmico. No entanto, o acesso aos dados mantidos no nó passivo é restrito. Nesse cenário, o XtremIO pode estender bastante a funcionalidade, fornecendo acesso às cópias de snapshot gravável. Figura 4. Instâncias de cluster de failover do AlwaysOn com Snapshots do XtremIO A Figura 4 demonstra como uma cópia de snapshot dos volumes de bancos de dados ativos pode ser realocada, em intervalos programados, na frequência e quantas vezes forem necessárias. Como resultado, o cluster de failover ainda pode oferecer proteção e o XtremIO snapshot fornece uma cópia independente dos dados a ser redefinida como necessário. 9

10 Soluções de replicação bidirecional do AlwaysOn com Snapshots graváveis do XtremIO O recurso AlwaysOn Availability Groups pode fornecer um ambiente mais flexível do que a FCI. Ao permitir a configuração de uma solução de replicação bidirecional, o usuário pode equilibrar a utilização de hardware nos datacenters e entre eles. Em vez de manter até 8 cópias secundárias, que é o limite no SQL Server 2014 (4 no SQL Server 2012), os administradores podem dedicar hardware para manter a disponibilidade para sistemas de produção e realocar cópias de snapshot para hardware independente ou provisionar para servidores de réplica secundária, nos quais o hardware pode ser subutilizado. A Figura 5 mostra um exemplo de configuração para um só local. Figura 5. XtremIO e AlwaysOn Availability Groups 10

11 Figura 6 apresenta um exemplo da configuração em vários locais. Figura 6. XtremIO e AlwaysOn Availability Groups em vários locais Com o desempenho proporcionado pelo XtremIO, também é possível manter a replicação de confirmação síncrona em distâncias curtas, conforme mostrado na Figura 6. A maioria das soluções de replicação em vários locais que usam o AlwaysOn Availability Groups provavelmente serão assíncronas, com a capacidade para que o próprio MS SQL Server mantenha o processo REDO, às distância, sendo o fator limitante. Contudo, com o XtremIO, soluções de baixa latência, de baixo custo e de pouca largura de banda são cada vez mais possíveis. A Figura 7 demonstra uma solução ainda mais complexa, na qual um modo de confirmação síncrono é mantido para duas cópias secundárias (o limite da confirmação síncrono) em uma solução de vários locais. O segundo Availability Group é configurado como modo de confirmação síncrono no nível A local, e o modo de confirmação assíncrono entre os locais A e B. O potencial de complexidade para uma determinada solução é limitado pela disponibilidade de hardware do computador e a capacidade do MS SQL Server de hospedar essas soluções complexas. 11

12 Figura 7. XtremIO e AlwaysOn Availability Groups em vários locais 12

13 Instância de cluster de failover do AlwaysOn combinada com AGs e Snapshots graváveis do XtremIO O usuário não está limitado à escolha entre o AlwaysOn FCI e Availability Groups. Uma combinação dos dois pode ser escolhida, como demonstrado na Figura 8. A única restrição para essa configuração é que Instâncias de cluster de failover do SQL Server não são compatíveis com failover automático de Availability Groups. Portanto, qualquer réplica de disponibilidade hospedada por um FCI só pode ser configurada para failover manual. Figura 8. AlwaysOn FCI e GAs com Snapshots do XtremIO Esses exemplos destacam como a utilização da funcionalidade de snapshot do XtremIO para fornecer cópias graváveis pode oferecer uma solução simples e muito mais prática do que tentar provisionar várias cópias secundárias gravávei em grupos de disponibilidade ou ter como resultado com cópias passivas inacessíveis nas configurações do AlwaysOn FCI. 13

14 Validação Cenários de validação Uma série de cenários foi concluída para avaliar o comportamento e o desempenho das implementações sugeridas. Como Instâncias de cluster de failover do AlwaysOn usam um modelo de disco compartilhado, os testes de validação concentram-se em AlwaysOn Availability Groups. Os cenários testados incluem: Taxa de desduplicação para cópias de banco de dados primário e secundário Mantendo o desempenho em modo de confirmação síncrono Cenário com vários bancos de dados e vários AGs com cópia de Snapshot gravável Monitorando a métrica de desempenho Ao monitorar o desempenho do SQL Server, vários contadores de desempenho de níveis de host podem ser monitorados. Os monitores mais óbvios Leitura de disco média por segundo; Média de disco/gravação fornecem a latência média de leitura/gravação vista no nível do host. Contadores adicionais são transferências/s, que fornecem percepções com IOPS e transações por segundo ou TPS O SQL Server Management Studio (SSMS) também oferece uma exibição de painel de controle, na qual um usuário pode monitorar os AlwaysOn Availability Groups. Contadores adicionais, como Tempo de recuperação estimado (segundos) e Taxa de redo (KB/s), podem ser adicionados à exibição, conforme mostrado na Figura 9. Figura 9. Exibição do painel de controle do SSMS para réplicas de AlwaysOn Availability Group Para obter mais detalhes sobre o monitoramento do AlwaysOn Availability Groups, consulte msdn.microsoft.com. 14

15 Bancos de dados de testes Os bancos de dados de teste usado simularam cargas de trabalho de OLTP executando uma carga de trabalho de leitura/gravação de 90/10. Esses bancos de dados são baseados no padrão de TPC-E, conforme definido pelo TPC (Transaction Processing Council, conselho de processamento de transações). O esquema de TPC-E simula a carga de trabalho de OLTP de uma corretora, fornecendo um banco de dados central que executa as transações relacionadas às contas de clientes da empresa. Embora o modelo de negócios subjacente do TPC-E seja uma corretora, o esquema de banco de dados, o preenchimento de dados, as transações e as regras de implementação foram projetadas para ser amplamente representativas para sistemas de OLTP modernos. Cem mil bancos de dados exclusivos de usuário foram usados, sendo que cada um equivale a um banco de dados de 824 GB de tamanho. No Windows, a implementação do esquema é igual a um banco de dados cujos arquivos têm 1,1 TB de tamanho. A capacidade do XtremIO de compactar dados exclusivos, resultando em uma taxa de compactação de 1.6:1 nessa instância, equivale a cerca de 544 GB de uso de espaço físico no array, conforme mostrado na Figura 10. Figura 10. Propriedades do armazenamento para o banco de dados inicial Ambiente de testes O teste foi realizado usando servidores Intel padrão do setor (com duas CPUs 10 core Intel E GHz). Cada servidor foi equipado com uma única porta dupla HBA da Emulex LPe 16002, conectada por meio de uma SAN Brocade a um cluster do X-Brick único (observe que o termo cluster pode se referir a um XtremIO X-Brick único ou uma configuração de vários X-Bricks). Configuração do SQL Server O Microsoft SQL Server 2014 Enterprise Edition foi usado para essa solução, já que as ofertas de alta disponibilidade do AlwaysOn estão disponíveis apenas nas edições Enterprise. As seguintes opções de configuração foram definidas: Configurações de memória mínima e máxima foram definidas como 128 GB. O bloqueio de páginas na memória foi definido. Os volumes de NTFS foram configurados com tamanho de alocação de 64 KB. A verificação indireta foi definida para 60 s nos bancos de dados de teste. 15

16 Projeto de armazenamento Para configurar o ambiente, o armazenamento foi provisionado em um só cluster de X-Brick. A Tabela 2 mostra a configuração de armazenamento provisionada para cada banco de dados. A imitação dos volumes, provisionados para cada host, fornece o armazenamento para as cópias de banco de dados primário e secundário. Os volumes foram provisionados para bancos de dados de sistema de host e TempDB, com um só volume de 1 TB configurado como um repositório de propagação. Tabela 2 Nome do volume do Xtremio Provisionamento de armazenamento do XtremIO para nós de host do Windows Tamanho do Volume (GB) Usado (GB) Host Nomes de volumes do Windows SQL1_SystemDB 5 SQL Srv 1 SQL1_SystemDB SQL1_TempDB 256 SQL1_TempDB SQL1_DB1_Data_1 512 DB1_Data_1 SQL1_DB1_Data_2 512 DB1_Data_2 SQL1_DB1_Data_3 512 DB1_Data_3 SQL1_DB1_Data_4 512 DB1_Data_4 SQL1_DB1_Log 512 DB1_Log SQL_SystemDB 5 SQL Srv 2 SQL2_SystemDB SQL2_TempDB 256 SQL2_TempDB SQL2_DB1_Data_1 512 DB1_Data_1 SQL2_DB1_Data_2 512 DB1_Data_2 SQL2_DB1_Data_3 512 DB1_Data_3 SQL2_DB1_Data_4 512 DB1_Data_4 SQL2_DB1_Log 512 DB1_Log Para cada Instância, um volume único foi provisionado para hospedar o banco de dados TempDB, que consiste em quatro arquivos de dados do banco de dados temporário e um registro de transações. Embora os requisitos de desempenho do banco de dados temporário variam com base em cargas de trabalho, essa configuração é executada adequadamente nesses testes. Cada banco de dados subsequente foi configurado de maneira semelhante, para que o armazenamento provisionado para a cópia da réplica secundária correspondesse ao armazenamento da réplica primária. 16

17 Propagação de cópias de banco de dados Há várias opções disponíveis para propagação de réplicas de Availability Group: Full Join Ignorar a sincronização inicial dos dados A Figura 11 apresenta uma visão das opções disponíveis, mostradas como parte do Assistente de criação de Availability Group. Ao executar uma sincronização completa de dados inicial como parte da criação do Availability Group, um usuário pode tirar proveito do desempenho do XtremIO para acelerar o processo de backup e recuperação. É recomendável que a compactação seja usada na seção de scripting de backup de um processo de criação de Availability Group, para ajudar a reduzir a duração do processo de propagação e repropagação ao diminuir o tamanho dos arquivos de backup. Usar vários arquivos de backup pode ajudar ainda mais o desempenho ao aumentar o paralelismo de acesso. O uso da opção Ignorar sincronização inicial de dados permite provisionar por meio de operações de backup/restauração nativa do SQL Server ou usar o recurso de snapshot do XtremIO. Figura 11. Propriedades do armazenamento para o banco de dados inicial Conforme esperado, um processo de backup/restauração é uma operação de leitura/gravação sequencial que exige muita largura de banda. Por isso, é preciso ter espaço adequado a ser reservado para acomodar o reenvio de todos os bancos de dados cobertos pelos Availability Groups. Basta excluir os arquivos de backup depois que o processo for concluído para evitar o consumo de espaço de armazenamento desnecessário e habilitar a recuperação de espaço. Usando snapshots do XtremIO para propagação de réplica secundária O XtremIO ofereceo recurso de Availability Groups de propagação por meio de Snapshots. Na prática, um snapshot é uma cópia gratuita do banco de dados e, embora os administradores não vejam os benefícios de desduplicação e compactação relatados no modo de exibição de painel de controle do XtremIO XMS, essa é uma opção útil se a velocidade é uma prioridade para o processo de repropagação. 17

18 Taxa de desduplicação de cópias de banco de dados primário e secundário Para exibir a taxa de desduplicação para um banco de dados da réplica primário e secundário em Availability Groups, uma réplica de banco de dados secundário é propagada. Como resultado, as seguintes taxas de redução de dados foram observadas: Razão total de redução 3,1:1 o Desduplicação 1,9:1 o Compactação 1,6:1 As taxas de redução de dados resultantes são exibidas na Figura 12. Figura 12. Propriedades de exibição do armazenamento para AG do banco de dados único A taxa de desduplicação de 1,9:1 é o resultado de bancos de dados de sistema e TempDBs para as duas instâncias do SQL Server hospedado no cluster do XtremIO X-Brick único. Repetindo esse teste, usando somente os arquivos relacionados às cópias dos dois bancos de dados hospedados no Array enquanto todos os outros arquivos são removidos, resulta em um taxa de desduplicação de 2.0:1, conforme mostrado na Figura 13. Figura 13. Hospedagem de arquivos de AG de banco de dados único pelo array do XtremIO 18

19 A hospedagem do arquivo de backup compactado do SQL Server, criado durante o processo de criação de AG no array, também afeta os resultados, como mostrado na Figura 14. Recomenda-se excluir esses arquivos após o processo, para que um resultado mais claro possa ser observado. Figura 14. Hospedagem de arquivos de AG de banco de dados único pelo array do XtremIO mais arquivo de backup A Figura 15 mostra o espaço físico usado após a criação do Availability Group.do banco de dados único inicial. Apenas GB de capacidade física são consumidos no array, em comparação a uma utilização da capacidade do volume relatada de TB. Se for visualizado em nível de sistema operacional, o Windows informa 1.1 TB de dados existentes em cada instância do SQL Server. Figura 15. Capacidade física utilizada Esses resultados demonstram a capacidade do XtremIO de reduzir drasticamente o espaço ocupado pelo armazenamento do AlwaysOn Availability Groups e para mascarar o modelo de armazenamento não compartilhado usado pelos Availability Groups. 19

20 Monitoramento de Availability Groups No SSMS, os Availability Groups são marcados como primário ou secundário, dependendo da instância da qual o painel de controle é exibido. Na visualização do servidor, mostrado na Figura 16, o grupo de disponibilidade AG1 contém um banco de dados chamado OLTP_1 e é marcado como primário, comprovando que ele é visto do servidor de réplica primária. Figura 16. Visualização Server Depois de configurados, os Availability Groups podem ser monitorados por meio da exibição do painel de controle no SSMS. Uma exibição de painel de controle está disponível para cada Availability Group. A Figura 17 mostra a exibição do painel de controle para AG1, que hospeda um único banco de dados. PSQL1 tem a função primária, e PSQL2 tem a função de réplica secundária. O banco de dados é marcado como Sincronizado em ambas as instâncias do SQL Server, o que indica que esse banco de dados está sendo executado no modo síncrono. Figura 17. Exibição de painel de controle do SSMS do AG do banco de dados único 20

21 Conforme mostrado na Figura 18, um segundo Availability Group, AG2, está configurado. PSQL2 tem a função Primária e os bancos de dados neste servidor são marcados como Sincronizados. PSQL1 é marcado como Secundária e Em sincronização. Isso indica que o Availability Group é configurado no modo assíncrono. Figura 18. Exibição de painel de controle do SSMS do AG do banco de dados único Observe que o modo de Failover é Automático para AG1 e Manual para AG2, demonstrando que o modo síncrono só permite Failover automático Sem perda de dados. Mantendo o desempenho em modo de confirmação síncrono Uma carga de trabalho de teste foi executada no banco de dados da réplica primária em AG1, que foi configurado no modo de confirmação síncrono. Conforme estabelecido pela Microsoft, o uso do modo de confirmação síncrono pode aumentar a latência porque é preciso aguardar a confirmação de que o registro que está sendo protegido. Os recursos de desempenho extremo do XtremIO, para desempenho de serviço como baixa latência, eliminam esse problema quando o SQL Server é hospedado em um array XtremIO. Como demonstrado na Figura 19 e na Figura 20, executar uma carga de trabalho de OLTP gerou mais de IOPS no array com latência do array bem abaixo de 1 ms. Figura 19. Visualização de desempenho de latência para o modo de confirmação síncrona 21

22 O aplicativo de gerenciamento de armazenamento do XtremIO permite que um monitor definido por usuário monitore a latência de volumes individuais de gravação, leitura e latência média medida em microssegundos (µs), conforme mostrado na Figura 20. Figura 20. Painel de controle do XMS Monitor definido do usuário Latência de volume Os resultados mostram que o array do XtremIO pode atender a essa carga de trabalho sem nenhuma restrição. A latência máxima é de 854 (µs) para a latência de gravação de registros, o que é particularmente complexo em cenários de replicação síncrona. O desempenho do registro de transações normalmente pode ser um gargalo para cargas de trabalho do SQL Server. No entanto, os recursos de desempenho do XtremIO resolvem esse problema. Embora a carga de trabalho possa ser enviada forçada com facilidade, IOPS de e em geral é considerado como o número máximo de IOPS para os maiores bancos de dados do SQL Server. Nesse caso, o banco de dados está atendendo a IOPS de cerca de enquanto mantém as latências bem abaixo do limite de um milissegundo (ms). A Figura 21 mostra uma análise da carga de trabalho entre as duas instâncias do SQL Server. A réplica primária está atendendo IOPS de , enquanto o secundária atende IOPS de A carga de trabalho na réplica secundária consiste principalmente na gravação de I/Os gerados pelo processo de REDO. As Transações/s (TPS) nas cópias de réplica primária e secundária diferem muito porque a réplica secundária está apenas se mantendo em sincronia com a cópia primária do banco de dados OLTP_1, mas há algumas atividades no banco de dados temporário para cada instância do SQL Server. Figura 21. IOPS e TPS entre cópias primárias e secundárias 22

23 O painel de controle do SSMS para AG1, mostrado na Figura 22, demonstra o AG1 do Availability Group, marcado como Íntegro e sincronizado com sem perda de dados em um tempo de recuperação estimado de 1 segundo. A taxa de Redo é mostrada como 6,023 KB/s. Figura 22. Exibição de painel de controle do SSMS para AG1 O desempenho demonstrado é impressionante, considerando que ele é obtido durante a execução de uma solução de alta disponibilidade que, ao mesmo tempo, mantém uma cópia secundária em um estado sincronizado. Como o processo de redo é realizado entre réplicas primária e secundária, as taxas de redução de dados devem ser consideradas. Observando a exibição de painel de controle do XMS (Figura 23), pode-se observar que não há nenhuma alteração nos valores informados, mesmo com relação a uma carga de trabalho de execução estendida. Figura 23. A taxa de redução de dados mantém-se uniforme Cenário com vários bancos de dados e vários AGs com cópia de Snapshot gravável Para demonstrar um cenário um pouco mais complexo, uma solução de replicação bidirecional foi configurada, consistindo em dois Availability Groups que protegem três bancos de dados. Um snapshot da cópia do banco de dados de réplica primária para OLTP_1 foi obtido e provisionado para uma instância adicional do SQL Server, e uma carga de trabalho total foi conduzida em relação a esse snapshot gravável do XtremIO, juntamente com uma carga de trabalho sendo direcionada para todos os outros bancos de dados primários. Os detalhes do cenário são: Availability Group AG1 o o Função primária de hospedagem PSQL1, função secundária de armazenamento PSQL2 Protegendo um único banco de dados OLTP_1 no modo de confirmação síncrono Availability Group AG2 o o Função primária de hospedagem PSQL2, função secundária de armazenamento PSQL1 Protegendo dois bancos de dados OLTP_2 e OLTP_3 no modo de confirmação assíncrono Snapshot gravável de réplica primária OLTP_1 hospedado pelo PSQL_3 23

24 Figura 24. Painel de propriedades do armazenamento Eficiência Conforme mostrado na Figura 24, duas cópias dos três bancos de dados, OLTP_1, OLTP_2 e OLTP_3, resultam em uma taxa de desduplicação de 2,0:1 e uma taxa de compactação de 1,6:1, oferecendo uma taxa de redução de dados geral de 3,1:1. Observando os valores de capacidade, mostrados na Figura 25, TB do espaço físico são usados, em vez de TB de capacidade de Volume usado e TB de capacidade de volume provisionada pelo array. Essas condições fornecem uma economia de thin provisioning de 70%. Figura 25. Painel de propriedades do armazenamento Capacidade 24

25 O efeito de mapeamento de volumes de snapshot do banco de dados de réplica primária OLTP_1 para a hospedagem do terceiro servidor é mostrado na Figura 26. Figura 26. Painel de propriedades do armazenamento com snapshot sem salvar cópias O painel Armazenamento mostra que a criação do snapshot e o mapeamento de volumes não alteram o valor de capacidade física usada. A única alteração é que a capacidade do Volume provisionado é alterada para TB e a economia de thin provisioning aumenta 74%. Na próxima fase, cargas de trabalho individuais foram executadas em todos os bancos de dados por várias horas. Figura 27. Painel Performance A Figura 27 mostra o desempenho informado no painel de controle XtremIO com IOPS de para a carga de trabalho combinada entre quatro bancos de dados. 25

26 Figura 28. Média total de IOPS de leitura/gravação relatada no painel de controle Uma análise de um determinado momento do IOPS de leitura/gravação ( Figura 28) mostra leituras para gravações. A média de latência em todo o array neste momento, conforme mostrado na Figura 29, é 899 microssegundos (µs). Figura 29. Gravação, leitura e a latência média relatadas no painel de controle Resumo de validação Os resultados dos testes de validação confirmam que o XtremIO é uma plataforma excelente para hospedar ambientes do MS SQL Server confidenciais de latência. A capacidade do XtremIO Storage Array de atender a várias cargas de trabalho em configurações complexas enquanto mantém uma solução mista de replicação bidirecional síncrona e assíncrona que atende mais de IOPS é verdadeiramente impressionante. Essa conclusão é novamente validada, considerando que os resultados incluem a manutenção de uma carga de trabalho completa em relação a um snapshot de um banco de dados protegido em um AlwaysOn Availability Group que, por sua vez, foi configurado em confirmação síncrona, especialmente com uma latência média de 899 (µs). 26

27 Conclusão Este white paper destaca a capacidade do EMC XtremIO Storage Array de hospedar ambientes de SQL Server protegidos pelo ofertas nativas do AlwaysOn para SQL Server. As configurações possíveis são demonstradas, usando o recurso de Instâncias de cluster de failover do AlwaysOn e AlwaysOn Availability Group, nos modos síncrono e assíncrono, bem como configurá-los. Além disso, este documento destaca a capacidade do recurso de snapshot do XtremIO de superar a limitação de cópias secundárias somente leitura, permitindo criar snapshots instantâneos sem salvar cópias dos bancos de dados de produção para análise destrutira ou teste de cargas de trabalho. Resultados A tecnologia de Instância de cluster de failover e de Grupo de disponibilidade do AlwaysOn para SQL Server oferece melhorias significativas aos níveis de proteção nativa do SQL Server em termos de facilidade de uso, monitoramento e desempenho, em comparação às ofertas de proteção do SQL Server nativas preexistentes. A capacidade do XtremIO de desduplicar cópias de banco de dados secundário, juntamente com seu recurso de compactação, oferece economia significativa para implementações do AlwaysOn Availability Groups. Os snapshots do XtremIO superam a limitação de cópias secundárias somente leitura e permitem a criação de cópias de snapshot gravável de bancos de dados de produção, mesmo quando esses bancos de dados são protegidos na replicação síncrona. Os snapshots do XtremIO podem estender a funcionalidade do SQL Server, mesmo sem a necessidade de escolher o licenciamento empresarial. 27

28 Referências Para obter mais informações, consulte o site do XtremIO. Documentação da EMC Esses documentos estão disponíveis nos site brazil.emc.com ou no Suporte on-line da EMC. O acesso ao suporte on-line depende de suas credenciais de log-in. Caso você não tenha acesso a determinado documento, entre em contato com o representante da EMC. White papers Para obter informações adicionais, consulte os white papers listados abaixo: Introdução ao EMC XtremIO Storage Array Introdução aos snapshots do XtremIO Documentação de produtos Para obter mais informações, consulte os seguintes documentos de produto:. EMC XtremIO System Specifications Guia do Usuário do EMC XtremIO Storage Array Introdução ao storage array do EMC XtremIO (Ver 3.0) Documentação da Microsoft Para obter informações adicionais especificamente fornecidas pela Microsoft, consulte a documentação mais recente nos sites do MSDN e TechNet em Microsoft.com e consulte os documentos a seguir: Pre-Configuration Database Optimizations SQL Server Best Practices MSDN: AlwaysOn Availability Groups (SQL Server) 28