O Mundo Além do Exadata – Parte 1

No post anterior mostrei porque a atualização tecnológica do Exadata não é tão boa quanto parece. Então, quais seriam as alternativas?

Falando de Processadores…

Saindo do Exadata, onde não existem opções de processadores para se escolher, podemos olhar para mais alternativas. Vou incluir dois processadores na comparação para fazermos uma análise de alternativas: são os processadores INTEL E5-2667v3 e E5-2687Wv3.

Podemos observar que eles possuem uma performance por socket “na média” e uma “baixa” contagem de cores por socket. No entanto, em função da velocidade de clock maior, a performance de cada core é substancialmente maior. Um cenário de atualização de infraestrutura, a partir de um modelo full rack X3-2, ficaria então da seguinte forma:

O uso de um destes dois modelos de processador permitiria a atualização da infraestrutura de processamento sem custos adicionais de licenciamento de software, provendo um incremento da capacidade total de processamento. Ambas as alternativas requerem mais servidores do que a alternativa do Exadata X6-2, porém o custo proveniente deste incremento de hardware é muito menor que o custo de licenças de software adicionais requeridas pelo X6-2.

Voltando ao aspecto técnico, o que é melhor? Menos cores mais rápidos ou mais cores menos rápidos?

Considerando a mesma tecnologia de processadores, um clock maior significa que mais instruções podem ser realizadas no mesmo intervalo de tempo, ou de outra forma, que um mesmo conjunto de intruções pode ser realizado num intervalo menor de tempo. Ou seja, o tempo de resposta de uma operação é menor.

Uma das formas de se modelar sistemas computacionais é através da Teoria de Filas. Não vou explicar esta teoria aqui devido à vasta disponibilidade de material sobre o assunto. O que vale aqui é que através dela podemos simular diferentes cenários e ver qual o que apresenta melhores resultados.

O site Orapub disponibiliza uma planilha Excel aqui que permite a comparação fácil de dois cenários. Os parâmetros que eu utilizei para fazer a comparação podem ser vistos abaixo.

Somente os campos em amarelo são modificados e eles ilustram a comparação entre os cenários com 4 x servidores com 2 sockets E5-2699v4 contra 8 x servidores com 2 sockets E5-2667v3. Na planilha, os servidores são representados pelos valores em “Filas no Sistema” (Queues in System), o número de cores em cada servidor (2 sockets em cada) são representados pelos valores em “Servidores por Fila” (Servers per Queue). O tempo de serviço (Service Time) representa quanto tempo é gasto para se executar uma transação e os valores utilizados foram arbitrários porém mantendo a proporção da velocidade de clock e foram obtidos através do inverso da freqüência de clock em GHz. Os demais valores foram arbitrados de forma a permitir a visualização gráfica de forma mais fácil e são a taxa de transações por unidade de tempo (System Arrival Rate) e Tempo de Resposta Tolerado (Response Time Tolerance). O gráfico resultante desta comparação pode ser visto abaixo.

No gráfico acima é possível ver que o “joelho” onde o tempo de resposta aumenta de forma exponencial acontece primeiro no cenário com processadores E5-2699v4 (Case 1), ou seja, o processador E5-2667v3, que é mais rápido (Case 2), permite suportar um número maior de transações antes do tempo de resposta aumentar de forma exponencial. Os valores que foram arbitrados são muito grandes e, conforme mencionado, serviram para facilitar a visualização de forma fácil, mas no mundo real, a diferença no número de transações entre os dois cenários deve ser algumas ordens de grandeza maior (inversamente proporcional ao tempo de serviço).

O Exadata é a Resposta Definitiva? – Parte 3

Uma boa parte dos clientes que compram um Exadata ficam felizes na primeira aquisição, ou seja, na lua-de-mel. Afinal, os problemas de performance que existiam antes se foram em sua grande maioria. Mas não se esqueça que se o investimento fosse feito da forma adequada em infraestrutura, outras alternativas também conseguiriam resolver este problema.

Os problemas começam quando é necessário se fazer um upgrade ou uma atualização da infraestrutura. Todo o charme (desconto) feito para atrair o pretendente se vai e o que passa a acontecer é um embate. Normalmente quem ganha é o mais forte (adivinhe quem?).

As versões iniciais não possuiam flexibilidade de expansão, forçando o cliente a fazer um crescimento casado de armazenamento e processamento, mesmo que um deles não fosse necessário. Esta restrição foi sendo flexibilizada nas últimas versões.

Em termos de atualização do hardware, pouca coisa nova realmente aconteceu. O que pode ser visto na prática foi a atualização dos servidores de banco de dados e dos discos dos storage cells. Mas quanto disso é realmente bom para o cliente?

Existem duas versões de storage cells, sendo uma voltada para desempenho e outra para capacidade. A primeira passou a utilizar módulos de memória não-volátil (NVMe) de alta densidade a partir da versão X5, substituindo os discos rotacionais com interface SAS. Apesar de ser uma atualização válida, vale a pena dar uma lida neste artigo aqui. A versão de alta capacidade passou a utilizar discos de 8TB NL-SAS, confiando ainda numa grande quantidade de cache para obter performance. O porém quanto ao uso de discos desta densidade é em relação à falha de um deles. Imagine o tempo necessário para reconstrução dos dados após a sua substituição. Numa conta arredondada, 8.000.000 de MB sendo escritos à uma taxa de 150MB/s resultam em aproximadamente 15 horas de reconstrução ou, sob outra ótica, de exposição (um disco a menos durante este período), sendo recomendada a implementação de proteção com três cópias (HIGH) e resultando em cerca de somente 30% de área útil em relação ao total bruto.

O mais interessante é em relação à atualização dos processadores. Abaixo está uma tabela com a comparação de performance dos processadores utilizados nos Exadatas a cada geração. Utilizei duas métricas diferentes que podem ser facilmente encontradas na internet, mas é difícil que uma métrica de CPU reflita fielmente a atividade realizada por um banco de dados ou, para ser mais preciso, o seu banco de dados. De qualquer forma, elas refletem a noção de aumento ou redução de performance entre diferentes processadores.

É evidente que a cada nova geração do equipamento, os processadores tem maior capacidade de processamento, sendo que o preço do hardware permanece aproximadamente constante. No entanto, a pergunta que eu faço para você é a seguinte: sabendo que a parte mais cara do projeto é o software e que ele é precificado por core, e não por socket, você está realmente fazendo um bom negócio quando faz uma atualização do equipamento?

Vamos ver então um visão expandida e mais detalhada do quadro anterior.

O que se observa agora é que a performance por core tem decaído ou se mantido constante na melhor das hipóteses, sendo que a contagem de cores aumentou consideravelmente. Aí o seu argumento pode ser o seguinte: “assim é melhor pois posso consolidar tudo num footprint menor!”. Teoricamente você tem razão, mas nem sempre é tão fácil assim.

Poucos clientes possuem configurações full rack ou maiores, sendo a grande maioria dos equipamentos instalados composta de configurações fracionárias, e portanto com pouco potencial de consolidação. Se hoje você possui um equipamento X3-2 1/2 rack e quer atualizar para a versão X6-2, você poderia teoricamente trocar para a configuração imediatamente inferior, que seria a 1/4 rack. Utilizando os dados da tabela acima, este seria o resultado da “atualização” da infraestrutura:

Apesar de ter trocado para uma configuração “menor”, o resultado final é uma quantidade de cores maior. Ou seja, você será obrigado a adquirir licenças adicionais (num incremento de 38% de licenças de banco de dados e respectivos valores de manutenção). Além disso, configurações menores que 1/2 rack possuem um impacto negativo na disponibilidade do ambiente. Na página 5 do o documento Best Practices for Database Consolidation on Exadata Database Machine, pode ser lido o seguinte texto (em tradução livre):

“Há também a opção de implementar um pool de Hardware menor que consiste em um quarter ou oitavo rack Exadata para consolidação entry level. Esta opção é aceitável para aplicações críticas, se um banco de dados standby em um Exadata separado for implantado. Uma pequena desvantagem do HA de um Oracle Exadata Database Machine quarter ou oitavo de rack  é que existem células Exadata insuficientes para os discos de voting residirem em qualquer grupo de discos de alta redundância, que pode ser contornado através da expansão com mais 2 células Exadata. Discos de voting exigem 5 grupos de falha ou 5 células Exadata; esta é uma das principais razões pelas quais um meio rack Exadata é o tamanho mínimo recomendado. Há um risco do Oracle ASM e Oracle Clusterware falharem quando o grupo de discos ASM (onde os discos de voting residem) desmontar  devido a falhas no armazenamento. Nesta situação, todos os bancos de dados falharão, mas eles podem ser reinicializados manualmente seguindo My Oracle Support (MOS) nota 1339373. 1 (Consulte a secção sobre o impacto devido à perda de DBFS_DG).”

Então você não está trocando laranja por laranja exatamente…

O Exadata é a Resposta Definitiva? – Parte 2

No post anterior vimos que o Exadata pode potencialmente endereçar problemas de performance de bancos de dados Oracle, principalmente se eles estiverem ligados ao dimensionamento da infraestrutura. Agora Sr. DBA, todos os seus problemas são de performance?

Alguns dos principais problemas e desafios verificados em clientes Oracle são os seguintes:

• Custo total de propriedade: se você é o responsável por pagar a conta, deve saber que o software Oracle é um dos mais caros no mercado
• Gerenciamento de cópias: necessárias para fins de teste, homologação, treinamento, troubleshooting
• Proteção de dados: incluindo backup, alta disponibilidade e disaster recovery

Naturalmente cada um sabe onde fica o seu calo que dói, e às vezes vale a pena trocar uma dor por outra menor. Vou falar um pouco sobre o custo de um projeto baseado em Oracle.

Há alguns anos, o Wikibon publicou um estudo sobre virtualização de ambientes Oracle, onde eram destacados os custos de um projeto. O gráfico abaixo retirado do site deles mostra a quebra de custos que não deve ser muito diferente da sua, onde fica claro que os maiores gastos estão nas licenças de software Oracle. No entanto, se não é você que paga a conta você não deve saber o quão caro é o que você pede.

Este mesmo estudo mostra ainda que um investimento um pouco maior em infraestrutura permite uma redução significativa dos custos totais de projeto. Esta redução é obtida em função da redução e eliminação de ineficiências e contenções do ambiente que levam à uma maior necessidade de processadores e consequentemente de licenças de software. Lembram-se que eu já falei sobre dimensionamento correto?

Voltemos então ao Exadata…

Considerando que o equipamento do Exadata é baseado em hardware commodity, ele é um equipamento caro. Mesmo assim ele representa uma pequena fração do custo total de projeto, que inclui não somente a aquisição inicial, mas os custos de manutenção anual.

Se você não sabe quanto custa um Exadata, saiba que todos os preços da Oracle são públicos e disponibilizados no seu site. Os preços do hardware podem ser encontrados aqui e os do software aqui.

Ao longo deste post vou usar como referência o modelo X3-2, que é um modelo obsoleto e não é mais produzido. No entanto, servirá para mostrar a evolução dos cenários com as versões subsequentes até a versao X6-2 que foi recém lançada (2016).

Quando se compra um Exadata, é preciso adquirir junto as licenças de software. Na prática, a Oracle “empurra”um conjunto de licenças como se fosse mandatório para o Exadata. No entanto, já vi um ou outro cliente onde esta condição foi flexibilizada em favor do fechamento do negócio no final do ano fiscal. Licenças existentes podem também ser reaproveitadas, se estiverem sem uso. As licenças normalmente “empacotadas” no Exadata são as seguintes:

• Exadata Storage Server Software: cobrada por disco instalado nos storage cells. Os incrementos costumam ser a capacidade do storage cell, ou seja, 12 para os discos HDD e 8 para os módulos de memoria não-volátil (eNVM), sendo que neste ultimo o preço da licença dobra.
• Oracle Enterprise Edition: cobrada por core instalado, assim como todas as Options e Packs a seguir. Por utilizar processadores x86, existe um fator (PCF) de 0.5 para as licenças.
• Real Application Cluster Option
• Partitioning Option
• Advanced Compression Option
• Multitenant Option (a partir da versão 12c)
• Diagnostic Pack
• Tuning Pack

Considerando todos estes software, o preço em dólares e sem impostos de um Exadata é aproximadamente o mostrado abaixo, podendo ser visto as quebras por software e por hardware. Os descontos foram arbitrados para fins ilustrativos e irá depender do poder de negociação de cada cliente ou da época da aquisição. Está sendo considerado um cenário de 5 anos, com o respectivo impacto nos custos de manutenção.

Fica claro que existe um potencial de redução de custos em relação ao Exadata. No entanto, pelo fato dele ser um appliance, sem muitas opções, amarra o custo da solução em algumas configurações. Além disso, será que todas as opções de software oferecidas são realmente necessárias? Existem diversos clientes com Exadata que nunca utilizaram particionamento ou compressão de dados, pois simplesmente não precisam. Considerando somente o custo destas duas Options é possível um investimento num hardware com tecnologia de ponta e eliminando o custo de manutenção anual que as Options agregam. Colabora ainda para o aumento do custo da solução, o fato de todas as funcionalidades da plataforma (por exemplo: proteção de dados) serem executadas pelo software, consumindo mais recursos de CPU com consequente aumento da necessidade de software licenciado.

Antes eu havia dito que achava o hadware do Exadata caro. Parece que me enganei pois o que custa realmente muito caro é o software.

O Exadata é a Resposta Definitiva? – Parte 1

Me lembro até hoje quando participei do Oracle Open World 2008 na qual foi feito o lançamento do Exadata Database Machine. Foi uma ação conjunta com a HP, que logo em seguida ficou a ver navios em função da aquisição da Sun Microsystems pela Oracle. A partir daí o equipamento passou pela evolução tecnológica (?) normal de esperada para qualquer produto, sendo que a estrutura básica se manteve até os dias de hoje.

De uma forma simplificada, o Exadata Database Machine é um equipamento baseado no que se chama de hardware commodity pelo fato de seus componentes serem facilmente encontrados nas “prateleiras”, ou seja, não há nenhum componente especial.

A sua composição física na sua configuração full rack é basicamente:

• Um rack com suas respectivas PDUs
• 8 servidores que são utilizados como servidores de banco de dados, possuindo discos somente para armazenamento do SO e binários do Oracle RDBMS
• 14 servidores que são utilizados como Exadata storage cells, possuindo discos e cartões de memória flash ou módulos de memória não-volátil nas versões mais recentes
• 2 ou mais switches Infiniband para conectividade entre os servidores
• 1 switch GigE para administração da infraestrutura

Como ele se diferencia então da infraestrutura “tradicional” onde você escolhe e monta a sua infraestrutura de banco de dados?

No banco de dados nada muda. O Oracle RDBMS que é executado no Exadata é exatamente o mesmo que está disponível para download no site da Oracle. Porém, algumas funcionalidades somente funcionam quando se detecta os Exadata storage cells ou um storage Pillar através de sinalização SNMP. Falaremos sobre a real necessidade e eficiência destas funcionalidades mais adiante.

No armazenamento e conectividade houveram sim algumas mudanças. Se olharmos para a primeira versão do Exadata, lançado em conjunto com a HP, notamos que o seu foco primário foi os ambientes de Data Warehouse. De forma bem simplista, estes ambientes são caracterizados em geral por um grande volume de dados, onde as consultas precisam ler grandes tabelas para a obtenção das respostas desejadas. Sob o aspecto técnico, o objetivo sempre foi simples: ler mais dados em tempos cada vez menores. Para isso o software foi evoluindo ao longo das diferentes versões com funcionalidades como paralelismo (conhecido no passado como Parallel Query), partititoning, sub-partitioning (falarei sobre isso em outra oportunidade), bitmap index, materialized views, query rewrite, e outras funcionalidades. No entanto, uma boa parte dos DBAs não entendeu que a performance está ligada não somente ao uso correto destas funcionalidades, mas também ao dimensionamento correto da infraestrutura utilizada. De forma geral, a infraestrutura quase sempre estava sub-dimensionada para as demandas específicas destes ambientes, seja pela falta de discos suficientes ou pela reduzida conectividade entre storage e servidores. Ao lançar um appliance (ou Engineered System como a Oracle gosta de chamar), padronizou-se este dimensionamento para satisfazer aos requerimentos destes ambientes que necessitam transferir grandes volumes de dados armazenados para os servidores de banco de dados.

Mas isso é tudo? Não. Quando se executam consultas sobre as grandes tabelas fato as seguintes operações acontecem, entre outras:

1. Os dados são lidos dos discos
2. Os dados são transferidos via fabric (rede) de dados para os servidores de bancos de dados
3. O servidor de banco de dados filtra os dados desejados (como por exemplo, do último mês)
4. O servidor de banco de dados faz os joins e cálculos necessários e retorna o resultado

As etapas 1 e 2 são melhorados com um dimensionamento correto da infraestrutura.

Algumas otimizações foram introduzidas no Exadata para tentar endereçar as etapas 2 e 3:

• Smart Scan: é uma função de off loading, ou seja, o processamento é feito nos storage cells ao invés dos servidores de banco de dados. Para otimizar a transfêrencia de dados entre storage e servidores de banco de dados duas ações podem ser tomadas: aumentar o tamanho do “tubo” por onde passam os dados ou diminuir o volume de dados transferidos. O Smart Scan executa a segunda opção através do processamento prévio dos dados no storage cell mas de maneira restrita às operações mais simples relacionadas à leitura de grandes segmentos de dados em acessos sequenciais (full scans). Note que apesar do volume de dados trafegados ser menor, o Smart Scan não elimina a necessidade de leitura dos dados a partir dos discos.
• Storage Index: também é uma função de off loading e consiste na manutenção de “índices” na memória dos storage cells. O Storage Index é criado automaticamente para até 8 colunas por tabela. Por ser uma estrutura em memória, são criados a partir do acesso aos dados e são perdidos no caso de reboot dos storage cells. Diferente dos índices tradicionais, eles armazenam valores mínimos, máximos e a existência de valores nulos das colunas indexadas. Funcionam em conjunto com o Smart Scan, ou seja, para acessos sequenciais, o que significa que nem todas as operações conseguem tirar proveito deles. Resista portanto à idéia insana de eliminar todos os índices de suas tabelas.
• Uma terceira otimização presente no Exadata é o EHCC (Exadata Hybrid Columnar Compression), que é uma funcionalidade principalmente voltada à economia de espaço de armazenamento. Apesar de reduzir o volume de dados armazenado, ele aumenta o consumo de CPU dos servidores banco de dados e normalmente provoca um impacto na performance, sendo eventualmente utilizado para arquivamento de dados. Dados comprimidos ocupam menos espaço não somente para armazenamento, mas também para serem transferidos.

Como já mencionei anteriormente, o Exadata nasceu com um foco em ambientes de Data Warehouse buscando endereçar a transferência de grandes massas de dados, mas ele serve também para aplicações transacionais (OLTP)? Buscando endereçar este outro mercado, que por sinal é muito maior que o primeiro, foram incorporadas então à segunda versão do Exadata (X2) as placas de Flash Cache, que aumentam substancialmente a performance dos acessos randômicos à disco. Neste tipo de aplicação, as funcionalidades de off loading dos storage cells fazem pouca diferença devido à natureza randômica do acesso aos dados, assim como pouca vantagem tráz a infraestrutura Infiniband, sendo mais importante o tempo de resposta dos acessos aos blocos de pequeno tamanho resultante dos acessos indexados (viu o porquê de não se livrar dos índices confiando cegamente no storage index?). O cache é uma forma inteligente de se utilizar recursos caros de forma otimizada e tirar proveito da chamada localidade de referência, que diz respeito ao acesso mais frequente de determinadas áreas de dados. Diversos fabricantes de storage arrays usam cache com o mesmo objetivo há muitos anos.

Mas nem tudo é perfeito…

A eficiência de armazenamento do Exadata é baixa pois as formas de proteção de dados disponíveis contam com 2 ou 3 cópias dos dados, traduzindo-se em menos de 50% ou 33% de área útil respectivamente. A proteção NORMAL do ASM implica em duas cópias dos dados, que normalmente já significa um elevado nível de proteção de dados quando falamos de storages tradicionais. Porém, este nível de proteção é inadequado no Exadata quando pensamos em uma infraestrutura corporativa onde os requerimentos de disponibilidade são elevados. Pense no seguinte cenário: você vai aplicar um conjunto de patches nos storage cells. Você pode utilizar rolling upgrades e executar esta operação de forma online sem a necessidade de parada do ambiente, certo? Pense bem! Durante a aplicação de patches no storage cell, a mesma pode ficar indisponível e requerer reboots para completar a operação. Durante estes períodos de atualização os dados armazenados no storage cell podem ficar  indisponíveis de forma que parte dos dados ficam apenas com uma cópia. O que aconteceria se por um acaso (lembre-se de Murphy) esta única cópia fosse perdida? Por isto, a recomendação em ambientes críticos é a utilização do esquema de proteção tipo HIGH, que consiste em três (!) cópias dos dados, levando à uma área útil final inferior à 33% do total.

Ainda para deixar claro, ambos os tipos de aplicações podem ser endereçados fora do Exadata, através do uso adequado da infraestrutura e com um aproveitamento muito maior da área de armazenamento.

Em resumo: em termos de tecnologia o Exadata buscou endereçar os problemas de performance em ambientes de Data Warehouse através de um dimensionamento adequado da conectividade e da redução (limitada) da transferência dos dados. Para aplicações OLTP estas melhorias possuem pouco ou nenhum impacto, mas elas são beneficiadas pela disponibilidade de uma grande área de cache incluída posteriormente. Além disso, a eficiência de armazenamento do Exadata é muito baixa se considerarmos os demais players do mercado de armazenamento.