Introdução

Sendo um serviço disponibilizado pela Microsoft baseado em nuvem, o SQL Azure vem a cada dia conquistando mais espaço e valor dentro do mercado atual.

(Figura 1 – Microsoft SQL Azure.)

Antigamente, muitos pensavam que essa tecnologia não iria para frente, isso porque a preocupação de colocar suas informações em um lugar no qual não há o gerenciamento da empresa causava muitas dúvidas e procupações. Vendo isso, à Microsoft passou a trabalhar diante desse propósito, passar ao comprador as condições e todas as seguranças para que suas informações tivessem sim total credibilidade e segurança dentro da nuvem da Microsoft.

Não somente segurança, mais o maior atrativo desse excelente recurso é um Sistema de Alta Disponibilidade e a não-administração. Sem a nuvem, todos os DBA’s passavam por momentos extressantes dentro de uma empresa.

(Figura 2 – Componentes do SQL Azure.)

A necessidade da implementação de políticas, regras e principalmente Alta Disponibilidade, causavam suor e dor de cabeça para todos nós. Com o pensamento mais avançado, a Microsoft não lançou somente a nuvem, mais sim um sistema de alta disponiblidade completo, aonde garante sua informação em dois Data Centers localizados em diversos locais do Globo. Aqui iremos entender essa nova arquitetura, pois o SQL Azure apresenta 3 vertentes que são elas: Database, Reporting e o Data Sync.

(Figura 3 – Banco de Dados do SQL Azure.)

Como parte da solução, temos a criação de uma banco de dados, dentro de um servidor na nuvem, com isso podemos inserir, atualizar, deletar, gerenciar as informações, como tambem realizar a migração de uma banco de dados SQL Server para o SQL Azure.

Migrando um Banco de Dados SQL Server para o SQL Azure no SQL Server 2012.

(Figura 4 – SQL Data Sync.)

Esse serviço disponibilizado na nuvem consiste em realizar a sincronização de um banco de dados SQL Server e SQL Azure, fazendo assim com que as informações sejam sincronizadas na nuvem, com isso temos um agente que realiza essa sincronização.

Realizando a Configuração do SQL Data Sync entre SQL Server e SQL Azure.

(Figura 5 – SQL Reporting.)

Esse novo recurso disponibiliza um servidor de relatório no qual podemos realizar a criação de diversos relatórios e assim realizar a publicação na nuvem.

Implementando o SQL Reporting Services.

Ou seja com isso temos uma plataforma completa, concisa e robusta que nos proporciona um servidor de banco de dados, promovendo assim alta disponibilidade para o mesmo, alêm de possuir um servidor de relatórios.

Arquitetura

(Figura 6 – Acesso ao SQL Azure.)

Os bancos de dados do SQL Azure são armazenados em diversos servidores lógicos dentro dos Data Centers da Microsoft. O SQL Database Gateway funciona como um proxy, realizando a proteção, validãção de logins e acesso a  base de dados.

(Figura 7 – Acesso a bases de dados.)

Sendo assim temos o DB1, DB2 e Db3, cada banco de dados está na instância do Data Center. Cada banco de dados quando criado possuir 3 réplicas, uma sendo a réplica primária e outras duas secondárias. Todas as operações passam pela réplica primária e são replicadas para as outras de modo assincróno.

Na figura acima temos o banco de dados DB1 na máquina 6 e suas réplicas secundárias nas máquinas 4 e 5. Sendo assim entendemos que a distribuição lógica dos bancos de dados no Azure são amarradas a uma conexão, não á uma instância de banco de dados. ou seja o comando USE não pode ser utilizado.

 (Figura 8 – Topologia.)

Camada de Cliente

(Figura 9 – Camada Cliente.)

Essa camada é para gerir a comunicação direta com o banco de dados. Nessa camada o cliente pode possuir um banco de dados SQL Server em seu Data Center ou no Windows Azure.

Camada de Serviço

(Figura 10 – Camada de Serviço.)

A camada de serviço é responsável por rodar o serviço de Gateway, assim como serviços de contas, provisionamento e roteamento.

(Figura 11 – Arquitetura da camada de Serviço.)

Nessa camada temos que:

Quando uma conexão via TDS é aberta sobre o gateway, a primeira fase é a verificação de PARSE do comando e logo em seguida o comando por exemplo CREATE DATABASE é enviado para a camada UTILITY LAYER.

O gateway realiza um handshake com o cliente sendo que essa operação é feita por SSL. Se houver muitas conexões sendo realizadas ao mesmo tempo todas as conexões são rejeitadas. Após isso as credencias são verificadas e somente os IP’s que possuem acesso são permitidos.

Depois da validação realizada, o cluster master é acessado para realizar o mapeamento entre o banco de dados do cliente e o banco de dados do servidor. Depois de encontrado e a conexão aceita, há um retorno positivo para o cliente realizar o acesso.

Camada de Plataforma

(Figura 12 – Camada de Plataforma.)

Nessa camada é aonde há os Hosts para os banco de dados. Cada computador físico é chamado dedata nodes.

(Figura 13 – Estrutura da Camada de Plataforma – Data Nodes ou seja máquinas físicas.)

A cada COMMIT realizado dentro da camada de plataforma é necessário de um quorum commit.Isso quer dizer que para o COMMIT ser aceito, ele deve ser feito na réplica primária e em pelo menos em 1 réplica secundária. No processo da Fabric é realizado os seguintes procedimentos:

Detecção de Falha – Se uma réplica primária ou secundária estiver offline, o agente será disparado.

Agente de Reconfiguração – Gerencia e reestabelece a conexão entre os nodes.

PM (Gerenciador de Partição) – Permite que mensagens sejam enviadas a cada partição.

Engine Throttling (Mecanismo) – Garante que cada servidor lógico (node), não ututilize recursos desnecessários.

Ring Topology (Topologia em Anel) – Gerencia as máquinas, sendo assim cada máquinas possui 2 parentes, que detectam se essa máquinas estão offline.

Camada de Infraestrutura

(Figura 14 – Camada de Infraestrutura.)

Essa camada representa a administração física do harware assim como seu sistema operacional.

Informações

http://msdn.microsoft.com/pt-br/library/hh147515.aspx#azure

http://social.technet.microsoft.com/wiki/contents/articles/1695.inside-windows-azure-sql-database.aspx