InterSystems Caché é um sistema de gerenciamento de banco de dados (DBMS) multimodelo e servidor de aplicações. Veja mais detalhes aqui.
Ao usar SQL padrão ou a camada de objetos no InterSystems IRIS, a consistência dos metadados é geralmente mantida por meio de validação integrada e imposição de tipo. No entanto, sistemas legados que ignoram essas camadas—acessando globals diretamente—podem introduzir inconsistências sutis e graves.
Esta interface web foi projetada para facilitar o gerenciamento de Tabelas de Pesquisa de Dados (Data Lookup Tables) por meio de uma página web amigável. É particularmente útil quando os valores da sua tabela de pesquisa são grandes, dinâmicos e mudam frequentemente. Ao conceder aos usuários finais acesso controlado a esta interface web (permissões de leitura, escrita e exclusão limitadas a esta página), eles podem gerenciar os dados da tabela de pesquisa de forma eficiente, de acordo com suas necessidades.
Os dados gerenciados por meio desta interface podem ser utilizados perfeitamente em regras ou transformações de dados do HealthConnect, eliminando a necessidade de constante monitoramento e gerenciamento manual das tabelas de pesquisa, economizando tempo significativo.
Nota:
Se a Tabela de Pesquisa de Dados padrão não atender aos seus requisitos de mapeamento, você pode criar uma tabela personalizada e adaptar esta interface web, juntamente com sua classe de suporte, com modificações mínimas. O código de exemplo da classe está disponível mediante solicitação.
Quando precisamos integrar o Caché/IRIS com outros bancos de dados relacionais, uma pergunta comum surge: “Como configuro a conexão JDBC?”. A documentação oficial nem sempre fornece um guia passo a passo direto, o que pode ser frustrante, especialmente para iniciantes.
Neste artigo, vou guiá-lo por todo o processo de configuração de uma conexão JDBC com MySQL, desde o download do conector até o espelhamento de tabelas no Caché/IRIS.
Começar a usar ObjectScript é realmente empolgante, mas também pode parecer um pouco estranho se você está acostumado com outras linguagens. Muitos iniciantes tropeçam nos mesmos obstáculos, então aqui estão alguns "pegadinhas" que você vai querer evitar. (Além de algumas dicas amigáveis para contorná-las.)
Nomear Coisas Aleatoriamente
Todos nós já fomos culpados de nomear algo como Test1 ou MyClass apenas para seguir em frente rapidamente. Mas quando seu projeto cresce, esses nomes se tornam um pesadelo.
Você pode verificar o espaço em disco a qualquer momento usando a classe utilitária do sistema: SYS.Database e a consulta: FreeSpace.
Aqui está como testar no terminal IRIS (vá para o namespace %SYS e então execute):
zn"%SYS"set stmt=##class(%SQL.Statement).%New()
set st=stmt.%PrepareClassQuery("SYS.Database","FreeSpace")
set rset=stmt.%Execute()
do rset.%Display()O exemplo de resultado de saída é o seguinte:
O mirror sincroniza apenas arquivos de banco de dados.
Para sincronizar outros arquivos necessários para sua aplicação (arquivos CSP, imagens, documentos, etc.) entre os dois servidores que compõem o conjunto de espelhamento, siga uma das seguintes abordagens:
InterSystems FAQ rubric
Por padrão, a ordem das colunas em uma tabela é determinada automaticamente pelo sistema.
Para alterar a ordem, defina explicitamente a ordem de cada propriedade utilizando a palavra-chave SqlColumnNumber ao definir a classe.
Exemplo:
Property Name As %String [SqlColumnNumber = 2];
Consulte a documentação abaixo.
Se você deseja alterar o nome da tabela SQL, especifiqueSqlTableName. Se você deseja alterar o nome da coluna (nome do campo), especifiqueSqlFieldName.
Ambos se aplicam apenas a classes persistentes.
Ao começar a usar o InterSystems IRIS ou Cache, os desenvolvedores frequentemente se deparam com três conceitos principais: Objetos Dinâmicos, Globals e Tabela Relacional. Cada um tem seu papel na construção de soluções escaláveis e fáceis de manter. Neste artigo, vamos percorrer exemplos de código práticos, destacar as melhores práticas e mostrar como esses conceitos se conectam.
1. Trabalhando com Objetos Dinâmicos
O Guia do Mochileiro do Object Script
O Object Script é nossa linguagem de programação principal no ambiente InterSystems IRIS. Ele também oferece recursos modernos que o tornam poderoso para desenvolvedores.
Para iniciantes, adotar boas práticas de programação desde o início é fundamental para escrever um código de fácil manutenção, eficiente, escalável e claro, seguindo as melhores práticas
Este guia apresenta dicas essenciais para ajudar desenvolvedores “novatos” em ObjectScript a escreverem um código melhor e compreenderem alguns recursos da linguagem.
Antes de tudo: use Nomes Significativos
(Um guia para iniciantes para manter seu código limpo, amigável e à prova de futuro)
Bem-vindo à selva do ObjectScript, onde seu código pode ter escopo global e natureza persistente. Vamos manter as coisas limpas, legíveis e resistentes a bugs.
1️⃣Nomeie como se fosse sério
Se você está investigando Globals estruturadas complexas, isso pode facilmente se tornar um exercício cansativo de digitação.
Diferente do Global Explorer no System Management Portal, o Global-Inspector permite um tipo de navegação aprofundada (drill-down), permitindo explorar nível por nível dos subscritos. Você também tem a opção de visualizar o conteúdo armazenado ou mostrar apenas a estrutura de subscritos. Globals que armazenam tabelas SQL podem não ser tão interessantes, mas no espaço SYSTEM, você encontrará verdadeiras árvores com ramos e ramificações completamente diferentes.
Você está curioso para saber como executar scripts Python diretamente no terminal do InterSystems IRIS ou Caché? 🤔
Boa notícia: é fácil! 😆
O IRIS oferece suporte ao Embedded Python, permitindo que você use Python de forma interativa dentro do terminal do IRIS.
Para iniciar o shell do Python a partir do terminal do IRIS, basta executar o seguinte comando:
do##class(%SYS.Python).Shell()Esse comando abre um shell interativo do Python dentro do terminal do IRIS. A partir daí, você pode escrever e executar código Python como faria em um ambiente Python normal.
Se você está migrando do Oracle para o InterSystems IRIS — como muitos dos meus clientes — pode se deparar com padrões específicos de SQL do Oracle que precisam ser adaptados.
Veja esse examplo:
SELECT (TO_DATE('2023-05-12','YYYY-MM-DD') - LEVEL + 1) AS gap_date
FROM dual
CONNECT BY LEVEL <= (TO_DATE('2023-05-12','YYYY-MM-DD') - TO_DATE('2023-05-02','YYYY-MM-DD') + 1);
No Oracle:
Prezado senhores,
Estou tentando consultar os dados das tabelas de um banco de dados caché. Ele possui dados nas globais. Também possui tabelas SQL sem registros, mas com a estrutura das classes do banco de dados. Quando vou consultar os dados através do driver ODBC não retorna nenhum dado. Mesmo pelo painel administrativo as consultas SQL não retornam dados. Sabem me dizer o que pode estar acontecendo?
At.te
Graciano dos Santos Duarte
foi desenvolvido o seguinte código:
Bom dia!
Tenho o seguinte ClassMethod()
ClassMethod Insere(ID As %BigInt, ...) As %Status [ SqlProc ]
{
; Executa o insert
&()
I 'SQLCODE S ID=%ROWID
I SQLCODE Q $$$ERROR($$$GeneralError,SQLCODE)
Q $$$OK
}
Qual seria uma boa prática para capturar o retorno %Status, na camada de aplicação C# .NET ?
Pessoal,
Poderia me informar se na plataforma InterSystems IRIS, existe uma ferramenta de trace de execução de comandos SQL, procedures entre outros, semelhante ao SQL Profiler?
Grato,
Frequentemente, clientes, fornecedores ou equipes internas me pedem para explicar o planejamento de capacidade de CPU para para grandes bancos de dados de produção rodando no VMware vSphere.
Em resumo, existem algumas práticas recomendadas simples a seguir para dimensionar a CPU para grandes bancos de dados de produção:
Geralmente, isso leva a algumas perguntas comuns:
Respondo a estas perguntas com exemplos abaixo. Mas também lembre-se, as melhores práticas não são imutáveis. Às vezes, você precisa fazer concessões. Por exemplo, é provável que grandes VMs de banco de dados de produção NÃO caibam em um nó NUMA e, como veremos, isso está OK. As melhores práticas são diretrizes que você terá que avaliar e validar para seus aplicativos e ambiente.~
Embora eu esteja escrevendo isso com exemplos para bancos de dados rodando em plataformas de dados InterSystems, os conceitos e regras se aplicam geralmente ao planejamento de capacidade e desempenho para qualquer VM grande (Monstro).
#VMs Monstruosas
Este post é principalmente sobre a implantação de _VMs Monstruosas _, às vezes chamadas de VMs Largas. Os requisitos de recursos de CPU de bancos de dados de alta transação significam que eles são frequentemente implantados em VMs Monstruosas.
Uma VM monstruosa é uma VM com mais CPUs virtuais ou memória do que um nó NUMA físico.
A arquitetura de processador Intel atual possui arquitetura de Memória de Acesso Não Uniforme (NUMA). Por exemplo, os servidores que estou usando para executar testes para este post têm:
Cada processador de 12 núcleos tem sua própria memória local (128 GB de RDIMMs e cache local) e também pode acessar a memória em outros processadores no mesmo host. Os pacotes de 12 núcleos de CPU, cache de CPU e 128 GB de memória RDIMM são um nó NUMA. Para acessar a memória em outro processador, os nós NUMA são conectados por uma interconexão rápida.
Processos em execução em um processador que acessam a memória RDIMM e Cache local têm menor latência do que atravessar a interconexão para acessar a memória remota em outro processador. O acesso através da interconexão aumenta a latência, então o desempenho não é uniforme. O mesmo design se aplica a servidores com mais de dois sockets. Um servidor Intel de quatro sockets tem quatro nós NUMA.
O ESXi entende o NUMA físico e o agendador de CPU do ESXi é projetado para otimizar o desempenho em sistemas NUMA. Uma das maneiras pelas quais o ESXi maximiza o desempenho é criar localidade de dados em um nó NUMA físico. Em nosso exemplo, se você tiver uma VM com 12 vCPUs e menos de 128 GB de memória, o ESXi atribuirá essa VM para ser executada em um dos nós NUMA físicos. O que leva à regra;
Se possível, dimensione as VMs para manter a CPU e a memória locais em um nó NUMA.
Se você precisar de uma VM Monstruosa maior que um nó NUMA, está OK, o ESXi faz um trabalho muito bom calculando e gerenciando automaticamente os requisitos. Por exemplo, o ESXi criará nós NUMA virtuais (vNUMA) que agendam de forma inteligente nos nós NUMA físicos para um desempenho ideal. A estrutura vNUMA é exposta ao sistema operacional. Por exemplo, se você tiver um servidor host com dois processadores de 12 núcleos e uma VM com 16 vCPUs, o ESXi pode usar oito núcleos físicos em cada um dos dois processadores para agendar vCPUs da VM, o sistema operacional (Linux ou Windows) verá dois nós NUMA.
Também é importante dimensionar corretamente suas VMs e não alocar mais recursos do que o necessário, pois isso pode levar a recursos desperdiçados e perda de desempenho. Além de ajudar a dimensionar para NUMA, é mais eficiente e resultará em melhor desempenho ter uma VM de 12 vCPUs com alta (mas segura) utilização de CPU do que uma VM de 24 vCPUs com utilização de CPU de VM baixa ou mediana, especialmente se houver outras VMs neste host precisando ser agendadas e competindo por recursos. Isso também reforça a regra;
Dimensione as máquinas virtuais corretamente.
Nota: Existem diferenças entre as implementações NUMA da Intel e da AMD. A AMD tem múltiplos nós NUMA por processador. Já faz um tempo desde que vi processadores AMD em um servidor de cliente, mas se você os tiver, revise o layout NUMA como parte do seu planejamento.
Para o melhor agendamento NUMA, configure VMs largas;
Correção Junho de 2017: Configure VMs com 1 vCPU por socket.
Por exemplo, por padrão, uma VM com 24 vCPUs deve ser configurada como 24 sockets de CPU, cada um com um núcleo.
Siga as regras de melhores práticas do VMware..
Consulte este post nos blogs do VMware para exemplos.
O post do blog do VMware entra em detalhes, mas o autor, Mark Achtemichuk, recomenda as seguintes regras práticas:
O licenciamento do Caché conta núcleos, então isso não é um problema, no entanto, para software ou bancos de dados diferentes do Caché, especificar que uma VM tem 24 sockets pode fazer diferença para o licenciamento de software, então você deve verificar com os fornecedores.
Hyper-threading (HT) frequentemente surge em discussões, e ouço: "hyper-threading dobra o número de núcleos de CPU". O que, obviamente, no nível físico, não pode acontecer — você tem tantos núcleos físicos quanto possui. O Hyper-threading deve ser habilitado e aumentará o desempenho do sistema. A expectativa é talvez um aumento de 20% ou mais no desempenho do aplicativo, mas a quantidade real depende do aplicativo e da carga de trabalho. Mas certamente não o dobro.
Como postei no post de melhores práticas do VMware, um bom ponto de partida para dimensionar grandes VMs de banco de dados de produção ié assumir que o vCPU tem dedicação total de núcleo físico no servidor — basicamente ignore o hyper-threading ao planejar a capacidade. Por exemplo;
Para um servidor host de 24 núcleos, planeje um total de até 24 vCPUs para VMs de banco de dados de produção, sabendo que pode haver folga disponível.
Após dedicar tempo monitorando o desempenho da aplicação, do sistema operacional e do VMware durante os horários de pico de processamento, você pode decidir se uma consolidação de VMs mais alta é possível. Na postagem de melhores práticas, eu estabeleci a regra como;
Um CPU físico (inclui hyper-threading) = Um vCPU (inclui hyper-threading).
O HT em processadores Intel Xeon é uma forma de criar dois CPUs _lógicos _ CPUsem um núcleo físico. O sistema operacional pode agendar eficientemente nos dois processadores lógicos — se um processo ou thread em um processador lógico estiver esperando, por exemplo, por E/S, os recursos do CPU físico podem ser usados pelo outro processador lógico Apenas um processador lógico pode estar progredindo em qualquer ponto no tempo, então, embora o núcleo físico seja utilizado de forma mais eficiente, o desempenho não é dobrado.
Com o HT habilitado na BIOS do host, ao criar uma VM, você pode configurar um vCPU por processador lógico HT. Por exemplo, em um servidor de 24 núcleos físicos com HT habilitado, você pode criar uma VM com até 48 vCPUs. O agendador de CPU do ESXi otimizará o processamento executando os processos das VMs em núcleos físicos separados primeiro (enquanto ainda considera o NUMA). Eu exploro mais adiante na postagem se alocar mais vCPUs do que núcleos físicos em uma VM de banco de dados "Monster" ajuda no escalonamento.
Após monitorar o desempenho do host e da aplicação, você pode decidir que algum sobrecomprometimento dos recursos de CPU do host é possível. Se esta é uma boa ideia dependerá muito das aplicações e cargas de trabalho. Uma compreensão do agendador e uma métrica chave para monitorar podem ajudá-lo a ter certeza de que você não está sobrecomprometendo os recursos do host.
Às vezes ouço; para que uma VM progrida, deve haver o mesmo número de CPUs lógicos livres que vCPUs na VM. Por exemplo, uma VM de 12 vCPUs deve 'esperar' que 12 CPUs lógicos estejam 'disponíveis' antes que a execução progrida. No entanto, deve-se notar que, no ESXi após a versão 3, este não é o caso. O ESXi usa co-agendamento relaxado para CPU para melhor desempenho da aplicação.
Como múltiplos threads ou processos cooperativos frequentemente se sincronizam uns com os outros, não agendá-los juntos pode aumentar a latência em suas operações. Por exemplo, um thread esperando para ser agendado por outro thread em um loop de espera ocupada (spin loop). Para melhor desempenho, o ESXi tenta agendar o máximo possível de vCPUs irmãs juntas. Mas o agendador de CPU pode agendar vCPUs de forma flexível quando há múltiplas VMs competindo por recursos de CPU em um ambiente consolidado. Se houver muita diferença de tempo, enquanto algumas vCPUs progridem e outras irmãs não (a diferença de tempo é chamada de skew), então a vCPU líder decidirá se interrompe a si mesma (co-stop). Observe que são as vCPUs que fazem co-stop (ou co-start), não a VM inteira. Isso funciona muito bem mesmo quando há algum sobrecomprometimento de recursos, no entanto, como você esperaria; muito sobrecomprometimento de recursos de CPU inevitavelmente impactará o desempenho. Mostro um exemplo de sobrecomprometimento e co-stop mais adiante no Exemplo 2.
Lembre-se que não é uma corrida direta por recursos de CPU entre VMs; o trabalho do agendador de CPU do ESXi é garantir que políticas como shares de CPU, reservas e limites sejam seguidas, maximizando a utilização da CPU e garantindo justiça, throughput, responsividade e escalabilidade. Uma discussão sobre o uso de reservas e shares para priorizar cargas de trabalho de produção está além do escopo desta postagem e depende da sua aplicação e mix de cargas de trabalho. Posso revisitar isso em um momento posterior se encontrar alguma recomendação específica do Caché. Existem muitos fatores que entram em jogo com o agendador de CPU, esta seção apenas arranha a superfície. Para um mergulho profundo, consulte o white paper da VMware e outros links nas referências no final da postagem.
Para ilustrar as diferentes configurações de vCPU, executei uma série de benchmarks usando um aplicativo de Sistema de Informação Hospitalar baseado em navegador com alta taxa de transações. Um conceito semelhante ao benchmark de banco de dados DVD Store desenvolvido pela VMware.
Os scripts para o benchmark são criados com base em observações e métricas de implementações hospitalares reais e incluem fluxos de trabalho, transações e componentes de alto uso que utilizam os maiores recursos do sistema. VMs de driver em outros hosts simulam sessões web (usuários) executando scripts com dados de entrada aleatórios em taxas de transação de fluxo de trabalho definidas. Um benchmark com uma taxa de 1x é a linha de base. As taxas podem ser aumentadas e diminuídas em incrementos.
Juntamente com as métricas do banco de dados e do sistema operacional, uma boa métrica para avaliar o desempenho da VM do banco de dados do benchmark é o tempo de resposta do componente (que também pode ser uma transação) medido no servidor. Um exemplo de um componente é parte de uma tela do usuário final. Um aumento no tempo de resposta do componente significa que os usuários começariam a ver uma mudança para pior no tempo de resposta do aplicativo. Um sistema de banco de dados com bom desempenho deve fornecer alto desempenho consistente para os usuários finais. Nos gráficos a seguir, estou medindo em relação ao desempenho consistente do teste e uma indicação da experiência do usuário final, calculando a média do tempo de resposta dos 10 componentes de alto uso mais lentos. O tempo de resposta médio do componente deve ser inferior a um segundo, uma tela de usuário pode ser composta por um componente, ou telas complexas podem ter muitos componentes.
Lembre-se de que você sempre está dimensionando para a carga de trabalho máxima, mais um buffer para picos inesperados de atividade. Geralmente, busco uma utilização média de 80% da CPU no pico.
Uma lista completa do hardware e software do benchmark está no final da postagem.
É possível criar uma VM de banco de dados dimensionada para usar todos os núcleos físicos de um servidor host, por exemplo, uma VM de 24 vCPUs em um host de 24 núcleos físicos. Em vez de executar o servidor "bare-metal" em um espelho de banco de dados Caché para alta disponibilidade (HA) ou introduzir a complicação do clustering de failover do sistema operacional, a VM do banco de dados é incluída em um cluster vSphere para gerenciamento e HA, por exemplo, DRS e VMware HA.
Tenho visto clientes seguirem o pensamento da velha guarda e dimensionarem uma VM de banco de dados primária para a capacidade esperada no final da vida útil de cinco anos do hardware, mas como sabemos acima, é melhor dimensionar corretamente; você obterá melhor desempenho e consolidação se suas VMs não forem superdimensionadas e o gerenciamento de HA será mais fácil; pense em Tetris se houver manutenção ou falha do host e a VM monstro do banco de dados tiver que migrar ou reiniciar em outro host. Se a taxa de transações for prevista para aumentar significativamente, os vCPUs podem ser adicionados antecipadamente durante a manutenção planejada.
Observação, a opção de 'adicionar a quente' (hot add) de CPU desativa o vNUMA, portanto, não a use para VMs monstro.
Considere o seguinte gráfico mostrando uma série de testes no host de 24 núcleos. A taxa de transações 3x é o ponto ideal e a meta de planejamento de capacidade para este sistema de 24 núcleos.
Há muita coisa acontecendo neste gráfico, mas podemos nos concentrar em algumas coisas interessantes.
Então, chega de dimensionamento correto, e quanto a aumentar as vCPUs, o que significa usar hyper threads? É possível dobrar o desempenho e a escalabilidade? A resposta curta é Não!
Neste caso, a resposta pode ser vista observando o tempo de resposta do componente a partir de 4x. Embora o desempenho seja "melhor" com mais núcleos lógicos (vCPUs) alocados, ele ainda não é plano e consistente como era até 3x. Os usuários relatarão tempos de resposta mais lentos em 4x, independentemente de quantas vCPUs forem alocadas. Lembre-se que em 4x o _host _ já está no limite, com 100% de utilização da CPU, conforme relatado pelo vSphere. Em contagens de vCPU mais altas, mesmo que as métricas de CPU do convidado (vmstat) estejam relatando menos de 100% de utilização, esse não é o caso para os recursos físicos. Lembre-se que o sistema operacional convidado não sabe que está virtualizado e está apenas relatando os recursos apresentados a ele. Observe também que o sistema operacional convidado não vê threads HT, todas as vCPUs são apresentadas como núcleos físicos.
O ponto é que os processos do banco de dados (existem mais de 200 processos Caché na taxa de transação 3x) estão muito ocupados e fazem um uso muito eficiente dos processadores, não há muita folga para os processadores lógicos agendarem mais trabalho ou consolidarem mais VMs neste host. Por exemplo, grande parte do processamento do Caché está ocorrendo na memória, então não há muita espera por IO. Portanto, embora você possa alocar mais vCPUs do que núcleos físicos, não há muito a ganhar porque o host já está 100% utilizado.
Caché é muito bom em lidar com altas cargas de trabalho. Mesmo quando o host e a VM estão com 100% de utilização da CPU, o aplicativo ainda está em execução e a taxa de transações ainda está aumentando — o escalonamento não é linear e, como podemos ver, os tempos de resposta estão ficando mais longos e a experiência do usuário sofrerá — mas o aplicativo não "cai de um penhasco" e, embora não seja um bom lugar para se estar, os usuários ainda podem trabalhar. Se você tiver um aplicativo que não é tão sensível aos tempos de resposta, é bom saber que você pode empurrar até o limite, e além, e o Caché ainda funciona com segurança.
Lembre-se de que você não deseja executar sua VM de banco de dados ou seu host com 100% de utilização da CPU. Você precisa de capacidade para picos inesperados e crescimento na VM, e o hipervisor ESXi precisa de recursos para todas as atividades de rede, armazenamento e outras que realiza.
Eu sempre planejo para picos de 80% de utilização da CPU. Mesmo assim, dimensionar a vCPU apenas até o número de núcleos físicos deixa alguma folga para o hipervisor ESXi em threads lógicos, mesmo em situações extremas.
Se você estiver executando uma solução hiperconvergente (HCI), você DEVE também considerar os requisitos de CPU do HCI no nível do host. Veja minha postagem anterior sobre HCI para mais detalhes. O dimensionamento básico da CPU de VMs implantadas em HCI é o mesmo que o de outras VMs.
Lembre-se, você deve validar e testar tudo em seu próprio ambiente e com seus aplicativos.
Tenho visto sites de clientes relatando desempenho "lento" do aplicativo enquanto o sistema operacional convidado relata que há recursos de CPU de sobra.
Lembre-se de que o sistema operacional convidado não sabe que está virtualizado. Infelizmente, as métricas do convidado, por exemplo, conforme relatado pelo vmstat (por exemplo, em pButtons) podem ser enganosas, você também deve obter métricas de nível de host e métricas ESXi (por exemplo esxtop) para realmente entender a saúde e a capacidade do sistema.
Como você pode ver no gráfico acima, quando o host está relatando 100% de utilização, a VM convidada pode estar relatando uma utilização menor. A VM de 36 vCPU (vermelha) está relatando 80% de utilização média da CPU na taxa de 4x, enquanto o host está relatando 100%. Mesmo uma VM dimensionada corretamente pode ser privada de recursos, se, por exemplo, após a entrada em produção, outras VMs forem migradas para o host ou os recursos forem supercomprometidos por meio de regras DRS mal configuradas.
Para mostrar as principais métricas, para esta série de testes, configurei o seguinte:
Com outro banco de dados usando recursos; na taxa de 3x, o sistema operacional convidado (RHEL 7) vmstat está relatando apenas 86% de utilização média da CPU e a fila de execução tem uma média de apenas 25. No entanto, os usuários deste sistema estarão reclamando alto, pois o tempo de resposta do componente disparou à medida que os processos são desacelerados.
Como mostrado no gráfico a seguir, Co-stop e Tempo de Preparo contam a história de por que o desempenho do usuário é tão ruim. As métricas de Tempo de Preparo (%RDY) e CoStop (%CoStop) mostram que os recursos da CPU estão massivamente supercomprometidos na taxa alvo de 3x. Isso realmente não deveria ser uma surpresa, já que o host está executando 2x (outra VM) e a taxa de 3x desta VM de banco de dados.
O gráfico mostra que o tempo de espera (Ready time) aumenta quando a carga total da CPU no host aumenta.
Tempo de espera (Ready time) é o tempo em que uma VM está pronta para executar, mas não pode porque os recursos da CPU não estão disponíveis.
O co-stop também aumenta. Não há CPUs lógicas livres suficientes para permitir que a VM do banco de dados avance (como detalhei na seção HT acima). O resultado final é que o processamento é atrasado devido à contenção por recursos físicos da CPU.
Eu vi exatamente essa situação em um site de cliente onde nossa visão de suporte de pButtons e vmstat mostrava apenas o sistema operacional virtualizado. Enquanto o vmstat reportava folga de CPU, a experiência de desempenho do usuário era terrível.
A lição aqui é que só quando as métricas do ESXi e uma visão em nível de host foram disponibilizadas é que o problema real foi diagnosticado; recursos de CPU supercomprometidos causados por escassez geral de recursos de CPU do cluster e, para piorar a situação, regras DRS ruins fazendo com que VMs de banco de dados de alta transação migrassem juntas e sobrecarregassem os recursos do host.
Neste exemplo, usei uma VM de banco de dados de linha de base de 24 vCPUs executando a uma taxa de transação 3x, e depois duas VMs de banco de dados de 24 vCPUs a uma taxa de transação constante de 3x.
A utilização média da CPU da linha de base (veja o Exemplo 1 acima) foi de 76% para a VM e 85% para o host. Uma única VM de banco de dados de 24 vCPUs está usando todos os 24 processadores físicos. Executar duas VMs de 24 vCPUs significa que as VMs estão competindo por recursos e estão usando todas as 48 threads de execução lógicas no servidor.
Lembrando que o host não estava 100% utilizado com uma única VM, ainda podemos ver uma queda significativa no throughput e no desempenho, pois duas VMs de 24 vCPUs muito ocupadas tentam usar os 24 núcleos físicos no host (mesmo com HT). Embora o Caché seja muito eficiente ao usar os recursos de CPU disponíveis, ainda há uma queda de 16% no throughput do banco de dados por VM e, mais importante, um aumento de mais de 50% no tempo de resposta do componente (usuário).
Meu objetivo com este post é responder às perguntas comuns. Veja a seção de referência abaixo para um mergulho mais profundo nos recursos de CPU do host e no agendador de CPU do VMware.
Embora existam muitos níveis de ajustes e detalhes técnicos do ESXi para extrair a última gota de desempenho do seu sistema, as regras básicas são bastante simples.
Para grandes bancos de dados de produção :
Se você deseja consolidar VMs, lembre-se de que grandes bancos de dados são muito ocupados e utilizarão intensamente as CPUs (físicas e lógicas) em horários de pico. Não as superinscreva até que seu monitoramento indique que é seguro.
Executei os exemplos neste post em um cluster vSphere composto por dois processadores Dell R730 conectados a um array all-flash. Durante os exemplos, não houve gargalos na rede ou no armazenamento.
PowerEdge R730
PowerVault MD3420, 12G SAS, 2U-24 drive
VMware ESXi 6.0.0 build-2494585
RHEL 7
A taxa de linha de base 1x teve uma média de 700.000 glorefs/segundo (acessos ao banco de dados/segundo). A taxa 5x teve uma média de mais de 3.000.000 glorefs/segundo para 24 vCPUs. Os testes foram permitidos a serem executados até que o desempenho constante fosse alcançado e, em seguida, amostras de 15 minutos foram coletadas e calculadas a média.
Estes exemplos são apenas para mostrar a teoria, você DEVE validar com sua própria aplicação!
A interface de usuário de interoperabilidade agora inclui experiências de usuário modernizadas para os aplicativos Editor DTL e Configuração da Produção que estão disponíveis para aceitação em todos os produtos de interoperabilidade. Você pode alternar entre as visualizações modernizada e padrão. Todas as outras telas de interoperabilidade permanecem na interface de usuário padrão. Observe que as alterações são limitadas a esses dois aplicativos e identificamos abaixo a funcionalidade que está disponível atualmente.
As soluções de Infraestrutura Hiperconvergente (HCI) têm ganhado força nos últimos anos, com o número de implementações agora aumentando rapidamente. Os tomadores de decisão de TI estão considerando HCI ao planejar novas implementações ou atualizações de hardware, especialmente para aplicações já virtualizadas no VMware. As razões para escolher HCI incluem: lidar com um único fornecedor, interoperabilidade validada entre todos os componentes de hardware e software, alto desempenho, especialmente de IO (entrada/saída), escalabilidade simples pela adição de hosts, implementação simplificada e gerenciamento simplificado.
Escrevi este artigo com uma introdução para um leitor que é novo em HCI, analisando os recursos comuns das soluções de HCI. Em seguida, reviso as opções de configuração e recomendações para planejamento de capacidade e desempenho ao implementar aplicativos construídos na plataforma de dados InterSystems, com exemplos específicos para aplicativos de banco de dados. As soluções de HCI dependem do armazenamento flash para desempenho, por isso também incluo uma seção sobre as características e casos de uso de opções selecionadas de armazenamento flash.
O planejamento de capacidade e as recomendações de desempenho neste artigo são específicos para o VMWare vSAN. No entanto, o vSAN não está sozinho no crescente mercado de HCI; existem outros fornecedores de HCI, notóriamente a Nutanix que também possui um número crescente de implementações. Há muita similaridade entre os recursos, independentemente do fornecedor de HCI escolhido, então espero que as recomendações neste artigo sejam amplamente relevantes. Mas o melhor conselho em todos os casos é discutir as recomendações deste artigo com os fornecedores de HCI, levando em consideração os requisitos específicos de sua aplicação.
Estritamente falando, soluções convergentes existem há muito tempo, no entanto, nesta postagem, estou falando sobre as soluções HCI atuais, por exemplo, da Wikipedia: "A hiperconvergência se afasta de múltiplos sistemas discretos que são empacotados juntos e evoluem para ambientes inteligentes__ definidos por software__ que todos rodam em servidores rack x86 de prateleira, de uso geral...."
Não. Ao conversar com fornecedores, você deve lembrar que o HCI tem muitas permutações; Convergido e hiperconvergido são mais um tipo de arquitetura, não um projeto ou padrão específico. Devido à natureza de commodity do hardware HCI, o mercado tem vários fornecedores se diferenciando na camada de software e/ou outras maneiras inovadoras de combinar computação, rede, armazenamento e gerenciamento.
Sem entrar muito em detalhes aqui, como exemplo, soluções rotuladas como HCI podem ter armazenamento dentro dos servidores em um cluster ou ter uma configuração mais tradicional com um cluster de servidores e armazenamento SAN separado – possivelmente de fornecedores diferentes – que também foi testado e validado para interoperabilidade e gerenciado a partir de um único painel de controle. Para planejamento de capacidade e desempenho, você deve considerar que soluções onde o armazenamento está em um array conectado por um fabric SAN (por exemplo, Fibre Channel ou Ethernet) têm um perfil de desempenho e requisitos diferentes do caso em que o pool de armazenamento é definido por software e localizado dentro de cada um dos nós do cluster de servidores com processamento de armazenamento nos servidores.
Para esta postagem, estou me concentrando em HCI e especificamente VMware vSAN onde o_armazenamento está fisicamente dentro dos servidores host._. Nessas soluções, a camada de software HCI permite que o armazenamento interno em cada um dos múltiplos nós em um cluster execute o processamento para agir como um sistema de armazenamento compartilhado. Portanto, outro fator impulsionador do HCI é que, mesmo que haja um custo para o software HCI, também pode haver economias significativas ao usar HCI em comparação com soluções que usam arrays de armazenamento corporativos.
Para esta postagem, estou falando sobre soluções onde o HCI combina computação, memória, armazenamento, rede e software de gerenciamento em um cluster de servidores x86 virtualizados.
Como mencionado acima, VMWare vSAN e Nutanix são exemplos de soluções HCI. Ambos têm abordagens de alto nível semelhantes para HCI e são bons exemplos do formato:
Existem algumas variações na implementação, mas, de modo geral, o HCI possui recursos comuns que informarão seu planejamento de desempenho e capacidade:
Como observei acima, também existem outras soluções HCI com variações nesta lista, como suporte para arrays de armazenamento externo, nós somente de armazenamento... a lista é tão longa quanto a lista de fornecedores.
A adoção do HCI está ganhando ritmo e a concorrência entre os fornecedores está impulsionando a inovação e as melhorias de desempenho. Também vale a pena notar que o HCI é um bloco de construção básico para a implantação em nuvem.
É política e procedimento da InterSystems verificar e lançar os produtos da InterSystems em relação a tipos de processador e sistemas operacionais, inclusive quando os sistemas operacionais são virtualizados. Observe o Aviso da InterSystems: Data Centers Definidos por Software (SDDC) e Infraestrutura Hiperconvergente (HCI)..
Por exemplo: Caché 2016.1 executado no sistema operacional Red Hat 7.2 no vSAN em hosts x86 é suportado.
Observação: se você não escrever seus próprios aplicativos, também deverá verificar a política de suporte de seus fornecedores de aplicativos.
Esta seção destaca considerações e recomendações para a implantação do VMware vSAN para aplicações de banco de dados em plataformas de dados InterSystems - Caché, Ensemble e HealthShare. No entanto, você também pode usar essas recomendações como uma lista geral de perguntas de configuração para revisar com qualquer fornecedor de HCI.
Como ponto de partida, use as mesmas regras de planejamento de capacidade para a vCPU e a memória de suas VMs de banco de dados que você já usa para implantar seus aplicativos no VMware ESXi com os mesmos processadores.
Como um lembrete para o dimensionamento geral de CPU e memória para o Caché, uma lista de outras postagens nesta série está aqui: Planejamento de capacidade e índice de série de performance.
Uma das características dos sistemas HCI (Infraestrutura Hiperconvergente) é a latência de E/S de armazenamento muito baixa e a alta capacidade de IOPS (Operações de Entrada/Saída por Segundo). Você deve se lembrar da segunda postagem desta série, o gráfico dos grupos alimentares de hardware mostrando CPU, memória, armazenamento e rede. Eu destaquei que esses componentes estão todos relacionados entre si e mudanças em um componente podem afetar outro, às vezes com consequências inesperadas.Por exemplo, vi um caso em que a correção de um gargalo de E/S particularmente ruim em um array de armazenamento fez com que o uso da CPU saltasse para 100%, resultando em uma experiência do usuário ainda pior, pois o sistema estava repentinamente livre para fazer mais trabalho, mas não tinha os recursos de CPU para atender ao aumento da atividade do usuário e da taxa de transferência. Esse efeito é algo a se ter em mente ao planejar seus novos sistemas, se seu modelo de dimensionamento for baseado em métricas de desempenho de hardware menos performático. Mesmo que você esteja atualizando para servidores mais novos com processadores mais recentes, a atividade da VM do seu banco de dados deve ser monitorada de perto, caso você precise redimensionar devido à menor latência de E/S na nova plataforma.
Observe também que, conforme detalhado posteriormente, você também terá que considerar o processamento de E/S de armazenamento definido por software ao dimensionar os recursos de CPU e memória do host físico.
Para entender o planejamento da capacidade de armazenamento e colocar as recomendações de banco de dados em contexto, você deve primeiro entender algumas diferenças básicas entre o vSAN e o armazenamento tradicional do ESXi. Abordarei essas diferenças primeiro e, em seguida, detalharei todas as recomendações de melhores práticas para bancos de dados Caché.
No cerne do vSAN e do HCI em geral está o armazenamento definido por software (SDS). A maneira como os dados são armazenados e gerenciados é muito diferente do uso de um cluster de servidores ESXi e um array de armazenamento compartilhado. Uma das vantagens do HCI é que não existem LUNs (Números de Unidades Lógicas), mas sim pools de armazenamento que são alocados para VMs conforme necessário, com políticas que descrevem as capacidades de disponibilidade, capacidade e desempenho por VMDK (Disco Virtual da Máquina Virtual).
Por exemplo; imagine um array de armazenamento tradicional consistindo em prateleiras de discos físicos configurados juntos como grupos de discos ou pools de discos de vários tamanhos, com diferentes números e/ou tipos de discos, dependendo dos requisitos de desempenho e disponibilidade. Os grupos de discos são então apresentados como um número de discos lógicos (volumes de array de armazenamento ou LUNs) que, por sua vez, são apresentados aos hosts ESXi como datastores e formatados como volumes VMFS. As VMs são representadas como arquivos nos datastores. As melhores práticas de banco de dados para disponibilidade e desempenho recomendam, no mínimo, grupos de discos e LUNs separados para banco de dados (acesso aleatório), journals (sequencial) e quaisquer outros (como backups ou sistemas não produtivos, etc.).
vSAN é diferente; o armazenamento do vSAN é alocado usando gerenciamento baseado em políticas de armazenamento (SPBM). Políticas podem ser criadas usando combinações de capacidades, incluindo as seguintes (mas existem mais):
-Falhas a Tolerar (FTT), que dita o número de cópias redundantes de dados.
VMDKs (discos de VM individuais) são criados a partir do pool de armazenamento vSAN selecionando as políticas apropriadas. Então, em vez de criar grupos de discos e LUNs no array com um conjunto de atributos, você define as capacidades de armazenamento como políticas no vSAN usando SPBM; por exemplo, "Banco de Dados" seria diferente de "Diário (Journal)", ou quaisquer outros que você precise. Você define a capacidade e seleciona a política apropriada quando cria discos para sua VM.
Outro conceito chave é que uma VM não é mais um conjunto de arquivos em um datastore VMDK, mas é armazenada como um conjunto de objetos de armazenamento. Por exemplo, sua VM de banco de dados será composta por múltiplos objetos e componentes, incluindo os VMDKs, swap, snapshots, etc. O vSAN SDS gerencia toda a mecânica de posicionamento de objetos para atender aos requisitos das políticas que você selecionou.
Para garantir alto desempenho, existem duas camadas de armazenamento:
Como mostrado no gráfico abaixo, o armazenamento é dividido em camadas e grupos de discos. No vSAN 6.5, cada grupo de discos inclui um único dispositivo de cache e até sete discos rígidos ou dispositivos flash. Pode haver até cinco grupos de discos, possivelmente até 35 dispositivos por host. A figura abaixo mostra um cluster vSAN all-flash com quatro hosts, cada host tem dois grupos de discos, cada um com um disco de cache NVMe e três discos de capacidade SATA.
Figura 1. Armazenamento vSAN all-flash mostrando camadas e grupos de discos
Ao considerar como preencher as camadas e o tipo de flash para as camadas de cache e capacidade, você deve considerar o caminho de E/S; para a menor latência e o máximo desempenho, as escritas vão para a camada de cache, então o software consolida e descarrega as escritas para a camada de capacidade. O uso do cache depende do modelo de implantação, por exemplo, em configurações híbridas do vSAN, 30% da camada de cache é cache de escrita, no caso de all-flash, 100% da camada de cache é cache de escrita -- as leituras são da camada de capacidade flash de baixa latência.
Haverá um aumento de desempenho usando all-flash. Com unidades flash de maior capacidade e durabilidade disponíveis hoje, chegou a hora de você considerar se precisa de discos rígidos. O argumento comercial para flash em vez de discos rígidos foi feito nos últimos anos e inclui custo/IOPS muito menor, desempenho (menor latência), maior confiabilidade (sem partes móveis para falhar, menos discos para falhar para IOPS necessários), menor consumo de energia e perfil de calor, menor espaço físico e assim por diante. . Você também se beneficiará de recursos adicionais de HCI, por exemplo, o vSAN só permitirá deduplicação e compressão em configurações all-flash.
Para o melhor desempenho, a camada de cache deve ter a menor latência, especialmente para o vSAN, pois há apenas um único dispositivo de cache por grupo de discos.
Para SSDs na camada de capacidade, há uma diferença de desempenho insignificante entre SSDs SAS e SATA. Você não precisa incorrer no custo de SSDs NVMe na camada de capacidade para aplicações de banco de dados. No entanto, em todos os casos, certifique-se de que está usando SSDs SATA de classe empresarial com recursos como proteção contra falha de energia.
Dependendo do seu cronograma, novas tecnologias como o 3D Xpoint, com IOPS mais altos, menor latência, maior capacidade e maior durabilidade, podem estar disponíveis. Há uma análise do armazenamento flash no final deste post.
Como mencionei acima, você pode ter até cinco grupos de discos por host e um grupo de discos é composto por um dispositivo flash e até sete dispositivos na camada de capacidade. Você pode ter um único grupo de discos com um dispositivo flash e quanta capacidade precisar, ou vários grupos de discos por host. Existem vantagens em ter vários grupos de discos por host:
Você terá que equilibrar disponibilidade, desempenho e capacidade, mas, em geral, ter vários grupos de discos por host é um bom equilíbrio.
Um requisito fundamental para uma boa experiência do usuário de aplicativos é a baixa latência de armazenamento; a recomendação usual é que a latência de E/S de leitura do banco de dados deve estar abaixo de 10ms. Consulte a tabela da Parte 6 desta série aqui para obter detalhes.
Para cargas de trabalho de banco de dados Caché testadas usando a política de armazenamento vSAN padrão e o utilitário RANREADo Caché, observei E/S de leitura aleatória sustentada de 100% acima de 30K IOPS com menos de 1ms de latência para vSAN all-flash usando SSDs SATA Intel S3610 na camada de capacidade. Considerando que uma regra prática básica para bancos de dados Caché é dimensionar instâncias para usar memória para o máximo de E/S de banco de dados possível, a capacidade de latência e IOPS all-flash deve fornecer ampla margem para a maioria das aplicações. Lembre-se de que os tempos de acesso à memória ainda são ordens de magnitude menores do que até mesmo o armazenamento flash NVMe
Como sempre, lembre-se de que seus resultados podem variar; políticas de armazenamento, número de grupos de discos e número e tipo de discos, etc., influenciarão o desempenho, portanto, você deve validar em seus próprios sistemas!
Você pode calcular a capacidade bruta em TB de um pool de armazenamento vSAN aproximadamente como o tamanho total dos discos na camada de capacidade. Em nossa configuração de exemplo na figura 1 há um total de 24 SSDs INTEL S3610 de 1,6 TB:
Capacidade bruta do cluster: 24 x 1.6TB = 38.4 TB
No entanto, a capacidade _disponível _ é muito diferente e é onde os cálculos se tornam complexos e dependem das escolhas de configuração; quais políticas são usadas (como FTT, que dita quantas cópias de dados) e também se a deduplicação e a compressão foram ativadas.
Vou detalhar políticas selecionadas e discutir suas implicações para capacidade e desempenho, e recomendações para uma arga de trabalho de banco de dados.
Todas as implementações de ESXi que vejo são compostas por múltiplas VMs; por exemplo, o TrakCare, um sistema de informação de saúde unificado construído na plataforma de informática de saúde da InterSystems, HealthShare, tem em seu núcleo pelo menos um grande (monstruoso) servidor de banco de dados VM que se encaixa absolutamente na descrição de "aplicação crítica de negócios de nível 1". No entanto, uma implementação também inclui combinações de outras VMs de propósito único, como servidores web de produção, servidores de impressão, etc. Bem como VMs de teste, treinamento e outras VMs de não produção. Geralmente, todas implantadas em um único cluster ESXi. Embora eu me concentre nos requisitos de VM de banco de dados, lembre-se de que o SPBM pode ser personalizado por VMDK para todas as suas VMs.
Para vSAN, a deduplicação e a compressão são configurações de liga/desliga em todo o cluster. A deduplicação e a compressão só podem ser ativadas quando você estiver usando uma configuração all-flash. Ambas as funcionalidades são ativadas juntas.
À primeira vista, a deduplicação e a compressão parecem ser uma boa ideia - você quer economizar espaço, especialmente se estiver usando dispositivos flash (mais caros) na camada de capacidade. Embora haja economia de espaço com deduplicação e compressão, minha recomendação é que você não habilite esse recurso para clusters com grandes bancos de dados de produção ou onde os dados são constantemente sobrescritos.
A deduplicação e a compressão adicionam alguma sobrecarga de processamento no host, talvez na faixa de utilização de CPU de um único dígito percentual, mas essa não é a principal razão para não recomendar para bancos de dados.
Em resumo, o vSAN tenta deduplicar dados à medida que são gravados na camada de capacidade dentro do escopo de um único grupo de discos, usando blocos de 4K. Portanto, em nosso exemplo na figura 1 os objetos de dados a serem deduplicados teriam que existir na camada de capacidade do mesmo grupo de discos. Não estou convencido de que veremos muita economia nos arquivos de banco de dados Caché, que são basicamente arquivos muito grandes preenchidos com blocos de banco de dados de 8K com ponteiros únicos, conteúdos, etc. Em segundo lugar, o vSAN só tentará compactar blocos duplicados e só considerará os blocos compactados se a compactação atingir 50% ou mais.Se o bloco deduplicado não compactar para 2K, ele será gravado não compactado. Embora possa haver alguma duplicação de sistema operacional ou outros arquivos, _ o benefício real da deduplicação e compressão seria para clusters implantados para VDI_.
Outro aviso é o impacto de uma falha (embora rara) de um dispositivo em um grupo de discos em todo o grupo quando a deduplicação e a compressão estão ativadas. Todo o grupo de discos é marcado como "não saudável", o que tem um impacto em todo o cluster: porque o grupo está marcado como não saudável, todos os dados em um grupo de discos serão evacuados desse grupo para outros locais, então o dispositivo deve ser substituído e o vSAN ressincronizará os objetos para reequilibrar.
Barra Lateral: Espelhamento de banco de dados InterSystems.
Para instâncias de aplicativos de banco de dados Caché de nível 1 de missão crítica que exigem a mais alta disponibilidade, recomendo o espelhamento de banco de dados síncrono da InterSystems, mesmo quando virtualizado. Soluções virtualizadas têm HA (alta disponibilidade) integrada; por exemplo, VMWare HA, no entanto, vantagens adicionais de também usar espelhamento incluem:
- Cópias separadas de dados atualizados.
Acho que você percebeu a falha em habilitar a deduplicação quando você tem bancos de dados espelhados no mesmo cluster? Você estará tentando deduplicar seus dados espelhados. Geralmente não é sensato e também é uma sobrecarga de processamento.
Outra consideração ao decidir se espelhar bancos de dados em HCI é a capacidade total de armazenamento necessária. O vSAN fará várias cópias de dados para disponibilidade, e esse armazenamento de dados será dobrado novamente pelo espelhamento. Você precisará ponderar o pequeno aumento incremental no tempo de atividade em relação ao que o VMware HA fornece, contra o custo adicional de armazenamento.
Para o máximo tempo de atividade, você pode criar dois clusters para que cada nó do espelho de banco de dados esteja em um domínio de falha completamente independente. No entanto, observe o total de servidores e a capacidade de armazenamento para fornecer esse nível de tempo de atividade.
Outra consideração é onde você escolhe criptografar os dados em repouso. Você tem várias opções na pilha de E/S, incluindo;
A criptografia terá um impacto muito pequeno no desempenho, mas pode ter um grande impacto na capacidade se você optar por habilitar a deduplicação ou a compressão no HCI.Se você optar por deduplicação e/ou compressão, não gostaria de usar a criptografia de banco de dados Caché, pois isso negaria quaisquer ganhos, já que os dados criptografados são aleatórios por design e não comprimem bem. Considere o ponto de proteção ou o risco que eles estão tentando proteger, por exemplo, roubo de arquivo versus roubo de dispositivo.
FTT define um requisito para o objeto de armazenamento tolerar pelo menos n falhas simultâneas de host, rede ou disco no cluster e ainda garantir a disponibilidade do objeto. O padrão é 1 (RAID-1); os objetos de armazenamento da VM (por exemplo, VMDK) são espelhados entre os hosts ESXi.
Portanto, a configuração do vSAN deve conter pelo menos n + 1 réplicas (cópias dos dados), o que também significa que existem 2n + 1 hosts no cluster.
Por exemplo, para cumprir a política de um número de falhas a tolerar = 1 , você precisa de três hosts no mínimo em todos os momentos -- mesmo que um host falhe. Portanto, para contabilizar a manutenção ou outros momentos em que um host é retirado do ar, você precisa de quatro hosts.
Observe que também existem exceções; uma configuração de Escritório Remoto de Filial (ROBO) que é projetada para dois hosts e uma VM de testemunha remota.
O método de armazenamento padrão no vSAN é RAID-1 -- replicação ou espelhamento de dados. A codificação de apagamento é RAID-5 ou RAID-6 com objetos/componentes de armazenamento distribuídos entre os nós de armazenamento no cluster. O principal benefício da codificação de apagamento é uma melhor eficiência de espaço para o mesmo nível de proteção de dados.
Usando o cálculo para FTT na seção anterior como um exemplo; para uma VM tolerar _duas _ falhas usando um RAID-1, deve haver três cópias de objetos de armazenamento, o que significa que um VMDK consumirá 300% do tamanho base do VMDK. O RAID-6 também permite que uma VM tolere duas falhas e consuma apenas 150% do tamanho do VMDK.
A escolha aqui é entre desempenho e capacidade. Embora a economia de espaço seja bem-vinda, você deve considerar seus padrões de E/S de banco de dados antes de habilitar a codificação de apagamento. Os benefícios de eficiência de espaço vêm ao preço da amplificação das operações de E/S, que é ainda maior durante os períodos de falha de componentes, portanto, para o melhor desempenho do banco de dados, use RAID-1.
A codificação de apagamento também impacta o número de hosts necessários em seu cluster. Por exemplo, para RAID-5, você precisa de um mínimo de quatro nós no cluster, e para RAID-6, um mínimo de seis nós.
A distribuição de dados (striping) oferece oportunidades para melhorias de desempenho, mas provavelmente só ajudará com configurações híbridas.
O nome para esta configuração vem do vSAN usar objetos para armazenar componentes de suas VMs (VMDKs, etc.).Por padrão, todas as VMs provisionadas em um datastore vSAN têm reserva de espaço de objeto de 0% (provisionamento fino), o que leva a economia de espaço e também permite que o vSAN tenha mais liberdade para o posicionamento de dados. No entanto, para seus bancos de dados de produção, a melhor prática é usar reserva de 100% (provisionamento espesso), onde o espaço é alocado na criação. Para o vSAN, isso será Lazy Zeroed – onde os zeros são escritos à medida que cada bloco é gravado pela primeira vez. Existem algumas razões para escolher reserva de 100% para bancos de dados de produção; haverá menos atraso quando ocorrerem expansões de banco de dados, e você estará garantindo que o armazenamento estará disponível quando precisar.
Geralmente, você pode habilitar os recursos de disponibilidade e economia de espaço após usar os sistemas por algum tempo, ou seja, quando houver VMs e usuários ativos no sistema. No entanto, haverá impacto no desempenho e na capacidade. Réplicas adicionais de dados, além do original, são necessárias, portanto, espaço adicional é exigido enquanto os dados são sincronizados. Minha experiência é que habilitar esses tipos de recursos em clusters com grandes bancos de dados pode levar muito tempo e expor a possibilidade de disponibilidade reduzida.
Existem outras considerações, como deixar espaço livre para balanceamento de disco, falhas, etc. O ponto é que você terá que levar em conta as recomendações deste post com as escolhas específicas do fornecedor para entender seus requisitos de disco bruto.
Você deve considerar a sobrecarga do processamento de armazenamento nos hosts. O processamento de armazenamento, que de outra forma seria tratado pelos processadores em um array de armazenamento empresarial, agora está sendo computado em cada host do cluster.
A quantidade de sobrecarga por host dependerá da carga de trabalho e de quais recursos de armazenamento estão habilitados. Minhas observações com testes básicos que realizei com Caché no vSAN mostram que os requisitos de processamento não são excessivos, especialmente quando você considera o número de núcleos disponíveis nos servidores atuais. A VMware recomenda planejar um uso de CPU do host de 5-10%.
O acima pode ser um ponto de partida para dimensionamento, mas lembre-se de que seus resultados podem variar e você precisará confirmar.
Revise os requisitos do fornecedor -- assuma NICs de 10GbE mínimos -- NICs múltiplos para tráfego de armazenamento, gerenciamento (por exemplo, vMotion), etc. Posso dizer por experiência dolorosa que um switch de rede de classe empresarial é necessário para a operação ideal do cluster -- afinal, todas as gravações são enviadas de forma síncrona pela rede para disponibilidade.
#Visão Geral do Armazenamento Flash
O armazenamento flash é um requisito do HCI, por isso é bom revisar onde o armazenamento flash está hoje e para onde está indo no futuro próximo.
A história curta é que, quer você use HCI ou não, se você não estiver implantando seus aplicativos usando armazenamento com flash hoje, é provável que sua próxima compra de armazenamento inclua flash.
Vamos revisar as capacidades das soluções de armazenamento comumente implantadas e garantir que estamos claros com a terminologia.
Disco rígido
Disco SSD - SATA e SAS
Disco SSD - NVMe
Array de Armazenamento
NVDIMM de Modo Bloco
3D XPoint
Esta é uma tecnologia futura - não disponível em novembro de 2016.
A _resistência _ do dispositivo SSD é uma consideração importante ao escolher unidades para camadas de cache e capacidade. A história curta é que o armazenamento flash tem uma vida finita. As células flash em um SSD só podem ser excluídas e reescritas um certo número de vezes (nenhuma restrição se aplica às leituras). O firmware no dispositivo gerencia a distribuição de gravações pela unidade para maximizar a vida útil do SSD. SSDs empresariais também normalmente têm mais capacidade flash real do que a visível para alcançar uma vida útil mais longa (superprovisionados), por exemplo, uma unidade de 800GB pode ter mais de 1TB de flash.
A métrica a ser observada e discutida com seu fornecedor de armazenamento é o número total de Gravações de Unidade por Dia (DWPD) garantido por um certo número de anos. Por exemplo; um SSD de 800GB com 1 DWPD por 5 anos pode ter 800GB gravados por dia durante 5 anos. Portanto, quanto maior o DWPD (e anos), maior a resistência. Outra métrica simplesmente muda o cálculo para mostrar dispositivos SSD especificados em Terabytes Gravados (TBW); o mesmo exemplo tem TBW de 1.460 TB (800GB * 365 dias * 5 anos). De qualquer forma, você tem uma ideia da vida útil do SSD com base no seu IO esperado.
Esta postagem aborda os recursos mais importantes a serem considerados ao implantar HCI e, especificamente, o VMWare vSAN versão 6.5. Existem recursos do vSAN que não abordei, se eu não mencionei um recurso, assuma que você deve usar os padrões. No entanto, se você tiver alguma dúvida ou observação, ficarei feliz em discutir através da seção de comentários.
Espero retornar ao HCI em futuras postagens, esta certamente é uma arquitetura que está em ascensão, então espero ver mais clientes da InterSystems implantando em HCI.
Pode ser feito com o TRY-CATCH:
#dim ex As%Exception.AbstractExceptionTRY {
//Code that causes an error
}
CATCH ex {
do ex.Log()
}Se você usar o ^%ETN, chame-o a partir do bloco BACK (BACK^%ETN).
Por favor, dê uma olhada também no artigo relacionado: Como buscar erros de aplicação (^ERRORS) usando um comando
Eu e os outros Arquitetos de Tecnologia frequentemente precisamos explicar aos clientes e fornecedores os requisitos de E/S do Caché e a forma como as aplicações Caché utilizarão os sistemas de armazenamento. As tabelas a seguir são úteis ao explicar o perfil e os requisitos típicos de E/S do Caché para uma aplicação de banco de dados transacional com clientes e fornecedores. As tabelas originais foram criadas por Mark Bolinsky.
Em publicações futuras, discutirei mais sobre E/S de armazenamento, portanto, estou publicando essas tabelas agora como referência para esses artigos.
Prezados, é possivel automatizar tarefas de extração de dados no caché?
Ex: Gerar uma tarefa que executa diariamente uma consulta e armazena os dados em um arquivo csv.
Em posts anteriores, mostrei como é possível coletar métricas de desempenho histórico usando pButtons. Recorro ao pButtons primeiro porque sei que ele é instalado com todas as instâncias de Plataformas de Dados (Ensemble, Caché, ...). No entanto, existem outras maneiras de coletar, processar e exibir métricas de desempenho do Caché em tempo real, seja para monitoramento simples ou, ainda, para análises operacionais e planejamento de capacidade muito mais sofisticados. Um dos métodos mais comuns de coleta de dados é usar o SNMP (Simple Network Management Protocol).
SNMP é uma maneira padrão para o Caché fornecer informações de gerenciamento e monitoramento para uma ampla variedade de ferramentas de gerenciamento. A documentação online do Caché inclui detalhes da interface entre o Caché e o SNMP. Embora o SNMP deva 'simplesmente funcionar' com o Caché, existem alguns truques e armadilhas de configuração. Levei alguns começos falsos e ajuda de outras pessoas aqui na InterSystems para fazer o Caché se comunicar com o agente mestre SNMP do Sistema Operacional, então escrevi este post para que você possa evitar a mesma dor.
Neste post, vou detalhar a configuração do SNMP para Caché no Red Hat Linux, e você deve ser capaz de usar os mesmos passos para outras distribuições *nix. Estou escrevendo o post usando o Red Hat porque o Linux pode ser um pouco mais complicado de configurar - no Windows, o Caché instala automaticamente uma DLL para se conectar com o serviço SNMP padrão do Windows, então deve ser mais fácil de configurar.
Uma vez que o SNMP esteja configurado no lado do servidor, você pode começar a monitorar usando várias ferramentas. Vou mostrar o monitoramento usando a popular ferramenta PRTG, mas existem muitas outras - Aqui está uma lista parcial.
Observe que os arquivos MIB do Caché e Ensemble estão incluídos na pasta Caché_installation_directory/SNMP. Os arquivos são: ISC-CACHE.mib e ISC-ENSEMBLE.mib.
Comece revisando "Monitorando o Caché Usando SNMP" na documentação online do Caché..
Siga os passos na seção Gerenciando SNMP no Caché na documentação online do Caché para habilitar o serviço de monitoramento do Caché e configurar o subagente SNMP do Caché para iniciar automaticamente na inicialização do Caché.
Verifique se o processo do Caché está em execução, por exemplo, olhando na lista de processos ou no sistema operacional:
ps -ef | grep SNMP
root 1171 1097 0 02:26 pts/1 00:00:00 grep SNMP
root 27833 1 0 00:34 pts/0 00:00:05 cache -s/db/trak/hs2015/mgr -cj -p33 JOB^SNMP
É só isso, a configuração do Caché está completa!
Há um pouco mais a fazer aqui. Primeiro, verifique se o daemon snmpd está instalado e em execução. Se não estiver, instale e inicie o snmpd.
Verifique o status do snmpd com:
service snmpd status
Inicie ou pare o snmpd com:
service snmpd start|stop
Se o SNMP não estiver instalado, você terá que instalá-lo de acordo com as instruções do sistema operacional, por exemplo: yum -y install net-snmp net-snmp-utils
Conforme detalhado na documentação do Caché, em sistemas Linux, a tarefa mais importante é verificar se o agente mestre SNMP no sistema é compatível com o protocolo Agent Extensibility (AgentX) (o Caché é executado como um subagente) e se o mestre está ativo e escutando conexões na porta TCP padrão do AgentX, 705.
Foi aqui que encontrei problemas. Cometi alguns erros básicos no arquivo snmp.conf que impediram o subagente SNMP do Caché de se comunicar com o agente mestre do sistema operacional. O seguinte arquivo de exemplo /etc/snmp/snmp.conf foi configurado para iniciar o AgentX e fornecer acesso aos MIBs SNMP do Caché e do Ensemble.
Observe que você terá que confirmar se a seguinte configuração está em conformidade com as políticas de segurança da sua organização.
No mínimo, as seguintes linhas devem ser editadas para refletir a configuração do seu sistema.
Por exemplo, altere:
syslocation "System_Location"
para
syslocation "Primary Server Room"
Edite também pelo menos as seguintes duas linhas:
syscontact "Your Name"
trapsink Caché_database_server_name_or_ip_address public
Edite ou substitua o arquivo /etc/snmp/snmp.conf existente para corresponder ao seguinte::
###############################################################################
#
# snmpd.conf:
# Um arquivo de configuração de exemplo para configurar o agente NET-SNMP com o
# Caché.
#
# Isto foi usado com sucesso no Red Hat Enterprise Linux e executando
# o daemon snmpd em primeiro plano com o seguinte comando:
#
# /usr/sbin/snmpd -f -L -x TCP:localhost:705 -c./snmpd.conf
#
# Você pode querer/precisar alterar algumas das informações, especialmente o
# endereço IP do receptor de traps se você espera receber traps. Eu também vi
# um caso (no AIX) onde tivemos que usar a opção "-C" na linha de comando snmpd,
# para garantir que estávamos obtendo o arquivo snmpd.conf correto.
#
###############################################################################
###########################################################################
# SEÇÃO: Configuração de Informações do Sistema
#
# Esta seção define algumas das informações relatadas no
# grupo mib "system" na árvore mibII.
# syslocation: A localização [tipicamente física] do sistema.
# Observe que definir este valor aqui significa que ao tentar
# executar uma operação snmp SET na variável sysLocation.0, o agente
# etornará o código de erro "notWritable". Ou seja, incluir
# este token no arquivo snmpd.conf desativará o acesso de gravação à
# variável.
# argumentos: string_de_localização
syslocation "Localização do Sistema"
# syscontact: As informações de contato do administrador
# Observe que definir este valor aqui significa que ao tentar
# executar uma operação snmp SET na variável sysContact.0, o agente
# retornará o código de erro "notWritable". Ou seja, incluir
# este token no arquivo snmpd.conf desativará o acesso de gravação à
# variável.
# argumentos: string_de_contato
syscontact "Seu Nome"
# sysservices: O valor adequado para o objeto sysServices.
# argumentos: número_sysservices
sysservices 76
###########################################################################
# SEÇÃO: Modo de Operação do Agente
#
# Esta seção define como o agente operará quando estiver em execução.
#
# master: O agente deve operar como um agente mestre ou não.
# Atualmente, o único tipo de agente mestre suportado para este token
# é "agentx".
#
# argumentos: (on|yes|agentx|all|off|no)
master agentx
agentXSocket tcp:localhost:705
###########################################################################
# SEÇÃO: Destinos de Trap
#
# Aqui definimos para quem o agente enviará traps.
# trapsink: Um receptor de traps SNMPv1
# argumentos: host [community] [portnum]
trapsink Caché_database_server_name_or_ip_address public
###############################################################################
# Controle de Acesso
###############################################################################
# Como fornecido, o daemon snmpd responderá apenas a consultas no
# grupo mib do sistema até que este arquivo seja substituído ou modificado
# para fins de segurança. Exemplos de como aumentar o nível de acesso
# são mostrados abaixo.
#
# De longe, a pergunta mais comum que recebo sobre o agente é "por que ele
# não funciona?", quando na verdade deveria ser "como configuro o agente
# para me permitir acessá-lo?"
#
# Por padrão, o agente responde à comunidade "public" para acesso somente
# leitura, se executado diretamente, sem nenhum arquivo de configuração
# no lugar. Os exemplos a seguir mostram outras maneiras de configurar
# o agente para que você possa alterar os nomes da comunidade e conceder
# a si mesmo acesso de gravação à árvore mib também.
#
# Para mais informações, leia o FAQ, bem como a página de manual
# snmpd.conf(5).
#
####
# Primeiro, mapeie o nome da comunidade "public" para um "nome de segurança"
# sec.name source community
com2sec notConfigUser default public
####
# Segundo, mapeie o nome de segurança para um nome de grupo:
# groupName securityModel securityName
group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser
####
# Terceiro, crie uma visualização para que o grupo tenha direitos de acesso:
# Faça com que pelo menos o snmpwalk -v 1 localhost -c public system volte a ser rápido.
# name incl/excl subtree mask(optional)
# acesso ao subconjunto 'internet'
view systemview included .1.3.6.1
# Acesso aos MIBs do Cache Caché e Ensemble
view systemview included .1.3.6.1.4.1.16563.1
view systemview included .1.3.6.1.4.1.16563.2
####
# Finalmente, conceda ao grupo acesso somente leitura à visualização systemview.
# group context sec.model sec.level prefix read write notif
access notConfigGroup "" any noauth exact systemview none none
Após editar o arquivo /etc/snmp/snmp.conf, reinicie o daemon snmpd.
service snmpd restart
Verifique o status do snmpd, observe que o AgentX foi iniciado, veja a linha de status: Ativando o suporte mestre AgentX.
h-4.2# service snmpd restart
Redirecting to /bin/systemctl restart snmpd.service
sh-4.2# service snmpd status
Redirecting to /bin/systemctl status snmpd.service
● snmpd.service - Simple Network Management Protocol (SNMP) Daemon.
Loaded: loaded (/usr/lib/systemd/system/snmpd.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2016-04-27 00:31:36 EDT; 7s ago
Main PID: 27820 (snmpd)
CGroup: /system.slice/snmpd.service
└─27820 /usr/sbin/snmpd -LS0-6d -f
Apr 27 00:31:36 vsan-tc-db2.iscinternal.com systemd[1]: Starting Simple Network Management Protocol (SNMP) Daemon....
Apr 27 00:31:36 vsan-tc-db2.iscinternal.com snmpd[27820]: Turning on AgentX master support.
Apr 27 00:31:36 vsan-tc-db2.iscinternal.com snmpd[27820]: NET-SNMP version 5.7.2
Apr 27 00:31:36 vsan-tc-db2.iscinternal.com systemd[1]: Started Simple Network Management Protocol (SNMP) Daemon..
sh-4.2#
Após reiniciar o snmpd, você deve reiniciar o subagente SNMP do Caché usando a rotina ^SNMP:
%SYS>do stop^SNMP()
%SYS>do start^SNMP(705,20)
O daemon snmpd do sistema operacional e o subagente Caché agora devem estar em execução e acessíveis.
O acesso MIB pode ser verificado a partir da linha de comando com os seguintes comandos. snmpget retorna um único valor:
snmpget -mAll -v 2c -c public vsan-tc-db2 .1.3.6.1.4.1.16563.1.1.1.1.5.5.72.50.48.49.53
SNMPv2-SMI::enterprises.16563.1.1.1.1.5.5.72.50.48.49.53 = STRING: "Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2015.2.1 (Build 705U) Mon Aug 31 2015 16:53:38 EDT"
E snmpwalk irá 'percorrer' a árvore ou ramo MIB::
snmpwalk -m ALL -v 2c -c public vsan-tc-db2 .1.3.6.1.4.1.16563.1.1.1.1
SNMPv2-SMI::enterprises.16563.1.1.1.1.2.5.72.50.48.49.53 = STRING: "H2015"
SNMPv2-SMI::enterprises.16563.1.1.1.1.3.5.72.50.48.49.53 = STRING: "/db/trak/hs2015/cache.cpf"
SNMPv2-SMI::enterprises.16563.1.1.1.1.4.5.72.50.48.49.53 = STRING: "/db/trak/hs2015/mgr/"
etc
etc
Existem também vários clientes Windows e *nix disponíveis para visualizar dados do sistema. Eu uso o iReasoning MIB Browser gratuito. Você precisará carregar o arquivo ISC-CACHE.MIB no cliente para que ele reconheça a estrutura do MIB.
A imagem a seguir mostra o iReasoning MIB Browser no OSX.
É aqui que podem haver grandes diferenças na implementação. A escolha da ferramenta de monitoramento ou análise fica a seu critério.
Por favor, deixe comentários na postagem detalhando as ferramentas e o valor que você obtém delas para monitorar e gerenciar seus sistemas. Isso será de grande ajuda para outros membros da comunidade.
Abaixo está uma captura de tela do popular PRTG Network Monitor mostrando métricas do Caché. Os passos para incluir métricas do Caché no PRTG são semelhantes aos de outras ferramentas.
Certifique-se de que você pode se conectar aos MIBs do sistema operacional. Uma dica é solucionar problemas com o sistema operacional, não com o Caché. É muito provável que as ferramentas de monitoramento já conheçam e estejam pré-configuradas para MIBs comuns de sistemas operacionais, então a ajuda de fornecedores ou outros usuários pode ser mais fácil.
Dependendo da ferramenta de monitoramento que você escolher, pode ser necessário adicionar um 'módulo' ou 'aplicativo' SNMP, que geralmente são gratuitos ou de código aberto. Achei as instruções do fornecedor bastante diretas para esta etapa.
Uma vez que você esteja monitorando as métricas do sistema operacional, é hora de adicionar o Caché.
Importe os arquivos ISC-CACHE.mib eISC-ENSEMBLE.mibpara a ferramenta para que ela reconheça a estrutura do MIB.
Os passos aqui irão variar; por exemplo, o PRTG possui um utilitário 'Importador de MIB'. Os passos básicos são abrir o arquivo de texto ISC-CACHE.mib na ferramenta e importá-lo para o formato interno da ferramenta. Por exemplo, o Splunk usa um formato Python, etc.
Nota:_ Descobri que a ferramenta PRTG expirava o tempo limite se eu tentasse adicionar um sensor com todos os ramos do MIB do Caché. Presumo que ele estava percorrendo toda a árvore e expirou o tempo limite para algumas métricas como listas de processos. Não gastei tempo solucionando esse problema, em vez disso, contornei o problema importando apenas o ramo de desempenho (cachePerfTab) do ISC-CACHE.mib.
Uma vez importado/convertido, o MIB pode ser reutilizado para coletar dados de outros servidores em sua rede. O gráfico acima mostra o PRTG usando o sensor Sensor Factory para combinar vários sensores em um único gráfico.
Existem muitas ferramentas de monitoramento, alerta e algumas ferramentas de análise muito inteligentes disponíveis, algumas gratuitas, outras com licenças para suporte e muitas funcionalidades variadas.
Você deve monitorar seu sistema e entender qual atividade é normal e qual atividade foge do normal e deve ser investigada. SNMP é uma maneira simples de expor métricas do Caché e do Ensemble.
A partir da plataforma de dados InterSystems IRIS® versão 2025.1, a InterSystems está oficialmente descontinuando o MultiValue e incluindo-o na lista de Recursos Descontinuados e Obsoletos. Embora a InterSystems continue a oferecer suporte aos clientes existentes que usam o MultiValue, ele não é recomendado para novos aplicativos.
Pessoal, para consumir dados no caché utilizando uma conexão de uma aplicação java via driver JDBC é necessário realizar alguma configuração adicional no caché?
Instalei um servidor linux oracle 8, neste servidor instalei o oracle 21c xe.
Fiz a instalação do pacote unixODBC unixODBC-devel , abaixo e descompactei os do ODBC-2018.1.5.659.0-lnxrhx64.tar.gz na pasta /usr/local/lib/odbc e configurei os arquivos /etc/odbcinst.ini e /etc/odbc.ini.
usei o comando isql -v CacheDB, fiz select em algumas tabelas e esta funcionado.
Também fiz as configurações na parte do oracle, nos arquivo tnsnames.ora, listener.ora e initCacheDB.ora.
Criei o dblink no oracle, mas ao executar um select no oracle esta retornando erro:
Para executar SQL no Terminal, use $system.SQL.Shell().
Por favor, consulte o exemplo abaixo.
Então, você verificou seu servidor e viu que o IRISTEMP está crescendo demais. Não precisa entrar em pânico. Vamos investigar o problema antes que seu armazenamento acabe.
Antes de assumir que o IRISTEMP é o problema, vamos verificar seu tamanho real.
Execute o seguinte comando no terminal IRIS:
%SYS>do ^%FREECNTQuando solicitado, digite:
Database directory to show free space for (*=All)? /<your_iris_directory>/mgr/iristemp/
Olá!
Este artigo é uma pequena visão geral de uma ferramenta que ajuda a entender classes e sua estrutura dentro dos produtos InterSystems: do IRIS ao Caché, Ensemble e HealthShare.
Em resumo, ela visualiza uma classe ou um pacote inteiro, mostra as relações entre as classes e fornece todas as informações possíveis para desenvolvedores e líderes de equipe sem fazê-los ir ao Studio e examinar o código lá.
Se você está aprendendo os produtos InterSystems, revisando muitos projetos ou apenas interessado em algo novo nas soluções de tecnologia InterSystems - você é mais do que bem-vindo para ler a visão geral do ObjectScript Class Explorer!