Trabalhando com Alta Disponibilidade, Cluster, Hyper
Download
Report
Transcript Trabalhando com Alta Disponibilidade, Cluster, Hyper
Trabalhando com Alta
Disponibilidade, Cluster, Hyper-V
2012 e
Pedro Antonio Galvão Junior
MVP – Windows Server System – SQL Server.
Senior Database Administrator.
Software Engineer.
University Teacher.
FIT - Flextronics Institute Technology.
Universidade Uninove/FAC São Roque.
Microsoft Windows Server 2012
• A função do Hyper-V permite criar e gerenciar um ambiente de computação virtualizado,
usando a tecnologia de virtualização interna do Windows Server 2012.
• Instalar a função Hyper-V instala os componentes necessários e, como opção, instala
ferramentas de gerenciamento.
• Os componentes necessários incluem hipervisor do Windows, o Serviço Gerenciamento de
Máquinas Virtuais do Hyper-V, o provedor WMI de virtualização e outros componentes de
virtualização como barramento VMbus, VSP (provedor de serviço de virtualização) e VID
(unidade de infraestrutura virtual).
• As ferramentas de gerenciamento para a função Hyper-V consistem em:
• Ferramentas de gerenciamento baseadas em GUI: Gerenciador Hyper-V, um snap-in
MMC (Console de Gerenciamento Microsoft) e uma conexão de máquina virtual que
fornece acesso à saída de vídeo de uma máquina virtual para que você possa interagir
com ela.
• Cmdlets específicos de Hyper-V para Windows PowerShell: O Windows Server 2012
inclui um módulo Hyper-V, que fornece acesso à linha de comando para todas as
funcionalidades disponíveis na GUI, bem como as funcionalidades não disponíveis por
meio da GUI.
Alta Disponibilidade
Nível de Alta-Disponibilidade medida em quantidade de noves
Percentual de Noves
Downtime (ano)
100%
Sem parada
99,999 (5 noves)
Menos de 5,26 minutos
99,99 (4 noves)
5,26 minutos até 52 minutos.
99,9 (3 noves)
52 minutos até 8 horas e 45 minutos.
99,0 (2 noves)
8 horas e 45 minutos até 87 horas e 36 minutos
98,9 (1 nove)
87 horas e 36 minutos até 875 horas e 54 minutos.
• Baseado no conceito de Shared Nothing Cluster que implementa um servidor virtual onde as
aplicações se conectam. O servidor virtual é composto de um nome de rede e IP diferentes dos
nomes de rede e IPs dos servidores físicos que compõem o cluster e de um disco de quorum.
•Um cluster é composto de pelo menos dois servidores, sendo que o servidor virtual é executado no
servidor físico que estiver ativo no cluster (nó ativo).
• Os outros servidores que compõem o cluster e não executam o servidor virtual são chamados de
nós passivos e ficam aguardando a falha de algum componente do nó ativo para assumir as funções
do servidor virtual.
• Os nós do cluster compartilham um mesmo disco – chamado “disco de quorum” – que pode ser
acessado por cada nó, mas somente um por vez o nó que tiver acesso ao disco de quorum é o nó
que controla o cluster e que receberá as conexões do servidor virtual.
•A solução Server Cluster pode ser descrita como uma tecnologia que permite que um servidor
assuma a função de outro servidor físico quando este parar de funcionar.
• Quando o servidor que é “dono” do disco de quorum falha, o servidor físico que está em stand-by
assume o disco de quorum e passa a responder requisições recebidas pelo servidor virtual.
•Este processo de transferência do servidor virtual de um nó físico para o outro nó físico chama-se
Failover.
• Um cluster de Failover é um conjunto de computadores independentes que trabalham em
conjunto para aumentar a disponibilidade e escalabilidade de funções de cluster (antigamente
chamadas de aplicações e serviços de cluster).
• Os servidores em cluster (chamados de nós) são conectados por cabos físicos e por software. Se
um ou mais dos nós do cluster falhar, o outro nó começará a fornecer o serviço (um processo
conhecido como Failover).
• Além disso, as funções de cluster são monitoradas de maneira proativa para verificar se estão
funcionando adequadamente. Se não estiverem funcionando, elas serão reiniciadas ou movidas
para outro nó.
• Os clusters de Failover também fornecem a funcionalidade CSV (Volume Compartilhado
Clusterizado) que, por sua vez, oferece um namespace consistente distribuído, o qual pode ser
usado para acessar o armazenamento compartilhado em todos os nós. Com o recurso Clustering de
Failover, os usuários passam pelo mínimo de interrupções no serviço.
•Um cluster não distribui carga de processamento, pois o nó passivo não recebe requisições.
Somente o nó físico – que possui acesso ao disco de quorum – é quem recebe e processa
requisições recebidas pelo servidor virtual.
•O cluster é uma solução de alta disponibilidade, pois em caso de falha do nó físico o outro nó
assume todas as funções do nó anterior.
Microsoft SQL Server 2012
• O SQL Server 2012 traz significantes mudanças em relação ao comportamemento
de HA e DR dentro do banco de dados.
• Cada vez mais as organizações precisam estar com suas bases de dados sempre
disponíveis e operantes, sendo assim devemos evitar o máximo de downtime de um
servidor assim como a perda de dados de uma empresa.
HA e DR:
O HA = High Availability ou Alta disponibilidade e o DR = Disaster
Recovery ou plano de recuperação de disastres, tem como principal objetivo
minimizar o impacto do downtime dos servidores de uma empresa.
• Como solução anterior, no SQL Server 2012 possuíamos a estratégia de Failover clustering para proteger toda a
instância do banco de dados, junto com Database Mirroring (espelhamento de banco de dados) para cada base
de dados, provendo assim um sistema com alta disponibiliade porém não totalmente eficaz e integrado.
• Porém, para as organizações que desejam mais de um datacenter, a solução é possuir um espelhamento de
banco de dados com o log shipping, essa seria outra opção para gerar assim uma alta disponibilidade das
informações armazenadas na empresa.
• Pensando em todos esses problemas e dificuldades que enfrentávamos, o SQL Server 2012 provê uma nova
solução chamada AlwaysOn. Esse novo recurso faz com que seja possível realizar a proteção em alto nível como
o Failover de diversos bancos de dados, possuir múltiplos secundários dentre outras opções que veremos logo a
frente.
• O AlwaysOn Availability Group provê uma alternativa ao espelhamento de banco de dados, esse
novo recurso possibilita a abilidade de realizar Failover automático ou manual de grupos de bancos
de dados, sendo possível possuir até 4 locais secundários.
• Essa nova solução provê proteção de todas as informações “sem” perda de dados e é totalmente
flexível. A mesma pode ser realizada com armazenamento local ou compartilhado, diferente do
Cluster, e ainda possuindo movimento dos dados entre os eles de forma sincróna ou assíncrona.
• Uma de suas grandes qualidades é o Failover entre instâncias assim como reparação de páginas
danificadas.
Disaster Recovery
Data Center
Primary Data Center
Windows Server Failover Cluster (single WSFC crossing two data centers)
SQL Server
SQL Server
Primary
SQL Server
Secondary
Secondary
Synchronous
Asynchronous
Availability Group
Disaster Recovery
Data Center
Primary Data Center
Windows Server Failover Cluster (single WSFC crossing two data centers)
SQL Server
SQL Server
Secondary
SQL Server
Secondary
Primary
Synchronous
Asynchronous
Availability Group
Additional Server for
Node Majority
Quorum Model
Disaster Recovery
Data Center
Primary Data Center
Windows Server Failover Cluster (single WSFC crossing two data centers)
SQL Server
SQL Server
Secondary
SQL Server
Secondary
Primary
Synchronous
Asynchronous
Availability Group
File Share
Microsoft SQL Server 2012
Conceitos e Terminologia: Os Availability Groups são criados a partir do Windows Failover Clustering.
O primeiro passo a ser configurado é realizar a criação de um Windows Failover Cluster (WFC) ou
seja realizar a criação de um grupo de servidores alto disponíveis.
Availability Replica Roles: Cada Availability Group ou seja cada grupo contendo diversos bancos
de dados, deverá possuir 2 ou mais parceiros que são chamados de Availability Replicas ou seja
replicas idênticas, para que assim o Failover de uma máquina para outra possa acontecer.
Cada instância do SQL Server no Availability Group é armazenada no Failover Cluster Instance (FCI).
• Esse recurso provê em nível servidor a alta disponibilidade das máquinas e
recursos utilizados.
• Cada Réplica do Availability Group armazena uma cópia idêntica dos bancos de
dados em cada servidor e instância do banco de dados.
Microsoft SQL Server 2012
Modos de Sincronização de Dados: A movimentação dos dados de uma réplica
primária para uma réplica secundária é feita de forma síncrona ou assíncrona.
• Utilizando a forma síncrona = Synchronous-Commit Mode - A transação para
ser
efetivada,
deverá
ser
aceita
em
ambos
servidores,
isso
significa
consideravelmente a latência em rede.
Essa opção é recomendada para servidores que compartilham uma rede de alto
nível.
• Utilizando a forma assíncrona = Assynchronous-Commit Mode - Aceita a
transação na primária sem o parceiro ter escrito essa informação ainda em disco.
Isso aumenta a performance entre os servidores.
• Manual Failover (Failover Manual) - A replica utiliza tanto o modo de
sincronização síncrona como assíncrona e assim possui o direito de realizar
somente um Failover Manual entre os parceiros.
Microsoft SQL Server 2012
Modos de Failover nos Availability Groups: Quando o Availability Group é
configurado, possuímos dois modos de comportamento, são eles:
• Automatic Failover (Failover Automático): A Replica usa o modo de
sincronização sincróna e assim suporta com que o Failover possa ser manual ou
automático.
• Manual Failover (Failover Manual) - A replica utiliza tanto o modo de
sincronização síncrona como assíncrona e assim possui o direito de realizar
somente um Failover Manual entre os parceiros.
Modos de Conexão no Secondário
O modo de conexão para cada servidor secondário pode ser:
• Dissalow Connections (Não Permitir Conexões) : As réplicas secondárias não permitem
que seja realizada nenhuma conexão.
• Allow Only Read-Intent Connections: A réplica permite somente a leitura de conexões
que tem a intenção de ler e passam pelo native client do SQL Server.
• Allow all Connections: É permitido qualquer conexão.
Availability Group Listener: Esse grupo possibilita uma forma de conexão dos
bancos de dados com o Availability Group via uma Virtual Network (Rede
Virtual).
Quando o Availability Group falha então esse grupo redireciona todas as
conexões para o novo servidor que passará a será o primário.
Configuração – Máquinas Virtuais
WinServer2012DC
WinServer2012N1
WinServer2012N2
WinServer2012N3
- Domain Controller; DHCP; - Failover Clustering;
- Failover Clustering;
- Failover Clustering;
DNS; ISCSI; File Server; WINS; - ISCSI Initiator; e
- ISCSI Initiator; e
- ISCSI Initiator; e
e Failover Clustering.
- Microsoft SQL Server 2012
- Microsoft SQL Server 2012
- Microsoft SQL Server 2012
Enterprise.
Enterprise.
Enterprise.
3 Placas de Rede:
2 Placas de Rede:
2 Placas de Rede:
2 Placas de Rede:
• 10.10.10.1
• 10.10.10.4
• 10.10.10.6
• 10.10.10.8
• 10.10.10.2
• DHCP
• DHCP
• DHCP
- 1GB RAM.
- 1GB RAM.
- 1GB RAM.
- 1GB RAM.
- HD 127 GBs.
- HD 127 GBs.
- HD 127 GBs.
- HD 127 GBs.
- VHD 2GBs – Quorum.
-2 CPUs.
- 2 CPUs.
- 2 CPUs.
• 10.10.10.3
- 1 CPU.
Windows Server 2012 Datacenter
Estrutura – SQL Server AlwaysOn
Virtual Machine
Function
Replica
Role
Availabilty Mode
Failover Mode
Node 1
Primary
Synchronous commit
- WinServer2012N1
Primary data
center
Automatic
Node 2
Secondary
Synchronous commit
- WinServer2012N2
Primary data
center
Automatic
Disaster
recovery data
center
Node 3
Secondary
Asynchronous commit (but a
secondary synchronous replica
is permitted; consider the
network latency between the
data centers, and its effect on
performance to the
application)
Manual
- WinServer2012N3
Programmability Enhancements (Database Engine)
http://msdn.microsoft.com/en-us/library/cc645577(v=sql.110).aspx
Techcenter do Microsoft SQL Server
http://technet.microsoft.com/pt-br/sqlserver/default.aspx
Centro de Treinamento Technet de Banco de dados
http://technet.microsoft.com/pt-br/hh210186
http://northamerica.msteched.com
www.microsoft.com/learning
http://microsoft.com/technet
http://microsoft.com/msdn
http://pedrogalvaojunior.wordpress.com