No último artigo da série sobre Windows Azure, apresentamos os possíveis ambientes para armazenamento de informaçōes dentro da plataforma. Naquele texto, descrevemos os conceitos de blobs, tables e queues. Se você não realizou a leitura deste texto e não possui os conhecimentos equivalentes, recomendo fortemente a leitura do mesmo antes de prosseguir com a deste. Você pode encontrar a série completa seguindo este link.
No texto de hoje apresentaremos outro serviço de armazenamento disponível na plataforma Azure, propositalmente não mencionado no artigo anterior (sobre Windows Azure Storage) – o SQL Azure. Muito embora o SQL Azure seja também um mecanismo de armazenamento, não foi mencionado anteriormente por se tratar de um serviço mais amplo e com muitas características intrínsecas, justificando assim, a escrita de um texto dedicado a seu estudo.
SQL Azure – Visão Geral
Uma definição razoável para SQL Azure é: “uma plataforma para gerenciamento de dados relacionais executada no modelo de PaaS (Plataforma as a Service) pelo Windows Azure”. O objetivo da Microsoft ao disponibilizar uma plataforma de gerenciamento de dados relacionais, é proporcionar um ambiente robusto, escalável horizontalmente e altamente disponível (apenas para citar algumas das vantagens da computação em nuvem) também para bases de dados.
A beleza da computação em nuvem e, especialmente do modelo PaaS, consiste justamente no fato de que ela “esconde” toda a complexidade de gerenciamento de hardware, entregando ao usuário final um ambiente saúdável, escalável, resiliente e com isso, altamente disponível para os dados. Se esta é a beleza, o modelo para gerenciamento de bancos de dados (e qualquer outro serviço) não pode quebrá-lo.
Dado o cenário do parágrafo anterior, é preciso observar que o SQL Azure é uma versão de cloud computing do já conhecido e consolidado SQL Server do modelo on-premisses. O fato de “ser uma versão de nuvem” do SQL Server, implica necessariamente que alguns recursos nativos neste ambiente não esteja no modelo de cloud. De forma geral, encontram-se ausentes os recursos associados ao gerenciamento de recursos físicos, tais como: drive de gravação de backups, comandos de replicação, configurações de RAID, etc. O motivo deste tipo de recurso estar indisponível é simples: o Windows Azure realiza estas operações de forma automática.
A Figura 1 apresenta o modelo de gerenciamento de dados em nuvem proposto pelo SQl Azure.
Figura 1. O modelo de gerenciamento de dados proporcionado pelo SQL Azure
Antes de falarmos individualmente sobre os componentes disponibilizados pelo SQL Azure (vide Figura 1), vamos a descrição de alguns aspectos importantes associados ao serviço e que devem ser levados em consideração ao projetar um banco de dados na nuvem. São eles:
-
SQL Azure é uma versão de bancos de dados relacional que, de forma análoga a seu modelo on-premisses, é baseada no modelo T-SQL. Se você não está familiarizado com este conceito, recomendo fortemente realizar a leitura deste link (em inglês).
- Muito embora seja baseada no modelo T-SQL, alguns recursos disponíveis no modelo on-premisses não encontram-se disponíveis no modelo proposto pelo SQL Azure. Principalmente aqueles recursos associados ao gerenciamento físico das instâncias de bancos de dados, pelos motivos já mencionados anteriormente.
- Muito embora não seja possível administrar recursos físicos no SQL Azure, a administração de recursos lógicos está mantida. DBAs (Database Administrators) poderão criar e administrar esquemas, contas de usuários, tarefas, visualizar planos de execução, realizar tunning de queries e índices, etc.
- SQL Azure permite que os profissionais possam criar backups manuais de suas instâncias de bancos de dados. Uma das formas possíveis é carregar o conteúdo de um banco de dados em outro pré-existente.
- Ao criar um banco de dados no SQL Azure, a plataforma replica seu banco de dados em três diferentes nodos no mesmo datacenter (se preferir cluster). Isso é naturalmente realizado para prover “alta disponibilidade” de sua estrutura de bancos de dados.
- Bases de dados hospedadas no SQL Azure podem ser federadas. Falaremos mais deste recurso em um artigo futuro nesta mesma série.
- SQL Azure possui um modelo de provisionamento que pode ser realizado de forma simplificada através de um portal web. No modelo on-premisses este provisionamento era mais complexo de ser realizado e o índice de erros neste processo acabava sendo demasiadamente alto.
- Ao criar um servidor de banco de dados SQL Azure, um range de IPs devem ser informado para que os bancos do servidor possam ser acessados. Isto é feito para implementar segurança ao modelo de dados do Windows Azure.
A arquitetura do SQL Azure
SQL Azure é um serviço de banco de dados na nuvem que é executado em servidores com SQL Server nos datacenters da Microsoft. Assim, arquiteturalmente, podemos visualizar o SQL Azure em quatro camadas distintas, apresentadas na Figura 2.
Figura 2. As camadas de aplicações do SQL Azure
Como é possível observar, são quatro camadas distintas cada uma executando um determinado set de funções. A seguir descrevemos cada uma delas.
1. Camada de Cliente
A camada do cliente é onde se encontra hospedada a aplicação. Esta primeira camada disponibiliza basicamente todos os recursos necessários para que a comunicação com SQL Azure possa ser realizada. Este ambiente pode ser on-premisses, o próprio Windows Azure ou ainda, híbrido (uma mesca entre on-premisses e cloud).
Este modelo é possível porque SQL Azure trabalha com Tabular Data Stream (TDS), um protocolo que faz o interfaceamento e a transferência dos dados entre a aplicação e o SQL Azure. Você pode encontrar mais informações sobre TDS seguindo este link (Wikipedia, em inglês).
2. Camada de Serviço
A camada de serviço atua como um agente conector entre a camada cliente e a camada de plataforma (onde efetivamente os dados encontram-se armazenados). Basicamente são três agentes internos a esta camada: provisionamento, billing e roteamento de conexão.
3. Camada de Plataforma
A camada de plataforma é aquela responsável por implementar todos os recursos físicos necessários, tanto para hospedar as informações quanto para suportar os recursos implementados na camada de serviço. É nesta camada que as intâncias físicas de SQL encontram-se armazenas e são geridas pelo SQL Azure Fabric.
Em linhas gerais, o SQL Azure Fabric é um orquestrador de banco de dados. Atrvés dele, são executados: balanceador de carga, tolerância a falhas que, nos final das contas, gera a alta disponibilidade dos bancos.
4. Camada de infraestrutura
Esta camada encapsula as operações de hardware. Todos os recursos relacionados a manutenção física da infraestrura de bancos de dados são agrupadas nesta camada.
Recursos que compõem o SQL Azure
A Figura 1 apresenta dois componentes principais disponibilizados como recursos (além da plataforma de dados em sí) do SQL Azure. São eles: Reporting Services e Data Sync. Nesta seção, apresento as principais características associadas a cada um deles.
1. SQL Azure Reporting Services (SARS)
O SQLAzure Reporting Services é uma ferramenta dedicada a criação de relatórios com base nos dados armazenados no SQL Azure. Na nuvem, as aplicações utilizam o modo remoto do ReportViewer para gerar e gerenciar seus relatórios. Com SARS é possível criar também relatórios com base em análises não convencionais (Business Inteligence).
Em relação aos recursos associados ao SQL Azure Reporting Services, boa parte do que encontra-se disponível para SQL Server na versão on-premisses está disponível também na versão de nuvem do SARS.
2. SQL Azure Data Sync
Em linhas gerais, o SQL Data Sync é um recurso que permite a replicação dos dados (e não da instância do banco de dados). Para que esta ideia fique mais clara, considere o seguinte cenário:
Uma aplicação web precisa manter uma cópia do banco de dados hospedado no Windows Azure também no ambiente on-premisses. A ideia é que os dados disponíveis na nuvem estejam disponíveis também no ambiente local. Como resolver este tipo de problema?
SQL Azure Data Sync é o recurso disponível dentro da plataforma para endereçar este tipo de cenário. Com ele, sem a necessidade de escrever uma linha de código sequer, os dados disponíveis no SQL Azure poderiam ser automaticamente sincronizados entre: diversar instâncias de SQL Azure ou ainda, instâncias de SQL Azure com instâncias de SQL Server tradicionais.
Vale mencionar que a comunicação é bidirecional logo, os dados podem ser replicados tanto de bancos de dados do SQL Azure para SQL Server quanto o contrário.
Do ponto de vista de segurança dos dados, todas conexões, dados mais sensíveis e transações são criptografados, fato que garante a segurança das informações geradas no domínio do cliente. Além disso, diversas autenticações são realizadas durante o processo. Algumas delas são:
- O agente SQL do cliente autentica os usuários locais com a segurança do próprio Windows.
- O SQL Azure Data Sync cria uma chave única de acesso para a comunicação com o agente SQL local.
- O SQL Azure Data Sync utiliza certificados digitais para autenticar acessos a diferentes módulos de uma aplicação dentro do Windows Azure.
SQL Azure Federation
SQL Azure Federation é uma das formas disponibizadas dentro da plataforma Azure para proporcionar maior escalabilidade e capacidade de armazenamento para bancos de dados relacionais.
A ideia de “federação” é sinônima a de partição. Sim, ao dizermos que uma base de dados está federada estamos dizendo que os dados armazenados em determinado banco encontram-se divididos/particionados entre diversas sub instâncias de bancos de dados (membros federados) ao longo dos servidores de datacenter do Windows Azure. A Figura 3 apresenta a ideia deste modelo.
Figura 3. O modelo de federação de dados
Como é possível observar, a federação pode ser realizada através de um campo chave. De forma generalista, a função do campo chave de federação é a de unir os dados federados no momento em que estes forem requisitados pela aplicação que os consomem. A chave de federação deve necessariamente possuir um dos seguintes tipos de dados: int, bigint, uniqueidentifier ou varbinary.
Bom pessoal, por hoje é isso. Fique atento aos próximos posts da série.
Pingback: O que significam os DTU’s das novas instâncias Azure SQL Databases? – Fabrício Sanchez