Administração de sistemas se refere ao gerenciamento de um ou mais sistemas de hardware e software.
Documentação sobre administração de sistemas InterSystems.
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:
Para habilitar a funcionalidade de Interoperabilidade após criar um namespace, use o método EnableNamespace da classe %EnsembleMgr:
do ##class(%EnsembleMgr).EnableNamespace()
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!
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.
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.
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.
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:
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/Monitorar sua implantação do IRIS é crucial. Com a descontinuação do System Alert and Monitoring (SAM), uma solução moderna e escalável é necessária para obter insights em tempo real, detecção precoce de problemas e eficiência operacional. Este guia aborda a configuração do Prometheus e Grafana no Kubernetes para monitorar o InterSystems IRIS de forma eficaz.
Este guia pressupõe que você já tenha um cluster IRIS implantado usando o InterSystems Kubernetes Operator (IKO), que simplifica a implantação, integração e gerenciamento.
Você pode configurar o tamanho máximo do banco de dados IRISTemp na inicialização do IRIS ao definir um parâmetro de configuração chamado MaxIRISTempSizeAtStart.
Após a definição, o sistema truncará o IRISTemp para o valor definido (MB) na próxima inicialização do IRIS. Se o tamanho atual for menor que o MaxIRISTempSizeAtStart especificado, não ocorrerá nenhum truncamento. Além disso, se for especificado 0, o truncamento não será realizado, então o tamanho será inicializado sem alteração. As configurações (padrão) são realizadas no menu abaixo.
Portal de Gerenciamento
[Administração do Sistema] > [Configuração] > [Configurações adicionais] > [Inicialização] > "MaxIRISTempSizeAtStart"
.png)
.png)
Para mais detalhes, consulte a página de documentação abaixo.
MaxIRISTempSizeAtStart
Neste tutorial, vou discutir como você pode conectar sua plataforma de dados IRIS a uma base de dados sql server.
Prerequisitos:
Para resolver o erro <PROTECT>, remova o atributo somente leitura do banco de dados da biblioteca de todo o sistema (IRISLIB para InterSystems IRIS, CACHELIB para Caché/Ensemble/HealthShare (baseado em Caché))
Quando terminar de importar a rotina, lembre-se de alterá-la novamente para somente leitura.
[Versão 2013.1 e acima]
[Portal de Gerenciamento] > [Administração do Sistema] > [Configuração] > [Configuração do Sistema] > [Banco de Dados Local] Desmarque "Mount read-only" (Montar somente leitura) no link do nome do banco de dados.
.png)
[Versão 2011.1 - Versão 2012.2]
[Portal de Gerenciamento] > [Administração do Sistema] > [Configuração] > [Configuração] > [Banco de dados local] Mude "Read-only?" (Somente leitura?) de [Editar] do banco de dados relevante.
[Versão 2010.2 ou mais recente]
[Portal de Gerenciamento de Sistemas] > [Configuração] > [Banco de Dados Local] Mude "Read-only?" (Somente leitura?) de [Editar] do banco de dados relevante.
Geralmente, o banco de dados da biblioteca de todo o sistema (IRISLIB/CACHELIB) armazena as rotinas com % que são reservadas pelos produtos da InterSystems. As rotinas escritas pelo usuário com nomes de rotinas %a* a %y* são armazenadas no banco de dados da biblioteca de todo o sistema(IRISLIB/CACHELIB).
Ao salvar rotinas definidas pelo usuário com % no sistema, recomendamos nomes que começam com %Z ou %z.
As rotinas que começam com %Z, %z são armazenadas no banco de dados do sistema ("IRISSYS" para InterSystems IRIS e "CAHESYS" para Caché/Ensemble/HealthShare) e são transferidas ao fazer upgrade dos produtos da InterSystems.
Observe que as rotinas com %, além das %Z e %z salvas no banco de dados da biblioteca de todo o sistema (IRISLIB/CACHELIB), serão excluídas durante o upgrade.
Isso pode ser obtido com uma query de lista da classe %SYS.Namespace
1. Crie uma rotina assim:
getnsp
set statement=##class(%SQL.Statement).%New()
set status=statement.%PrepareClassQuery("%SYS.Namespace","List")
set resultset=statement.%Execute()
while resultset.%Next() {
write resultset.%Get("Nsp"),!
}
quit2. Rode no seu terminal
O método de executar queries de classe introduzido nesse artigo pode ser aplicado em uma variedade de classes
O número máximo de namespaces que se podem criar em uma instância é de 2047. No entanto, para utilizar um grande número de namespaces, é necessário configurar a memória adequadamente.
O número máximo de bases de dados (incluso as bases de dados remotas) que se pode criar em uma instância é de 15.998. Dependendo do tipo de licença, pode haver restrições sobre a quantidade que se pode criar. Para mais detalhes, consulte o seguinte documento.
Configuração da Base de Dados [IRIS]
Configuração da Base de Dados
Aqui, vamos introduzir um código de exemplo para registrar e referenciar agendas de tarefas.
①Exemplo de registro de agenda de tarefa
*Crie uma tarefa para executar ^TEST todos os dias à 1:00 da manhã.
Se necessita migrar seu servidor por algum motivo, pode reduzir o trabalho de configuração do novo ambiente. Basta copiar a informação de configuração de seu ambiente prévio ao novo.
Você pode migrar as seguintes informações de configuração.
Globais temporárias armazenadas nas bases de dados IRISTEMP/CACHETEMP são usadas quando um processo não precisa guardar dados indefinidamente, mas requere a poderosa performance das globais. As bases de dados IRISTEMP/CACHETEMP não são jounralizadas, então usar globais temporárias não cria arquivos de journal.
O sistema usa as bases de dados IRISTEMP/CACHETEMP para armazenamento temporário e estão disponíveis para usuários para o mesmo objetivo.
Talvez você já tenha reparado que a base HSAUDIT não tem uma tarefa de expurgo já configurada na maioria das versões do HealthShare, e isso pode ser um problema já que ela tem mapeamentos de globais em vários namespaces.
Se você notou que essa base está ocupando muito espaço em disco e está com dificuldades de limpá-la, esse artigo é para você.
Se você já tem uma ideia de como fazer isso, mas está utilizando uma versão mais antiga do HealthShare, onde a tarefa não existe pronta, ou o PurgeByDaysToKeep não existe, esse artigo também é para você.
IS Comunidade de Desenvolvedores, Eu 👑 você.
O Enterprise Monitor é um componente do Ensemble e pode ajudar as organizações a monitorar várias produções executadas em diferentes namespaces na mesma instância ou em namespaces executados em várias instâncias.
A documentação pode ser encontrada em:
No Ensemble 2016.1, foram realizadas mudanças para esse utilitário funcionar com ambientes do HealthShare.
Este artigo mostrará o seguinte:
Para este artigo, usei a seguinte versão do HealthShare:
Cache para Windows (x86-64) 2016.1 (Build 656U) Sex 11 Mar 2016 17:42:42 EST [Módulos do HealthShare:Core:14.02.2415 + Linkage Engine:14.02.2415 + Patient Index:14.02.2415 + Clinical Viewer:14.02.2415 + Active Analytics:14.02.2415] __
O Enterprise Monitor é executado no seu próprio namespace e pode estar localizado em uma instância existente ou separada. Neste artigo, ele será executado na mesma instância.
Para criar um namespace:
Neste exemplo, criei um namespace HSMONITOR. Também criei um banco de dados chamado HSMONITOR
Captura de tela de como criar um namespace:
Para instâncias do HealthShare, o aplicativo da Web define, por padrão, o "Session Cookie Path" (Caminho do cookie da sessão) como "/csp/healthshare/". Se o namespace do Enterprise Monitor estiver em uma instância com outros namespaces do HealthShare, mude o "Session Cookie Path" do namespace do Enterprise Monitor para "/csp/healthshare/[namespace]/".
Para mudar o aplicativo da Web:
Captura de tela de como alterar o aplicativo da Web:
O Enterprise Monitor usa serviços da Web para se comunicar com diversos sistemas, então ele precisa de um nome de usuário/senha para validar a comunicação. O Ensemble consegue fazer isso usando credenciais. Todos os namespaces do HealthShare usam credenciais com o nome de usuário "HS_Services"
Vamos adicionar "HS_Services" às credenciais do namespace do Ensemble que criamos para o Enterprise Monitor.
Etapas para criar uma credencial:
Captura de tela de como adicionar credenciais:
Em seguida, criamos uma produção que usa o serviço empresarial "Ens.Enterprise.MonitorService". Essa é a produção que será executada no namespace do Enterprise Monitor que configuramos.
Confira a seguir a produção que criei. Observe que ela estende "Ens.Enterprise.Production" e inclui um item de serviço empresarial, que foi adicionado (Ens.Enterprise.MonitorService).
Class HSMONITOR.MonitorProduction Extends Ens.Enterprise.Production
{
XData ProductionDefinition
{
<Production Name="HSMONITOR.MonitorProduction">
<ActorPoolSize>2</ActorPoolSize>
<Item Name="Ens.Enterprise.MonitorService" ClassName="Ens.Enterprise.MonitorService" PoolSize="1" />
</Production>
}
}
Depois disso, você pode iniciar a produção no namespace do Enterprise Monitor que você criou. Nesse exemplo, iniciei o HSMONITOR.MonitorProduction no meu namespace HSMONITOR.
Agora que a produção está sendo executada, podemos adicionar os sistemas empresariais que queremos monitorar.
Para criar um novo sistema empresarial:
Captura de tela dos sistemas empresariais:
Para adicionar uma nova conexão:
Captura de tela de como adicionar uma conexão a HSREGISTRY:
Você pode adicionar vários sistemas empresariais para refletir seus ambientes do HealthShare. É possível adicionar gateways de borda, gateways de acesso, outros componentes do HealthShare, como Personal Community, Patient Index, Health Insight, etc.
A maioria das informações do HealthShare está localizada no registro de serviços.
Coloquei meu namespace do Enterprise Monitor na mesma instância que o HSREGISTRY.
Escrevi e executei o seguinte código no meu namespace HSMONITOR para criar sistemas empresariais de forma automática com base nas informações localizadas no registro de serviços.
Código de amostra:
ClassMethod BuildEM()
{
set tSaveNamespace = $namespace
zn "HSREGISTRY"
set sql="select EndPoint,Name,Info from HS_Registry_Service.SOAP"
set statement = ##class(%SQL.Statement).%New()
set tSC = statement.%Prepare(sql)
quit:$$$ISERR(tSC)
set result = statement.%Execute()
while result.%Next() {
set tEndPoint = result.EndPoint
set tName = result.Name
set tInfo = result.Info
If tName = "HSREGISTRY" set tName = ":"_tName
If tName = "HSPI" set tName = ":"_tName
If $p(tName,":",2) = "WebServices" set tName = ":"_tName
If tName = "HSCommunity.PIXv3.Consumer" set tName = ":HSCOMMUNITY"
Continue:$p(tName,":",2)=""
set tMCName = $p(tName,":",2)
set tMCNamespace = $p(tEndPoint,"/",6)
set tMCWebIP = tInfo
set tMCHomePath = "/"_$p(tEndPoint,"/",4,6)_"/"
set tMCServicePath = "/"_$p(tEndPoint,"/",4,7)_"/"
set aMC(tMCName)=$lb(tMCNamespace,tMCWebIP,tMCHomePath,tMCServicePath)
}
zn tSaveNamespace
///Now we have an array of namespaces, create Monitor entries
set tName = ""
do {
set tName=$O(aMC(tName))
if tName '="" {
set tMonitorClient = ##class(Ens.Enterprise.MonitorClient).%New()
set tMonitorClient.Name=tName
set tMonitorClient.WebIPAddress=$list(aMC(tName),2) ;IP/Port
set tMonitorClient.Namespace=$list(aMC(tName),1) ;NameSpace
set tMonitorClient.HomePage="%25CSP.Portal.Home.zen"
set tMonitorClient.HomePath=$list(aMC(tName),3) ;"/csp/healthshare/[namespace]/"
set tMonitorClient.QueueThreshold=""
set tMonitorClient.ServicePath=$list(aMC(tName),4) ;"/csp/healthshare/[namespace]/services/"
set tMonitorClient.SOAPCredentials="HS_Services"
set tMonitorClient.SSLCheckServerIdentity="1"
set tMonitorClient.SSLConfig=""
set tMonitorClient.Version="2016.1.1.108.1."
set tSC=tMonitorClient.%Save()
w !,tName,": ",$system.Status.DisplayError(tSC)
}
} while tName '= ""
quit
}
Agora que temos entradas no sistema empresarial, você verá uma nova opção de menu no namespace do Enterprise Monitor do Ensemble. Essa nova opção de menu será "Enterprise Monitor".
Captura de tela da nova opção de menu:
Ao selecionar "Enterprise Monitor", vemos o seguinte:
Agora podemos ver em um único local quais produções do HealthShare estão "Running" (em execução) ou "Stopped" (interrompidas), com links para as configurações das que estiverem em execução.
Ao selecionar uma linha, é possível ver os detalhes de cada ambiente. Confira este exemplo:
Essa tela mostra detalhes sobre:
Você também pode adicionar métricas personalizadas.
Confira mais informações sobre o monitor de produções:
http://docs.intersystems.com/ens20161/csp/docbook/DocBook.UI.Page.cls?KEY=EMONITOR_production
Com o Enterprise Monitor configurado, você também pode conferir o Enterprise Message Viewer.
Neste exemplo, acesse "Patient Search" (Pesquisa de pacientes) no HSACCESS, faça uma consulta, selecione um paciente e veja as informações mostradas no Clinical Viewer.
Ao acessar o Enterprise Message Viewer, é possível ver todos os sistemas chamados e as informações que foram usadas para realizar essa ação do Clinical Viewer.
Agora há um único lugar para ver como as mensagens estão fluindo em todos os sistemas/namespaces no ambiente do HealthShare.
OBSERVAÇÃO: esse utilitário Enterprise Message Viewer contém somente informações básicas do cabeçalho de mensagens do Ensemble. Ele fornece links para os detalhes específicos da sessão e direciona você aos detalhes e rastreamentos da mensagem do Ensemble.
O Enterprise Monitor e o Enterprise Message Viewer são ferramentas novas no Ensemble que ajudarão os clientes do HealthShare a gerenciar os ambientes e ver fluxos de trabalho no HealthShare.
Enterprise Monitor:
Enterprise Message Viewer:
Olá, esta postagem foi escrita inicialmente para Caché. Em junho de 2023, finalmente a atualizei para IRIS. Se você está revisitando a postagem agora, a única mudança real foi a substituição do Caché pelo IRIS! Também atualizei os links para a documentação do IRIS e corrigi alguns erros de digitação e gramaticais. Aproveite :)
Nesta postagem, mostro estratégias para fazer backup do InterSystems IRIS usando o Backup Externo, incluindo exemplos da integração com soluções baseadas em cópias instantâneas. A maioria das soluções que vejo hoje são implantadas no Linux no VMware. Portanto, grande parte da postagem mostra as formas como as soluções integram a tecnologia de cópia instantânea VMware como exemplos.
O backup online do IRIS está incluído na instalação do IRIS para backup contínuo dos bancos de dados do IRIS. Porém, há soluções de backup mais eficientes que você deve considerar ao ampliar os sistemas. O Backup Externo integrado com tecnologias de cópia instantânea é a solução recomendada para backup de sistemas, incluindo bancos de dados do IRIS.
A documentação online do Backup Externo tem todos os detalhes. Uma consideração importante é:
"Para garantir a integridade cópia instantânea, o IRIS oferece métodos para congelar gravações em bancos de dados enquanto a cópia é criada. Somente as gravações físicas nos arquivos dos bancos de dados são congeladas durante a criação da cópia instantânea, permitindo que os processos do usuário continuem realizando atualizações na memória sem interrupções."
Também é importante observar que parte do processo de cópia em sistemas virtualizados causa uma pequena pausa no backup de uma VM, geralmente chamada de "tempo de stun". Ela costuma durar menos de um segundo, então não é percebida pelos usuários nem afeta a operação do sistema. Porém, em algumas circunstâncias, o stun pode durar mais tempo. Se o stun durar mais que o tempo limite de qualidade de serviço (QoS) para o espelhamento do banco de dados do IRIS, o nó de backup pensará que houve uma falha no primário e fará a tolerância a falhas. Mais adiante nesta postagem, explico como você pode revisar os tempos de stun caso precise alterar o tempo limite de QoS do espelhamento.
Leia também a Guia de Backup e Restauração da documentação online do IRIS para esta postagem.
Se você não tiver mais nada, ela vem incluída na plataforma de dados da InterSystems para backups de tempo de inatividade zero. Lembre-se: o backup online do IRIS só faz backup de arquivos dos bancos de dados do IRIS, capturando todos os blocos nos bancos de dados alocados para dados com a saída gravada em um arquivo sequencial. O Backup Online do IRIS é compatível com backups cumulativos e incrementais.
No contexto do VMware, o Backup Online do IRIS é uma solução de backup a nível de convidado. Como outras soluções de convidado, as operações do Backup Online do IRIS são praticamente as mesmas, quer o aplicativo seja virtualizado ou executado diretamente em um host. O Backup Online do IRIS precisa ser coordenado com um backup do sistema para copiar o arquivo de saída do backup online do IRIS para a mídia de backup e todos os outros sistemas de arquivos usados pelo seu aplicativo. No mínimo, o backup do sistema precisa incluir o diretório de instalação, o diário e os diretórios alternativos do diário, os arquivos do aplicativo e qualquer diretório com os arquivos externos usados pelo aplicativo.
O Backup Online do IRIS deve ser considerado como uma abordagem inicial para sites menores que querem implementar uma solução de baixo custo para fazer backup apenas de bancos de dados do IRIS ou backups ad hoc. Por exemplo, é útil na configuração do espelhamento. No entanto, como os bancos de dados crescem e o IRIS só costuma ser uma parte do cenário de dados do cliente, é uma prática recomendada combinar os Backups Externos com a tecnologia de cópia instantânea e utilitários de terceiros, o que possui vantagens como inclusão do backup de arquivos que não são dos bancos de dados, restaurações mais rápidas, visão de dados de toda a empresa e melhores ferramentas de gestão e catálogo.
Usando o VMware como exemplo, a virtualização no VMware adiciona funcionalidades e opções para proteger VMs inteiras. Depois de virtualizar uma solução, você encapsulará efetivamente seu sistema — incluindo o sistema operacional, o aplicativo e os dados —, tudo dentro de arquivos .vmdk (e alguns outros). Quando necessários, esses arquivos podem ser simples de gerenciar e usados para recuperar um sistema inteiro, o que difere muita da mesma situação em um sistema físico, onde você precisa recuperar e configurar os componentes separadamente – sistema operacional, drivers, aplicativos de terceiros, banco de dados, arquivos de bancos de dados etc.
A vSphere Data Protection (VDP) do VMware e outras soluções de backup de terceiros para o backup da VM, como Veeam ou Commvault, usam a funcionalidade de cópias instantâneas das máquinas virtuais do VMware para criar backups. Segue uma explicação de nível superior das cópias instantâneas do VMware. Veja a documentação do VMware para mais detalhes.
É importante lembrar que as cópias instantâneas são aplicados à VM inteira, e o sistema operacional e qualquer aplicativo ou mecanismo de banco de dados não sabem que a cópia está acontecendo. Além disso, lembre-se:
Sozinhas, as cópias instantâneas da VMware não são backups!
As cópias instantâneas permitem que o software de backup faça backups, mas eles não são backups por si sós.
O VDP e as soluções de backup de terceiros usam o processo de cópia do VMware em conjunto com o aplicativo de backup para gerenciar a criação e, mais importantemente, a exclusão da cópia instantânea. Em um nível superior, o processo e a sequência de eventos para um backup externo usando cópias instantâneas do VMware são os seguintes:
As soluções de backup também usam outros recursos, como Changed Block Tracking (CBT), permitindo backups incrementais ou cumulativos para velocidade e eficiência (especialmente importante para a economia de espaço), e geralmente adicionam outras funções importantes, como deduplicação e compactação de dados, agendamento, montagem de VMs com endereços IP alterados para verificações de integridade etc., restaurações completas no nível da VM e do arquivo e gestão de catálogo.
As cópias instantâneas da VMware que não forem gerenciados adequadamente ou forem deixados em execução por um longo período podem usar armazenamento excessivo (quanto mais dados forem alterados, mais os arquivos delta continuarão a crescer) e deixar as VMs mais lentas.
Considere com cuidado antes de executar uma cópia instantânea manual em uma instância de produção. Por que você está fazendo isso? O que acontecerá se você reverter para quando a cópia instantânea foi criada? O que acontecerá com todas as transações do aplicativo entre a criação e a reversão?
Não tem problema se o seu software de backup criar e excluir uma cópia instantânea. A cópia instantânea deve existir apenas por um breve período. Uma parte fundamental da sua estratégia de backup será escolher um momento de baixo uso do sistema para minimizar qualquer impacto adicional nos usuários e no desempenho.
Antes de obter a cópia instantânea, é preciso colocar o banco de dados no modo desativado. Assim, é realizado o commit de todas as gravações pendentes e o banco de dados fica em um estado consistente. O IRIS oferece métodos e uma API para fazer o commit e congelar (interromper) gravações no banco de dados por um breve período enquanto a cópia instantânea é criada. Assim, somente as gravações físicas nos arquivos do banco de dados são congeladas durante a criação da cópia instantânea, permitindo que os processos do usuário continuem realizando atualizações na memória sem interrupções. Depois que a cópia instantânea é acionada, as gravações no banco de dados são descongeladas e o backup continua copiando os dados para a mídia de backup. O tempo entre o congelamento e o descongelamento deve ser rápido (alguns segundos).
Além de pausar as gravações, o congelamento do IRIS também processa a troca de arquivos de diário e a gravação de um marcador de backup no diário. O arquivo de diário continua a ser gravado normalmente enquanto as gravações no banco de dados físico estão congeladas. Se o sistema falhar enquanto as gravações no banco de dados físico estiverem congeladas, os dados serão recuperados do diário normalmente durante a inicialização.
O diagrama a seguir mostra as etapas de congelamento e descongelamento com cópias instantâneas da VMware para criar um backup com uma imagem de banco de dados consistente.
Observe o breve período entre o congelamento e o descongelamento: apenas o suficiente para criar a cópia instantânea, e não copiar o pai somente leitura para o destino do backup.
O processo de congelar e descongelar o banco de dados é fundamental para garantir a consistência e integridade dos dados. Isso ocorre porque:
Consistência dos dados: o IRIS pode escrever diários ou o WIJ ou fazer gravações aleatórias no banco de dados a qualquer momento. Uma cópia instantânea captura o estado da VM em um momento específico. Se o banco de dados estiver sendo ativamente gravado durante a cópia instantânea, isso poderá causar uma cópia com dados parciais ou inconsistentes. Congelar o banco de dados garante que todas as transações sejam concluídas e nenhuma transação nova seja iniciada durante a cópia, levando a um estado de disco consistente.
Desativação do sistema de arquivos: A tecnologia de cópia instantânea da VMware pode desativar o sistema de arquivos para garantir a consistência dele. No entanto, isso não abrange a consistência no nível do aplicativo ou do banco de dados. O congelamento do banco de dados garante que ele esteja em um estado consistente no nível do aplicativo, complementando o quiesce do VMware.
Redução do tempo de recuperação: a restauração de cópia instantânea obtida sem congelar o banco de dados pode exigir etapas adicionais, como o reparo do banco de dados ou verificações de consistência, o que pode aumentar significativamente o tempo de recuperação. O congelamento e descongelamento garantem que o banco de dados possa ser usado imediatamente após a restauração, diminuindo o tempo de inatividade.
O vSphere permite que um script seja chamado automaticamente em ambos os lados da criação da cópia instantânea. É quando são chamados o congelamento e descongelamento do IRIS. Observação: para essa funcionalidade funcionar corretamente, o host ESXi solicita que o sistema operacional convidado desative os discos pelas Ferramentas do VMware.
As ferramentas do VMware precisam ser instaladas no sistema operacional convidado.
Os scripts precisam obedecer regras rígidas de nome e localização. As permissões de arquivo também precisam ser definidas. Para o VMware no Linux, os nomes dos scripts são:
# /usr/sbin/pre-freeze-script
# /usr/sbin/post-thaw-script
Confira abaixo exemplos de scripts de congelamento e descongelamento que nossa equipe usa com o backup do Veeam para instâncias internas de laboratório de testes, mas eles também devem funcionar com outras soluções. Esses exemplos foram testados e usados no vSphere 6 e Red Hat 7.
Embora esses scripts possam ser usados como exemplos e ilustrem o método, você precisa validá-los para seus ambientes!
#!/bin/sh
#
# Script called by VMWare immediately prior to snapshot for backup.
# Tested on Red Hat 7.2
#
LOGDIR=/var/log
SNAPLOG=$LOGDIR/snapshot.log
echo >> $SNAPLOG
echo "`date`: Pre freeze script started" >> $SNAPLOG
exit_code=0
# Only for running instances
for INST in `iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}'`; do
echo "`date`: Attempting to freeze $INST" >> $SNAPLOG
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
# Freeze
irissession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,1800)" >> $SNAPLOG $
status=$?
case $status in
5) echo "`date`: $INST IS FROZEN" >> $SNAPLOG
;;
3) echo "`date`: $INST FREEZE FAILED" >> $SNAPLOG
logger -p user.err "freeze of $INST failed"
exit_code=1
;;
*) echo "`date`: ERROR: Unknown status code: $status" >> $SNAPLOG
logger -p user.err "ERROR when freezing $INST"
exit_code=1
;;
esac
echo "`date`: Completed freeze of $INST" >> $SNAPLOG
done
echo "`date`: Pre freeze script finished" >> $SNAPLOG
exit $exit_code
#!/bin/sh
#
# Script called by VMWare immediately after backup snapshot has been created
# Tested on Red Hat 7.2
#
LOGDIR=/var/log
SNAPLOG=$LOGDIR/snapshot.log
echo >> $SNAPLOG
echo "`date`: Post thaw script started" >> $SNAPLOG
exit_code=0
if [ -d "$LOGDIR" ]; then
# Only for running instances
for INST in `iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}'`; do
echo "`date`: Attempting to thaw $INST" >> $SNAPLOG
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
# Thaw
irissession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")" >> $SNAPLOG 2>&1
status=$?
case $status in
5) echo "`date`: $INST IS THAWED" >> $SNAPLOG
irissession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")" >> $SNAPLOG$
;;
3) echo "`date`: $INST THAW FAILED" >> $SNAPLOG
logger -p user.err "thaw of $INST failed"
exit_code=1
;;
*) echo "`date`: ERROR: Unknown status code: $status" >> $SNAPLOG
logger -p user.err "ERROR when thawing $INST"
exit_code=1
;;
esac
echo "`date`: Completed thaw of $INST" >> $SNAPLOG
done
fi
echo "`date`: Post thaw script finished" >> $SNAPLOG
exit $exit_code
# sudo chown root.root /usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script
# sudo chmod 0700 /usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script
Para testar se os scripts estão funcionando corretamente, você pode executar uma cópia instantânea manualmente em uma VM e verificar a saída do script. A captura de tela a seguir mostra a caixa de diálogo "Take VM Snapshot" (Tirar a cópia instantânea da VM) e as opções.
Desmarque- "Snapshot the virtual machine's memory" (Tirar a cópia instantânea da memória da máquina virtual).
Selecione - a caixa de seleção "Quiesce guest file system (Needs VMware Tools installed)", ou "Colocar o sistema de arquivos convidado em modo quiesced (as ferramentas do VMware precisam estar instaladas)", para pausar os processos em execução no sistema operacional convidado, deixando o conteúdo do sistema de arquivos em um estado consistente conhecido ao tirar a cópia instantânea.
Importante! Depois do teste, lembre-se de excluir a cópia instantânea!!!!
Se a sinalização quiesce for verdadeira e a máquina virtual estiver ligada ao tirar a cópia instantânea, as ferramentas do VMware serão usadas para o quiesce do sistema de arquivos na máquina virtual. O quiesce do sistema de arquivos é o processo de colocar os dados no disco em um estado adequado para backups. Esse processo pode incluir operações como a limpeza de buffers sujos no cache da memória do sistema operacional para o disco.
A saída a seguir mostra o conteúdo do arquivo de log $SNAPSHOT definido nos scripts de congelamento/descongelamento acima após executar um backup que inclui uma cópia instantânea como parte da sua operação.
Wed Jan 4 16:30:35 EST 2017: Pre freeze script started
Wed Jan 4 16:30:35 EST 2017: Attempting to freeze H20152
Wed Jan 4 16:30:36 EST 2017: H20152 IS FROZEN
Wed Jan 4 16:30:36 EST 2017: Completed freeze of H20152
Wed Jan 4 16:30:36 EST 2017: Pre freeze script finished
Wed Jan 4 16:30:41 EST 2017: Post thaw script started
Wed Jan 4 16:30:41 EST 2017: Attempting to thaw H20152
Wed Jan 4 16:30:42 EST 2017: H20152 IS THAWED
Wed Jan 4 16:30:42 EST 2017: Completed thaw of H20152
Wed Jan 4 16:30:42 EST 2017: Post thaw script finished
Esse exemplo mostra os 6 segundos decorridos entre o congelamento e o descongelamento (16:30:36-16:30:42). As operações dos usuários NÃO são interrompidas durante esse período. Você precisará coletar métricas dos seus próprios sistemas, mas, para um pouco de contexto, esse exemplo é de um sistema que está executando um benchmark de aplicativo em uma VM sem gargalos de IO e com uma média de mais de 2 milhões de glorefs/s, 170.000 de gloupds/s, 1.100 gravações físicas/s e 3.000 gravações por ciclo de daemon de gravação.
Lembre-se de que a memória não faz parte da cópia instantânea, portanto, ao reiniciar, a VM será reinicializada e recuperada. Os arquivos de banco de dados serão consistentes. Você não quer "retomar" um backup, e sim quer os arquivos em um momento conhecido. Então, você pode fazer o roll forward dos diários e quaisquer outras etapas de recuperação necessárias para o aplicativo e a consistência transacional assim que os arquivos forem recuperados.
Para proteção de dados adicional, a troca do diário pode ser feita por si só, e os diários podem ser armazenados em backup ou replicados em outro local, por exemplo, a cada hora.
Confira abaixo a saída de $LOGFILE nos scripts de congelamento/descongelamento acima, mostrando os detalhes do diário para a cópia instantânea.
01/04/2017 16:30:35: Backup.General.ExternalFreeze: Suspending system
Journal file switched to:
/trak/jnl/jrnpri/h20152/H20152_20170104.011
01/04/2017 16:30:35: Backup.General.ExternalFreeze: Start a journal restore for this backup with journal file: /trak/jnl/jrnpri/h20152/H20152_20170104.011
Journal marker set at
offset 197192 of /trak/jnl/jrnpri/h20152/H20152_20170104.011
01/04/2017 16:30:36: Backup.General.ExternalFreeze: System suspended
01/04/2017 16:30:41: Backup.General.ExternalThaw: Resuming system
01/04/2017 16:30:42: Backup.General.ExternalThaw: System resumed
No ponto de criação de uma cópia instantânea da VM e após a conclusão do backup e o commit do snapshot, a VM precisa ser congelada por um breve período. Esse pequeno congelamento costuma ser chamado de "stun" da VM. Veja uma ótima postagem de blog sobre os tempos de stun aqui. Resumo os detalhes abaixo e os contextualizo para as considerações do banco de dados do IRIS.
Da postagem sobre os tempos de stun: "Para criar uma cópia instantânea da VM, é feito o 'stun' da VM para (i) serializar o estado do dispositivo no disco e (ii) encerrar o disco que está em execução e criar um ponto da cópia instantânea… Durante a consolidação, é feito o 'stun' da VM para encerrar os discos e colocá-los em um estado apropriado para a consolidação."
O tempo de stun é normalmente algumas centenas de milésimos. No entanto, se houver uma atividade muito alta de gravação em disco durante a fase de commit, o tempo de stun poderá ser de vários segundos.
Se a VM estiver participando do Espelhamento do Banco de Dados do IRIS como um membro Primário ou de Backup, e o tempo de stun for maior que o tempo limite de Qualidade de Serviço (QoS) do espelho, o espelho relatará a falha da VM Primária e assumirá o controle.
Atualização de março de 2018: Meu colega, Peter Greskoff, indicou que um membro espelho de backup poderia iniciar a tolerância a falhas na metade do tempo limite de QoS durante um stun da VM ou quando um membro espelho primário estiver indisponível.
Para conferir uma descrição detalhada das considerações de QoS e cenários de tolerância a falhas, consulte esta ótima postagem: Guia do Tempo Limite de Qualidade de Serviço para Espelhamento. Resumindo a questão dos tempos de stun da VM e QoS:
Se o espelho de backup não receber nenhuma mensagem do espelho primário dentro da metade do tempo limite de QoS, ele enviará uma mensagem para garantir que o primário ainda está ativo. Em seguida, o backup aguardará uma resposta da máquina primária pela outra metade do tempo de QoS. Se não houver resposta do primário, presume-se que ele está inativo, e o backup assumirá o controle.
Em um sistema ocupado, os diários são enviados continuamente do espelho primário para o espelho de backup, e o backup não precisa verificar se o primário ainda está ativo. No entanto, durante um período tranquilo — quando é mais provável que os backups ocorram —, se o aplicativo estiver ocioso, pode não haver mensagens entre o espelho primário e o de backup por mais da metade do tempo de QoS.
Confira abaixo o exemplo de Peter. Pense neste intervalo para um sistema ocioso com um tempo limite de QoS de 8 segundos e um tempo de stun da VM de 7 segundos:
Leia também a seção Pitfalls and Concerns when Configuring your Quality of Service Timeout (Armadilhas e Preocupações ao Configurar o Tempo Limite de Qualidade de Serviço) na postagem do link acima para entender o equilíbrio de ter a QoS somente pelo tempo necessário. Ter a QoS por muito tempo, especialmente por mais de 30 segundos, também pode causar problemas.
Final da atualização de março de 2018:
Para obter mais informações sobre a QoS do Espelhamento, consulte também a documentação.
As estratégias para reduzir ao mínimo o tempo de stun incluem executar backups quando houver pouca atividade no banco de dados e configurar bem o armazenamento.
Como observado acima, ao criar uma cópia instantânea, há várias opções que você pode especificar. Uma delas é incluir o estado da memória na cópia - Lembre-se, o estado da memória NÃO é necessário para backups de bancos de dados do IRIS. Se estiver configurada a sinalização da memória, um dump do estado interno da máquina virtual será incluído na cópia. A criação de cópias instantâneas da memória demora muito mais. As cópias da memória são usados para reverter o estado de uma máquina virtual em execução para como estava quando a cópia foi obtida. Isso NÃO é necessário para o backup de arquivos de um banco de dados.
Ao tirar uma cópia instantânea da memória, será realizado o stun de todo o estado da máquina virtual. O tempo de stun varia.
Como observado anteriormente, para backups, a sinalização do quiesce precisa ser definida como verdadeira para cópias manuais ou pelo software de backup para garantir um backup consistente e utilizável.
A partir do ESXi 5.0, os tempos de stun das cópias são registrados no arquivo de log de cada máquina virtual (vmware.log) com mensagens semelhantes a:
2017-01-04T22:15:58.846Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 38123 us
Os tempos de stun estão em microssegundos. Então, no exemplo acima, 38123 us é 38123/1.000.000 segundos ou 0,038 segundos.
Para garantir que os tempos de stun estão dentro dos limites aceitáveis ou para solucionar problemas se você suspeitar que eles estão longos e causando problemas, baixe e revise os arquivos vmware.log da pasta da VM em que tem interesse. Depois de baixar, você pode extrair e ordenar o log usando os comandos Linux de exemplo abaixo.
Há várias formas de baixar os logs de suporte, incluindo criando um pacote de suporte do VMware através do console de gerenciamento do vSphere ou da linha de comando do host ESXi. Consulte a documentação do VMware para ver todos os detalhes, mas abaixo está um método simples para criar e reunir um pacote de suporte bem menor que inclui o arquivo vmware.log para você revisar os tempos de stun.
Você precisará do nome longo do diretório onde os arquivos da VM estão localizados. Faça login no host ESXi onde a VM do banco de dados está em execução usando ssh e use o comando: vim-cmd vmsvc/getallvms para listar os arquivos vmx e os nomes longos exclusivos associados a eles.
Por exemplo, o nome longo da VM do banco de dados de exemplo usada nesta postagem fica assim:
26 vsan-tc2016-db1 [vsanDatastore] e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0/vsan-tc2016-db1.vmx rhel7_64Guest vmx-11
Em seguida, execute o comando para reunir e empacotar apenas os arquivos de log:vm-support -a VirtualMachines:logs.
O comando dará a localização do pacote de suporte, por exemplo:
To see the files collected, check '/vmfs/volumes/datastore1 (3)/esx-esxvsan4.iscinternal.com-2016-12-30--07.19-9235879.tgz'.
Agora você pode usar o sftp para transferir o arquivo para fora do host para processamento e análise adicional.
Nesse exemplo, após descompactar o pacote de suporte, acesse o caminho correspondente ao nome longo da VM do banco de dados. Por exemplo, nesse caso:
<bundle name>/vmfs/volumes/<host long name>/e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0.
Você verá vários arquivos de log numerados. O arquivo de log mais recente não tem número, ou seja, vmware.log. O log pode ter só algumas centenas de KB, mas há muitas informações. Porém, queremos os tempos de stun/unstun, que são fáceis de encontrar com grep. Por exemplo:
$ grep Unstun vmware.log
2017-01-04T21:30:19.662Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 1091706 us
---
2017-01-04T22:15:58.846Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 38123 us
2017-01-04T22:15:59.573Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 298346 us
2017-01-04T22:16:03.672Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 301099 us
2017-01-04T22:16:06.471Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 341616 us
2017-01-04T22:16:24.813Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 264392 us
2017-01-04T22:16:30.921Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 221633 us
Podemos ver dois grupos de tempos de stun no exemplo, um desde a criação da cópia instantânea e outro definido 45 minutos depois para cada disco quando a cópia foi excluído/consolidado (por exemplo, depois que o software de backup fez a cópia do arquivo vmx somente leitura). O exemplo acima mostra que a maioria dos tempos de stun é menor do que um segundo, mesmo que o tempo de stun inicial seja um pouco mais de um segundo.
Tempos de stun curtos não são perceptíveis para o usuário final. No entanto, os processos do sistema, como o Espelhamento do Banco de Dados do IRIS, verificam continuamente se uma instância está "ativa". Se o tempo de stun exceder o tempo limite de QoS do espelhamento, o nó poderá ser considerado fora de contato e "morto", e a tolerância a falhas será acionada.
Dica: para revisar todos os logs ou solucionar problemas, um comando útil é fazer o grep de todos os arquivos vmware*.log e procurar qualquer discrepância ou instância em que o tempo de stun chega próximo ao tempo limite de QoS. O seguinte comando canaliza a saída para awk para formatação:
grep Unstun vmware* | awk '{ printf ("%'"'"'d", $8)} {print " ---" $0}' | sort -nr
Monitore seu sistema regularmente durante as operações normais para entender os tempos de stun e como eles podem afetar o tempo limite de QoS para HA, como o espelhamento. Como observado, as estratégias para reduzir ao mínimo o tempo de stun/unstun incluem executar backups quando houver pouca atividade no banco de dados e no armazenamento e configurar bem o armazenamento. Para monitoramento constante, os logs podem ser processados usando o VMware Log Insight ou outras ferramentas.
Em postagens futuras, revisitarei as operações de backup e restauração para as Plataformas de Dados da InterSystems. Por enquanto, caso você tenha algum comentário ou sugestão com base nos fluxos de trabalho dos seus sistemas, compartilhe nas seções de comentários abaixo.
No Linux, siga as etapas a seguir para excluir uma instância do InterSystems IRIS (doravante denominada IRIS).
(1) Pare a instância IRIS que você deseja desinstalar usando iris stop
# iris stop <instance name>(2) Exclua as informações da instância usando o seguinte comando
# iris delete <instance name>(3) Exclua o diretório de instalação do IRIS usando o comando rm -r
# rm -r <install directory>Além do diretório de instalação, o IRIS também usa (a) e (b) abaixo.
O diário (Journal) é um recurso essencial do IRIS e uma parte do que torna o IRIS um banco de dados confiável. Embora o diário seja fundamental para o IRIS, há nuances, então escrevi este artigo para resumir (mais brevemente do que nossa documentação com todos os detalhes) o que você precisa saber. Percebo a ironia de dizer que uma leitura de 27 minutos é breve.
Toda modificação em um banco de dados que tenha diário (sets e kills) é registrada com o carimbo de data/hora em um arquivo de diário. Isso é feito em paralelo com as gravações nos bancos de dados e no diário de imagem de gravação (WIJ) para a redundância. O IRIS usa os diários para reproduzir as mudanças no banco de dados em um cenário de recuperação, reverter transações e sincronizar bancos de dados para espelhamento.
Este artigo foca no que depende do diário e nos utilitários usados para gerenciar o diário. Também vamos mostrar uma breve visão geral das operações do IRIS relacionadas para explicar por que o diário é tão importante. Fique à vontade para entrar em contato com o WRC caso precise de suporte crítico com um problema no diário, mas conhecer os fundamentos pode ajudar você a configurar o diário corretamente e responder a cenários específicos da maneira apropriada.
Antes de começar, nossa documentação sobre o diário é robusta e pode ser encontrada abaixo. Às vezes, vou mencionar tabelas da documentação, em vez de reproduzi-las inline. Também vou adicionar um link para nossas melhores práticas de diário. - Recomendo muito a leitura desse documento.
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCDI_journal
A documentação mais recente (vinculada) no momento da escrita deste artigo é para o IRIS 2023.3 (CD), e a instância a que me referi está executando o IRIS 2023.1.2 (EM).
O portal de gerenciamento de sistemas é o local mais fácil para fazer alterações no diário (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário), mas há rotinas fora dele que também podem ser usadas para isso. Elas estão localizadas principalmente no namespace %SYS, e a maioria delas é indexada pela rotina ^JOURNAL, que chama os outros utilitários.
Observação: o portal de gerenciamento de sistemas será chamado de SMP para abreviar
O diário pode ser ativado principalmente no nível do sistema e no nível do banco de dados. Por padrão, o diário está sempre ativado em todo o sistema. Há pouquíssimas situações em que você deve desabilitar isso, portanto não há opção no SMP. Você precisará usar a rotina ^JRNSTOP. A interrupção do diário para o sistema dura até a reinicialização do IRIS, quando o diário é retomado automaticamente. Um erro também pode desativar o diário em todo o sistema, por exemplo, ficar sem espaço em disco no diário. Caso isso aconteça, você verá uma mensagem de messages.log avisando que o diário foi desativado. Você precisará usar a rotina ^JRNSTART para retomar o diário.
Para revisar o diário no nível do banco de dados, você pode acessar o SMP (Administração do Sistema > Configuração > Configuração do Sistema > Banco de Dados Local). O padrão é que os bancos de dados tenham diário.
Por padrão, os nomes dos arquivos do diário têm o formato aaaammdd.nnn e são armazenados em <install_dir>/mgr/journal/. Se o diário for compactado, o nome do arquivo terá o sufixo "z". O arquivo journal.log que registra o nome de cada arquivo do diário está em /mgr/. O log do diário limpará as entradas sequencialmente com base em se o próprio arquivo do diário foi limpo e se a entrada tem 30 dias ou mais. O journal.log é referenciado pelo IRIS para trocar e limpar diários, além de poder ser usado para ajudar a reproduzir diários. Ele nunca deve ser modificado manualmente.
Você pode ajustar algumas configurações do diário usando o SMP (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário) ou a rotina ^JRNOPTS, que é a opção 7 de ^JOURNAL. A maioria dessas configurações é armazenada no arquivo de parâmetros iris.cpf nas seções [config] e [journal]. Quase todas elas podem ser alteradas sem reiniciar o IRIS, mas podem incorrer em uma troca de arquivo de diário.
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=RCPF_config
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=RACS_journal
As seguintes configurações estão tanto no SMP quanto na ^JRNOPTS.
O SMP contém outras configurações que não estão em ^JRNOPTS, incluindo "Congelar em caso de erro" - entender essa configuração é importante o suficiente para eu discutir suas implicações na seção a seguir. Resumindo, nossa recomendação é ativar essa configuração.
Há outras configurações disponíveis na página "Configurações do Diário" que são menos usadas, como "Sessão da Web do Diário", "Diretório do Diário de Imagem de Gravação" e "Tamanho alvo para o wij". Informações sobre essas configurações estão disponíveis na documentação do CPF. Não vou abordá-las porque são situacionais.
Há também configurações avançadas de diário disponíveis em outros locais do SMP.
Observação: a partir de 2023.3, um novo recurso de arquivamento de diário foi lançado para que os diários compactados possam ser movidos para um drive separado.
Em Administração do Sistema > Configuração > Configurações Adicionais > Memória Avançada, você pode modificar os buffers do diário (jrnbufs), que têm, por padrão, 64 MB, mas podem variar de 8 ou 16 MB a 1.024 MB, dependendo se a sua instalação for de 8 bits ou Unicode. Essa configuração controla o tradeoff entre desempenho e confiabilidade (os dados do diário armazenados na memória/buffers são mais rápidos, mas temporários em caso de falha).
Em Administração do Sistema > Configuração > Configurações Adicionais > Compatibilidade, temos a configuração "SynchCommit", que determina quando um comando TCOMMIT solicitará que os dados estejam no disco. True faz com que TCOMMIT espere a gravação do diário, mas o padrão false permite que TCOMMIT retorne antes da gravação. Isso está relacionado às transações, que são abordadas algumas seções abaixo.
A configuração "Freeze on error", ou "Congelar em caso de erro", (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário) determina como o IRIS responderá aos erros de I/O do diário. O tradeoff que você precisa considerar é a disponibilidade em relação à integridade dos dados e das transações.
Essa configuração está desativada por padrão. Caso ocorra um erro no diário, você pode esperar o seguinte comportamento. O daemon do diário tentará novamente a cada 1s (padrão) até passar 150s (padrão) ou a instância ficar sem memória (buffers globais) para as atualizações do diário. Nesse momento, o diário será desativado em todo o sistema, impedindo que os dados após esse ponto sejam recuperáveis em um cenário de desastre. Outras preocupações com o diário desativado são que a reversão da transação falhará, o espelhamento falhará e o bloqueio do ECP/recuperação da transação será comprometido. Quando o diário for desativado devido a um erro, uma mensagem será registrada em messages.log informando que você precisará reativar manualmente o diário usando ^JRNSTART. Além disso, recomendamos que, em caso de execução com o diário desativado, você resolva o problema, troque o arquivo do diário e faça backup dos bancos de dados.
Em geral, recomendamos ativar "Congelar em caso de erro", ou seja, se ocorrer um erro com o diário, o IRIS congelará para que você resolva o problema. Todas as atualizações de globais do diário serão interrompidas, e as atualizações de globais serão congeladas quando o daemon do diário ficar inativo por 30s. O daemon do diário continuará tentando e descongelará quando tiver sucesso. Isso provavelmente travará o IRIS até que o problema do diário seja resolvido. Você verá mensagens de gravidade 3 em messages.log avisando você ao tentar novamente a I/O com falha.
Para explicar melhor o comportamento em relação à reversão da transação, com "Congelar em caso de erro" desativado, um TROLLBACK com falha encerrará a transação e liberará os bloqueios. Com a configuração ativada, o processo de abertura da transação será interrompido e CLNDMN tentará repetidamente reverter a transação. Os bloqueios serão mantidos durante essa operação. Se CLNDMN estiver tentando reverter uma transação para um trabalho inativo (como mostrado em messages.log), você poderá usar Manage^CLNDMN para encerrar manualmente a transação. As considerações aqui são semelhantes às discutidas acima: disponibilidade x integridade.
Observação: isso só se aplica à reversão local (não ECP).
O diário é fundamental para a recuperação de desastres. Ao gravar em um banco de dados do IRIS, o IRIS grava essas mudanças duas vezes antes de tocar no banco de dados em si. Todos os sets e kills são registrados no diário, que é gravado pelo menos a cada 2 segundos (há alguns outros gatilhos que vou omitir para simplificar). As alterações também são gravadas no diário de imagem de gravação (WIJ), que armazena as modificações do banco de dados por até 80s antes de serem gravadas no banco de dados em uma passagem. A combinação de diários e do WIJ garante que, em caso de falha, seja possível verificar novamente o que gravamos nos diários, no WIJ e no banco de dados.
Essa é uma breve explicação. Para saber mais, nosso "Guia de integridade dos dados" é um excelente recurso.
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCDI
Quando o IRIS é inicializado após uma interrupção anormal, ele determinará se precisa reaplicar o WIJ ou não e reproduzirá diários (como os diários são gravados com mais frequência, eles podem estar mais atualizados). Se você restaurar um backup, os diários podem/devem ser aplicados em seguida para reproduzir a sequência de sets e kills e atualizar o banco de dados. Sem o diário, você só poderá restaurar até o ponto do backup, quando ele tiver sido feito.
Os diários também facilitam as transações. Resumindo, as transações são usadas para garantir que uma sequência de alterações no banco de dados possam ser tratadas como uma única operação. Você provavelmente já ouviu falar do exemplo do caixa eletrônico: você não quer sacar dinheiro de uma conta, mas fazer com que não alcance seu destino. Ao colocar uma sequência de sets e kills entre os comandos "TSTART" e "TCOMMIT", com o bloqueio adequado para lidar com vários processos, você pode ter certeza de que, se uma das mudanças for gravada no disco, todas as alterações terão persistido. Se um erro ou outro evento impedir que o processo alcance o TCOMMIT, nenhuma das mudanças na transação será feita. Se você iniciar uma transação, mas não conseguir fazer o commit devido a um erro ou outro evento, o IRIS pode consultar o diário para desfazer todas as mudanças no banco de dados, voltando ao TSTART. Pela natureza das transações, mesmo se um banco de dados não tiver um diário, uma transação ainda será registrada em um diário. Esteja ciente de que isso se aplica somente a reversões de tempo de execução e, para uma inicialização de recuperação, não ocorrerá a reversão.
Uma explicação mais detalhada sobre as transações está disponível em nossa documentação "Processamento das transações":
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCOS_tp
O espelhamento é a solução de alta disponibilidade / recuperação de desastres / réplica de dados da InterSystems. No espelhamento, uma instância do IRIS envia seus diários a uma ou mais instâncias do IRIS, que executam em sequência os mesmos sets e kills (esse processo se chama "dejournaling") para manter os bancos de dados sincronizados. Isso permite a réplica de dados lógica em nós. Você nunca pode desativar o diário em um banco de dados espelhado por esse motivo.
Depois de se tornar um membro espelho primário, os arquivos de diário criados terão "MIRROR" no nome e o log do diário será registrado em um mirrorjrn-mirror_name.log, bem como no journal.log regular. Os outros membros espelho armazenarão os diários espelho junto com seus próprios diários e manterão uma cópia do log do diário espelho; mirrorjrn-mirror_name.log é criado em install-dir/mgr/.
Há outras ressalvas para o diário e o espelhamento que tentarei mencionar quando relevante. Nossa documentação sobre o espelhamento está aqui:
https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GHA_mirror
Esta seção provavelmente só é interessante para você se estiver usando o espelhamento. Ela discutirá como a localização dos arquivos de diário, o critério de limpeza e a configuração "Congelar em caso de erro" são afetados pelo espelhamento.
O critério de limpeza padrão para os arquivos de diário são um determinado número de dias ou backups. No entanto, se pelo menos um desses gatilhos for atendido, os arquivos do diário espelho podem ser preservados se forem necessários para a sincronização. Por exemplo, se um diário for necessário para concluir uma transação em qualquer membro espelho, ele não será removido.
Um membro de tolerância a falhas primário só limpará um arquivo de diário depois que o critério de limpeza for atingido e o arquivo tiver sido recebido por todos os membros espelho assíncronos e de backup. Isso é aplicável a menos que um assíncrono tenha sido desconectado há >14 dias.
Um membro de tolerância a falhas de backup ou assíncrono de recuperação de desastres limpará um diário após o arquivo passar por dejournaling, o critério de limpeza local for atendido e o diário for recebido por todos os assíncronos. É aplicável a mesma exceção de 14 dias conforme acima.
Em um assíncrono de relatório, os diários espelho são removidos imediatamente após o dejournaling por padrão. Isso pode ser modificado nas configurações do membro espelho (no CPF: AsyncUseSystemPurgeInterval).
O tempo limite de 14 dias pode ser modificado usando o método SYS.Mirror.JrnPurgeDefaultWait, documentado aqui:
A configuração de diário "Congelar em caso de erro" é ativada automaticamente para um membro espelho primário, já que não consegue continuar operando como um membro espelho sem o diário. Se o congelamento continuar por muito tempo, o membro de tolerância a falhas de backup deve detectar a inatividade e assumir como primário.
Agora temos uma ideia do motivo pelo qual o diário é usado e geralmente deve estar ativado. Mas há algumas situações em que você deve evitar o diário? Para isso, indico essa breve série de artigos escritos por Tani Frankel para Caché, mas aplicável ao IRIS, que aborda os seguintes tópicos:
https://community.intersystems.com/post/what-causing-journals-grow-rapidly
https://community.intersystems.com/post/my-growing-journals-how-do-i-minimize
Neste capítulo, vou abordar algumas operações de diário comuns que você pode precisar realizar. Uma lista mais completa de utilitários de diário poderá ser vista no terceiro capítulo, "Utilitários de diário".
Não é possível inicializar e interromper diários no nível da instância pelo portal de gerenciamento de sistemas. Você só pode fazer essa alteração através de ^JOURNAL ou usando ^JRNSTART e ^JRNSTOP.
As principais páginas de Diário no portal de gerenciamento estão localizadas em Operação de Sistema > Diários.
Para trocar os diretórios de diário, há um botão "Switch Directory" (Trocar diretório) na página de Diários no SMP, além do SWDIR^JOURNAL, que é a opção 13 em ^JOURNAL. Se você não tiver outro diretório definido, essa opção não estará disponível.
Para trocar para um novo arquivo de diário, você pode usar o botão "Switch Journal" (Trocar diário) na página de Diários no SMP ou utilizar o ^JRNSWTCH, que é a opção 3 em ^JOURNAL. Os arquivos de diário mudarão automaticamente após um backup bem-sucedido, se um arquivo de diário ficar cheio, se o diretório ficar indisponível e ao mudar as configurações do diário.
Se você quiser revisar o conteúdo de um arquivo de diário, poderá fazer isso no portal de gerenciamento de sistemas (Operação de Sistema > Diários) ou usando ^JRNDUMP. SELECT^JRNDUMP permitirá que você despeje registros de diário específicos em um arquivo, filtrando por uma variedade de critérios.
Observação: se você precisar conferir um arquivo de diário arbitrário, pode mudar o URL dessa página do SMP para que aponte para outro arquivo. Isso presume que o IRIS tenha permissões para acessar esse arquivo.
Para obter uma visão geral do conteúdo de um diário, você deve criar o perfil do diário usando a opção "Perfil" na página de Diários do SMP. Isso dará a você uma ideia dos globais que estão sendo alterados - a frequência e em quais bancos de dados. Você também pode ver um resumo dos metadados do arquivo de diário usando a opção "Resumo" na página de Diários. Isso contém informações como os bancos de dados envolvidos, se eles são criptografados e quando o arquivo de diário foi criado. A página de Diários também oferece a possibilidade de realizar uma verificação de integridade em um arquivo de diário.
Se você precisar limpar manualmente seus diários, por exemplo, se alguma atividade incomum de banco de dados causar registros excessivos no diário, é possível fazer isso usando PURGE^JOURNAL, a 6ª opção de ^JOURNAL. Assim, você pode fazer a limpeza com base no seu critério padrão ou remover todos os diários desnecessários para a transação ou recuperação da falha. A tarefa "Limpar Diário" padrão (Operação de Sistema > Gerenciador de Tarefas > Programação de Tarefas) é executada às 00:30, logo após a tarefa padrão "Trocar Diário" às 00:00. Se uma limpeza falhar, por exemplo, o arquivo de diário for necessário para uma transação ou espelhamento, você pode esperar uma mensagem de messages.log informando sobre isso. Você não deve tentar excluir arquivos de diário no nível do SO, já que isso pode causar o desalinhamento do sistema de arquivos com o journal.log e a quebra de operações de diário padrão.
Por fim, você pode se deparar com uma situação em que seja necessário executar uma restauração manual do diário. Os mecanismos exatos são mais discutidos na seção ^JRNRESTO, mas os conceitos básicos são os seguintes. ^JRNRESTO é a opção 4 de ^JOURNAL, e você deve garantir que os usuários não estejam no sistema, que o diário seja interrompido e que você tenha restaurado seu backup. Em seguida, pode executar o ^JRNRESTO e reiniciar o diário. Essa operação não está disponível no portal de gerenciamento de sistemas, porque só é usada em circunstâncias de força maior.
Para uso mais avançado, como determinadas soluções de problemas ou necessidades programáticas, o global ^%SYS("JOURNAL") contém informações detalhadas sobre o diário. O %SYS.Journal.System contém consultas e métodos do diário, conforme documentado aqui:
Nas duas seções anteriores, mencionei os utilitários do diário. Vários deles são agregados no ^JOURNAL, uma rotina disponível no namespace %SYS. Essa seção será mais detalhada do que as seções anteriores e darei exemplos específicos de caminhos de prompts. Você pode achar isso mais útil como uma referência do que um artigo para leitura.
A interface oferecerá essas opções:
1) Iniciar o diário (^JRNSTART)
2) Parar o diário (^JRNSTOP)
3) Trocar o arquivo do diário (^JRNSWTCH)
4) Restaurar os globais do diário (^JRNRESTO)
5) Exibir o arquivo do diário (^JRNDUMP)
6) Limpar os arquivos do diário (PURGE^JOURNAL)
7) Editar as propriedades do diário (^JRNOPTS)
8) Ativar ou desativar a criptografia do diário (ENCRYPT^JOURNAL())
9) Mostrar o status do diário (Status^JOURNAL)
10) -não disponível-
11) -não disponível-
12) Atualizar diário com os bancos de dados espelhados (MirrorCatchup^JRNRESTO)
13) Trocar diário para o diretório secundário (SWDIR^JOURNAL)
Vou descrever essas opções na ordem da quantidade de detalhes que fornecerei, da mais simples para a mais complexa. Observe que algumas opções (como 10 e 11 acima) podem aparecer como "-não disponível-" dependendo da sua configuração. Vou indicar isso.
Opções 1 "Iniciar diário (^JRNSTART)", 2 " Parar diário (^JRNSTOP)", 3 " Trocar arquivo do diário (^JRNSWTCH)" e 13 "Trocar diário para o diretório secundário (SWDIR^JOURNAL)" são simples, já que realizam uma única operação. A opção 13 ficará indisponível se a instância não tiver um diretório de diário alternativo configurado.
A opção 12 "Atualizar diário com os bancos de dados espelhados (MirrorCatchup^JRNRESTO)" também é uma operação básica para uma instância espelhada e iniciará uma atualização de espelho. O diário não precisa estar ativado nesse momento, mas precisa ter sido iniciado pelo menos uma vez desde a inicialização do IRIS para ter o diretório do diário atual na memória
A opção 7 "Editar propriedades do diário (^JRNOPTS)" permite que você modifique 5 configurações de diário básicas. Você pode mudar os diretórios do diário, o limite de tamanho do arquivo do diário, o prefixo do arquivo do diário e seu critério de limpeza.
A opção 10 oferece a "Restauração de cluster de diário (CLUMENU^JRNRESTO)". As considerações de cluster ECP estão além do que abordarei neste artigo, mas você pode encontrar informações sobre essa opção aqui na documentação do Caché:
A opção 8 é "Ativar ou desativar a criptografia do diário (ENCRYPT^JOURNAL())", e uma descrição profunda será omitida. Destaco que essa configuração se aplica a arquivos de diário futuros. Para configurar os arquivos de diário criptografados, veja esta documentação:
A opção 6 "Limpar arquivos de diário (PURGE^JOURNAL)" permite que você limpe com duas opções diferentes: com base no critério configurado (dias e backups bem-sucedidos) ou qualquer diário que não seja necessário para a reversão da transação ou recuperação de falhas. Ela relatará quais arquivos de diário foram removidos.
A opção 9 "Mostrar o status do diário (Status^JOURNAL)" oferece algumas metainformações sobre o diário. Ela dirá o status atual do diário, incluindo:
As opções 11, "Gerenciar reversão de transação pendente ou em andamento (Manage^JRNROLL)", 5 "Exibir o arquivo do diário (^JRNDUMP)" e 4 "Restaurar os globais do diário (^JRNRESTO)" são tão envolvidas que eu as separei em seus próprios cabeçalhos.
Em geral, a reversão da transação deve ser rápida, já que as transações só podem ser abertas por breves períodos, mas, se uma transação for deixada aberta por tempo prolongado, a instância pode precisar verificar um número significativo de arquivos de diário antes da inicialização normal do sistema. Verificamos as transações abertas na inicialização da instância e ao se tornar um membro espelho primário.
Se o tempo de atividade do sistema for essencial, Manage^JRNROLL pode suspender temporariamente o processo de reversão. Em geral, não recomendo usar esse utilitário, já que você quase certamente sacrificará a integridade transacional. Será preciso avaliar se o tempo de atividade é importante o suficiente para fazer esse tradeoff, e você também precisará se preparar para tomar qualquer medida necessária para solucionar o estado dos dados quando as transações não estiverem sendo resolvidas corretamente.
Não posso discutir todo cenário possível aqui, mas recomendo que você entre em contato com a WRC para receber ajuda se achar que precisa usar isso.
Além disso, Manage^JRNROLL permite que você monitore o processo de reversão. Ele dirá a você se a instância está verificando os arquivos de diário ou está realizando a reversão, quantos MB ainda precisam ser processados dos diários e quantas transações abertas foram encontradas. Outra opção para monitorar a reversão é o messages.log. Em versões modernas, você deve receber mensagens do messages.log relatando a quantidade de dados que ainda precisam ser processados e o número de transações abertas.
Depois de aplicar um backup, ^JRNRESTO é o utilitário usado para aplicar os arquivos de diário do momento do backup até o presente. Isso se chama "dejournaling." ^JRNRESTO só afetará os bancos de dados que estão definidos como diário ao executar a rotina.
^JRNRESTO oferece vários recursos para definir os diários que serão restaurados. Principalmente, você pode especificar vários arquivos de diário. Você também pode selecionar bancos de dados ou globais específicos para serem atualizados. Além disso, é possível selecionar bancos de dados ou globais individuais para a restauração. Para mais granularidade, você pode usar um filtro de diário personalizado de ^ZJRNFILT, que será abordado depois. Você também pode restaurar para a instância atual ou para os bancos de dados de outra instância do IRIS. ^JRNRESTO também pode ser usado para inicializar a atualização do espelho se você estiver tentando restaurar finais de diário espelho para um banco de dados espelhado no mesmo espelho. Nesse caso, ele simplesmente usará MirrorCatchup^JRNRESTO.
^JRNRESTO permite que você desative o diário para as atualizações de restauração, que melhorará o desempenho. Para aumentar ainda mais a velocidade do dejournaling, o dejournaling em paralelo pode usar até 4 jobs para atualizar vários bancos de dados ao mesmo tempo. Para usar isso, você precisaria de pelo menos 8 CPUs e heap de memória compartilhada suficiente configurada (gmheap). Cada job paralelo que você quer usar requer 200 MB de gmheap, ou seja, é necessário um mínimo de 400 MB de gmheap para usar o dejournaling em paralelo. Mesmo se você não alcançar esse limite, aumentar o heap de memória compartilhada pode melhorar o desempenho. É possível modificar a configuração de gmheap no portal de gerenciamento (Administração do Sistema > Configuração > Configurações Adicionais > Memória Avançada) e exige a reinicialização. Se a configuração permitir, por padrão, o IRIS usará o dejournaling em paralelo.
Você pode iniciar a restauração do diário ao trocar para o namespace %SYS e inserir "do ^JRNRESTO". A melhor forma de se familiarizar com esse utilitário é testar por conta própria, já que você pode ter uma ideia melhor do tipo de restauração de diário que talvez seja necessário em seu ambiente. Exemplos de prompts e amostras de saída estão disponíveis na documentação, e descreverei as etapas do processo, para você saber o que esperar.
Se a instância está em um espelho, o primeiro prompt perguntará se você quer "Atualizar bancos de dados espelhados? Não =>". Sua resposta aqui determinará se você será redirecionado para MirrorCatchup^JRNRESTO ou seguirá com mais prompts para especificar manualmente quais diários devem ser restaurados para quais bancos de dados.
Se você definiu um filtro de diário (ZJRNFILT, discutido abaixo), precisará responder se esse filtro deve ser usado ou não. MARKER^ZJRNFILT não é aplicável à grande maioria dos casos de uso:
"Usar filtro de diário atual (ZJRNFILT)?
Usar filtro de marcador de diário (MARKER^ZJRNFILT)?"
Depois disso, você pode especificar se quer "Processar todos os globais de diário em todos os diretórios?" ou não. Se você não quiser restaurar nada, precisará responder a uma série de prompts para declarar o que exatamente deseja restaurar. Você poderá escolher bancos de dados (mesmo para uma instância diferente do IRIS) e globais para cada banco de dados.
O primeiro esclarecimento solicitado será "Os arquivos de diário são importados de um sistema operacional diferente?" Isso determinará se ^JRNRESTO pode usar o formato de caminho de diretório padrão do SO.
A próxima etapa será especificar o caminho do diretório para o banco de dados de origem no prompt "Diretório para restaurar [? para ajuda]". Se você estiver restaurando diários espelhados para um banco de dados não espelhado, também pode usar o nome de espelho completo aqui (por exemplo, :mirror:<mirror_config_name>:<mirror_db_name>). O seguinte prompt é "Redirecionar para o diretório", para selecionar o banco de dados de destino. Você pode escolher o padrão e pressionar <enter> para selecionar a origem como o destino.
Para cada banco de dados, se devem ser restaurados todos ou alguns globais específicos.
"Processar todos os globais em <directory_to_db>? Não =>"
Depois de inserir todos os bancos de dados que você quer restaurar, você pode pressionar <enter> em "Diretório para restaurar [? para ajuda]:" a fim de prosseguir. Você precisará confirmar suas seleções.
OBSERVAÇÃO: se você estiver restaurando vários bancos de dados de origem para um banco de dados de destino, precisará fazer a mesma seleção de globais ou restaurar todos os globais.
^JRNRESTO tenta facilitar o máximo possível a restauração de uma sequência de arquivos de diário. Seja fazendo qualquer especificação de banco de dados acima ou restaurando todas as entradas, o primeiro prompt é "Os arquivos de diários foram criados por essa instância do IRIS e estão localizados nos seus caminhos originais? (Usa journal.log para localizar diários)?" Se você selecionar "sim", ^JRNRESTO poderá gerar uma lista de arquivos de diário disponíveis a partir do journal.log, em vez de exigir que o usuário direcione manualmente o processo para os arquivos de diário. Também é possível selecionar "não, você deverá responder se tem uma cópia do journal.log a partir da instância do IRIS de origem, e apontar para o diretório com os arquivos de diário que você quer restaurar.
Em ambos os casos, você receberá o prompt a seguir, onde poderá ver uma lista de arquivos de diário e fazer sua seleção. Os backups iniciam a troca de diário e registram uma mensagem (se você iniciar um congelamento externo para um backup externo, isso será registrado no messages.log), que pode servir como guia para os diários que você quer restaurar:
"Especifique a variedade dos arquivos que serão processados
Insira ? para abrir uma lista de arquivos de diário e selecione o primeiro e o último arquivo de
Primeiro arquivo para processar:"
Se você não tiver um arquivo journal.log para consulta, ainda poderá fornecer nomes de arquivos de diário e um diretório para procurar arquivos.
O IRIS deixará você revisar os arquivos selecionados e perguntará se você quer verificar a integridade dos arquivos de diário. Se você estiver tentando restaurar um arquivo de diário ativo, o IRIS exigirá e solicitará que você troque o arquivo.
Como descrito acima, o dejournaling em paralelo pode ser usado para melhorar o desempenho. Se você estiver usando o dejournaling em paralelo, o processo não será registrado em diário. Se você não estiver usando o dejournaling em paralelo, ainda terá a opção de desativar o diário dessas atualizações, melhorando o desempenho.
A escolha final que você fará antes de começar a restauração do diário será como responder a erros. Você pode selecionar respostas a erros nos níveis do banco de dados e do diário. É possível determinar se você quer continuar ou abortar o processo caso haja qualquer tipo de erro. Se você decidir abortar em qualquer um dos casos, o dejournaling em paralelo não poderá ser usado.
O processo começará a relatar seu progresso, informando qual arquivo de diário está sendo processado e a % de conclusão periodicamente. Quando a restauração for concluída, aparecerá um resumo dela.
Observação: ao restaurar diários, as transações abertas serão revertidas. Para garantir que você não tenha preocupações de integridade das transações, reverta ou use o commit nas transações. Se você tiver preocupações com a atividade do usuário, pode reiniciar o IRIS no modo de usuário único, conforme documentado aqui:
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ASECMGMT#ASECMGMT_emerg
Você pode usar ^ZJRNFILT para criar um filtro personalizado para uso durante a restauração do diário, controlando os sets e kills aplicados. Você precisará criar uma rotina personalizada aceitando os seguintes parâmetros.
ZJRNFILT(jid,dir,glo,type,restmode,addr,time)
jid - ID do job para identificar o PID que gerou o diário
dir - caminho completo do diretório com o IRIS.DAT que será restaurado, especificado no registro do diário
glo - global no registro do diário
type - tipo de comando conforme especificado na documentação aqui:
restmode - defina isso como 1 ou 0 no seu código personalizado para determinar se um registro deve ser restaurado
addr - endereço do registro do diário
time - carimbo de data/hora do registro (formato $horolog). Observe que essa é a hora em que o buffer do diário é criado, e não quando realmente ocorre o set/kill.
Exemplos de como escrever um ^ZJRNFILT estão disponíveis na documentação. Se a rotina ^ZJRNFILT personalizada existir, a restauração do diário solicitará que você use o filtro. Ao usá-lo, o filtro será chamado em cada registro do diário. Isso usará a lógica que você escrever na rotina, envolvendo quaisquer parâmetros que você queira usar, para definir o restmode como 1 (aplicar) ou 0 (não aplicar).
Se o processo de inicialização ^STU chamar ^JRNRESTO, ele não aplicará seu filtro ZJRNFILT personalizado.
Quando a restauração do diário for concluída, você deverá renomear ou excluir o ^ZJRNFILT. Ao renomear a rotina, ela será copiada para ^XJRNFILT, e ^ZJRNFILT será excluído.
Se ^ZJRNFILT se deparar com um erro, o processo de restauração será abortado.
Às vezes, o portal de gerenciamento pode não ser suficiente para analisar os arquivos do diário. Isso pode acontecer devido ao arquivo do diário ser tão grande que ocorre um tempo limite. Nesses casos, você pode usar ^JRNDUMP ou SELECT^JRNDUMP para despejar os registros do diário, facilitando a visualização.
^JRNDUMP mostrará uma seleção de arquivos de diário e o diretório onde podem ser encontrados. Você pode usar as seguintes opções para navegar pela exibição: "Pg(D)n,Pg(U)p,(N)ext,(P)rev". Você também pode usar "(G)oto" para indicar diretamente um arquivo de diário para investigar.
A opção "(I)nfo" fornecerá metadados de um arquivo de diário, incluindo o arquivo GUID, tamanho máximo, data e hora de criação, número de arquivos, min trans, arquivo anterior, arquivo GUID anterior, final do arquivo anterior, próximo arquivo, próximo arquivo GUID. A maioria dessas entradas é facilmente compreensível, porém, "Min Trans" contém o arquivo do diário e o deslocamento em que sabemos que todas as transações estão fechadas. Depois desse ponto, pode haver transações abertas. A partir daí, "(D)atabases" dirá quais bancos de dados são afetados por esse arquivo de diário. Todas as informações "(I)nfo" também estão disponíveis na página "Resumo do Arquivo do Diário" no portal de gerenciamento de sistemas.
"(E)xamine" mostrará as entradas individuais do diário com o endereço, ID do processo, operação, diretório, global e valor. Você pode usar (N)ext, (P)rev, (G)oto e (F)ind para navegar por esses endereços do diário. "(E)xamine" mais para analisar uma única entrada em profundidade, que fornecerá quase as mesmas informações disponíveis na página "Ver diário" do portal de gerenciamento de sistemas. Isso seria o endereço, tipo de operação, se a operação estava em uma transação, ID do job, ID do processo, ID do sistema ECP (0 se não estiver configurado para ECP), carimbo de data/hora, ordenação, endereço anterior e próximo, além do global e do seu novo valor. Se a entrada foi gravada em uma transação, o valor antigo também será listado.
Uma lista completa das diferentes operações/tipos está disponível na documentação (vinculada na parte superior da seção ZJRNFILT).
Há três tipos principais de registros de diário: registros de dados, marcadores de diário e cabeçalhos de diário. ^JRNDUMP não mostrará cabeçalhos de diário, e marcadores de diário são indicados por Tipo: JrnMark. Os marcadores de diário são usados para várias operações de sistema diferentes, como backups. Quase todas as entradas que você verá serão registros de dados.
SELECT^JRNDUMP permite que você despeje entradas de diário filtradas no terminal ou em um arquivo. Você pode filtrar com base nos seguintes critérios:
SELECT^JRNDUMP(%jfile,%pid,%dir,%glo,%gloall,%operation,%remsysid)
%jfile - caminho completo de um arquivo do diário, o padrão é o arquivo atual
%pid - ID do processo, o padrão é "any"
%dir - diretório de um banco de dados, o padrão é "any"
%glo - referência do global, o padrão é "any"
%gloall - modificador de %glo. Se isso for 0, o filtro procurará exatamente pelo nome do global especificado por %glo. Se isso for 1, o filtro pegará os nomes dos globais com o parâmetro %glo
%operation - tipo de operação, o padrão é "any"
%remsysid - ID do sistema ECP, o padrão é "any"
Alguns exemplo de filtros especificados para SELECT^JRNDUMP estão disponíveis na documentação.
Se a inicialização do IRIS se deparar com um erro de restauração de transação ou diário, você talvez seja colocado no modo de usuário único. Você verá uma mensagem de messages.log assim:
12/28/18-07:06:43:099 (1234) 1 1 erros durante a restauração do diário,
veja mais detalhes no arquivo messages.log.
A inicialização foi abortada, entrando no modo de usuário único.
Entre no IRIS com
iris session IRIS -B
e execute ^STURECOV para ajudar na recuperação dos erros.
Dependendo do erro, ^STURECOV oferece diferentes opções para ajudar você a se recuperar.
Observação sobre o espelho: ^STURECOV não poderá ser executado em um banco de dados se a reversão de transação estiver em andamento, já que o banco de dados não montará a leitura/gravação até que a reversão seja concluída. A Opção 11 do ^JOURNAL acima: Manage^JRNROLL aborda o que você deve fazer nesse caso.
Especificamente para um erro de diário, o menu ^STURECOV ficará assim:
1) Exibir a lista de erros da inicialização
2) Executar a restauração do diário novamente
3) Derrubar o sistema antes de uma inicialização normal
4) Desmontar um banco de dados
5) Montar um banco de dados
6) Utilitário de conserto do banco de dados
7) Verificar a integridade do banco de dados
8) Redefinir o sistema para que o diário não seja restaurado na inicialização
9) Exibir instruções sobre como desativar o sistema >>>>> [somente Unix]
10) Exibir Menu do Diário (^JOURNAL)
Alerta: a opção 8 é irreversível e impedirá que a próxima inicialização faça a restauração do diário. Nesse ponto, se você quiser restaurar diários, precisará usar ^JRNRESTO. Isso geralmente só deve ser usado se houver uma necessidade de contornar a recuperação e inicializar o IRIS.
Esse utilitário pode ser usado para adicionar um marcador de diário ao arquivo do diário - você provavelmente não precisará usá-lo. Ele é usado da seguinte maneira:
SET rc=$$ADD^JRNMARK(id,text)
"rc" retornará o deslocamento do diário e o nome do arquivo do diário. O id pode ser qualquer valor inteiro (entradas inválidas são definidas como 0 por padrão) e o texto pode ser qualquer string de até 256 caracteres.
Você poderá ver o marcador do diário no arquivo do diário, porém, se quiser analisar o texto ou o id, precisará usar ^JRNDUMP. O portal de gerenciamento de sistemas não oferece essa funcionalidade.
^JRNUTIL inclui várias tags que permitem a manipulação de arquivos de diário programaticamente. Isso permite que você abra, exclua ou leia um arquivo de diário, entre outras opções.
Se você tiver interesse em usar essas funções, provavelmente deve falar direto com alguém da InterSystems.
Esses utilitários só são necessários para a conversão de DSM para Caché. Eles permitem que você converta arquivos de diário para um formato comum. Um exemplo está disponível na documentação, mas esse uso é específico o suficiente para que eu não o aborde aqui.
Apenas leia a primeira seção e a documentação de melhores práticas. Espero que você tenha achado essa visão geral do diário útil - ela foi escrita por um humano (admin de sistema) para um humano. Fique à vontade para fazer comentários ou perguntas abaixo. Você também pode me enviar uma mensagem direta.
A família InterSystems IRIS tem um ótimo utilitário ^SystemPerformance (conhecido como ^pButtons no Caché e no Ensemble) que gera as informações de desempenho do banco de dados em um arquivo HTML legível. Ao executar ^SystemPerformance no IRIS para Windows, um arquivo HTML é criado onde nosso próprio log de desempenho mgstat e o log de desempenho do Windows são incluídos.
^SystemPeformance gera um ótimo relatório, mas você precisa extrair seções de log manualmente de um arquivo HTML e colá-las em um editor de planilha como o Excel para criar um gráfico visual de desempenho. Vários desenvolvedores já compartilham dicas e utilitários úteis para fazer isso aqui (Este é um ótimo artigo no Developer Community, de @Murray Oldfield )
Agora, apresento o novo utilitário ^mypButtons!
Baixe mypButtons.mac no OpenExchange.
Observação! Se você quiser reproduzir mypButtons.csv, carregue os arquivos HTML SystemPerformance com o perfil "a cada 1 segundo".
do readone^mypButtons("C:\temp\dir\myserver_IRIS_20230522_130000_8hours.html","^||naka")Ele lê um arquivo HTML SystemPerformance e armazena as informações em um determinado global. Nessa amostra, ele lê myserver_IRIS_20230522_130000_8hours.html e armazena-o em ^||naka.
do readdir^mypButtons("C:\temp\dir","^||naka")Ele lê todos os arquivos HTML SystemPerformance HTML em uma pasta específica e armazena as informações em um determinado global. Nessa amostra, ele lê todos os arquivos HTML em C:\temp\dir e armazena-os em ^||naka.
do writecsv^mypButtons("C:\temp\csv","^||naka")Ele gera os três arquivos csv a seguir em uma pasta específica a partir de um determinado global.
Aqui, mypButtons.csv inclui as seguintes colunas por padrão, que recomendo muito verificar primeiro para ver o desempenho:
Esse utilitário funciona para o InterSystems IRIS, InterSystems IRIS for Health, Caché e Ensemble para Windows.
(1) Primeiro, execute ^SystemPerformance para registrar nossa própria ferramenta de desempenho mgstat e o monitor de desempenho do Windows perfmon. Por padrão, o InterSystems IRIS possui alguns perfis, então você pode aproveitá-los logo. Tente isto no terminal IRIS.
%SYS> do^SystemPerformance
Current log directory: c:\intersystems\iris\mgr\
Windows Perfmon data will be left in raw format.
Available profiles:
112hours - 12-hour run sampling every 10 seconds
224hours - 24-hour run sampling every 10 seconds
330mins - 30-minute run sampling every 1 second
44hours - 4-hour run sampling every 5 seconds
58hours - 8-hour run sampling every 10 seconds
6 test - 5-minute TEST run sampling every 30 seconds
select profile number to run: 3Observação! Se você quiser reproduzir mypButtons.csv, use o perfil "a cada 1 segundo". Por padrão, você verá um perfil de "30 mins" que faz a amostragem a cada 1 segundo. Se quiser criar outros perfis, veja nossa documentação para mais detalhes.
(2) Depois da amostragem, um HTML será gerado em irisdir\mgr, cujo nome é parecido com JP7320NAKAHASH_IRIS_20231115_100708_30mins.html. Abra um HTML gerado, e você verá muitos dados de desempenho separados por vírgulas nas seções mgstat e na seção perfmon.
(3) Carregue-o com ^mypButtons conforme abaixo.
USER> do readone^mypButtons("C:\InterSystems\IRIS\mgr\JP7320NAKAHASH_IRIS_20231115_100708_30mins.html","^||naka")Isso carregará o HTML no primeiro parâmetro e salvará os dados de desempenho no global no segundo parâmetro.
(4) Gere o CSV com ^mypButtons conforme abaixo.
USER> do writecsv^mypButtons("C:\temp","^||naka")Isso gerará três arquivos CSV na pasta no primeiro parâmetro do global no segundo parâmetro. Abra mypButtons.csv no excel, e você pode ver mgstat e perfmon na mesma linha a cada segundo. Veja esta captura de tela - as colunas destacadas em amarelo são mgstat, e as em azul são perfmon.
(5) Vamos criar um gráfico simples com esse CSV. É muito fácil. Escolha a coluna B Time e a coluna C Glorefs, selecione o menu Insert (Inserir), gráficos de linhas 2D, conforme abaixo.
Esse gráfico mostrará informações de "Números de referência do global por segundo". Infelizmente, houve muito poucas atividades em minha instância IRIS, então meu gráfico de amostra não animará você, mas acredito que este gráfico do servidor de produção traz muitas informações úteis!
(6) mypButtons.csv inclui colunas selecionadas que acredito que você deve verificar primeiro. A série de artigos de Murray fala sobre a importância dessas colunas para ver o desempenho.
Se você quiser mudar as colunas relatadas no mypButtons.csv, modifique o rótulo writecsv manualmente. Ele relata as colunas definidas nessa área.
Espero que meu artigo e utilitário incentivem você a conferir o desempenho do InterSystems IRIS. Feliz SystemPeformance 😆
Temos o prazer de anunciar uma nova parte da documentação da InterSystems que facilita a atualização da plataforma de dados InterSystems IRIS®, InterSystems IRIS® for Health™ ou HealthShare® Health Connect. A lista de verificação de impacto da atualização em https://docs.intersystems.com/upgrade mostra tudo o que você precisa considerar – e apenas o que você precisa considerar – em uma atualização entre duas versões quaisquer. Isso pega todo o conteúdo do nosso "Histórico de incompatibilidade" e adiciona filtros convenientes, categorias de nível superior e a capacidade de exportar a lista como
Com frequência, me pedem para avaliar dados de desempenho relacionados a aplicativos IRIS de clientes para entender se os recursos do sistema são sub ou superprovisionados.
Este exemplo recente é interessante, porque envolve um aplicativo que fez uma migração "lift and shift" de um grande aplicativo de banco de dados IRIS para a nuvem. AWS, no caso.
Um aprendizado importante é que, depois de migrar para a nuvem, os recursos podem ser dimensionados corretamente ao longo do tempo conforme necessário. Não é preciso comprar e provisionar infraestrutura local para o crescimento que você espera alcançar daqui a vários anos no futuro.
É necessário monitoramento contínuo. A taxa de transações do seu aplicativo mudará à medida que seu negócio e o próprio aplicativo ou o uso dele mudar. Isso alterará os requisitos de recursos do sistema. Planejadores também devem considerar picos sazonais na atividade. Claro, uma vantagem da nuvem é que os recursos podem ser aumentados ou reduzidos conforme necessário.
Para mais informações contextuais, há vários posts detalhados sobre AWS e IRIS na comunidade. Um bom ponto de partida é pesquisar "referência da AWS". Também adicionei alguns links úteis no final deste post.
Os serviços da AWS são como blocos de Lego: tamanhos e formatos diferentes podem ser combinados. Ignorei networking, segurança e preparação de uma VPC para este post. Foquei em dois dos componentes de blocos de Lego;
O aplicativo é um sistema de informações de saúde usado em um grupo de hospitais movimentados. Os componentes da arquitetura em que estou focando aqui incluem dois servidores de bancos de dados em um cluster de tolerância a falhas de espelho da InterSystems.
Barra lateral: os espelhos estão em zonas de disponibilidade separadas para alta disponibilidade adicional.
O Amazon EC2 oferece uma ampla seleção de tipos de instância otimizados para diferentes casos de uso. Os tipos de instância compreendem combinações FIXAS variadas de CPU e memória, além de limites máximos fixos de capacidade de armazenamento e de networking. Cada tipo de instância inclui um ou mais tamanhos de instância.
Os atributos da instância EC2 que devem ser analisados com mais atenção incluem:
Para aplicativos IRIS como esse com um grande servidor de banco de dados, dois tipos de instâncias EC2 são apropriadas:
Observação: nem todos os tipos de instâncias estão disponíveis em todas as regiões da AWS. As instâncias R5 foram usadas nesse caso porque a R6i lançada mais recentemente não estava disponível.
Quando um sistema local existente está disponível, o planejamento da capacidade significa medir o uso atual de recursos, traduzindo isso para os recursos na nuvem pública e adicionando recursos para o crescimento previsto a curto prazo. Geralmente, se não há outros limites de recursos, os aplicativos do banco de dados do IRIS são escalados linearmente nos mesmos processadores. Por exemplo, imagine adicionar um novo hospital ao grupo. O aumento do uso do sistema (taxa de transações) em 20% exigiria 20% mais recursos de vCPU usando os mesmos tipos de processadores. É claro que isso não é garantido. Valide seus aplicativos.
Antes da migração, a utilização da CPU chegava a quase 100% em períodos movimentados. O servidor no local tem 26 vCPUs. Uma boa regra geral é avaliar sistemas com um pico esperado de 80% de utilização da CPU. Isso permite picos temporários na atividade ou outras atividades incomuns. Confira abaixo um gráfico de exemplo para a utilização da CPU em um dia típico.
O monitoramento dos servidores locais exigiria o aumento para 30 núcleos de vCPUs, trazendo o pico geral de utilização para abaixo de 80%. O cliente esperava adicionar um crescimento de transações de 20% no curto prazo. Então, um buffer de 20% é adicionado aos cálculos, permitindo também uma capacidade de reserva adicional para o período de migração.
Um cálculo simples é que 30 núcleos + 20% de crescimento e buffer de migração equivale a 36 núcleos de vCPU necessários.
Lembre-se de que as instâncias EC2 da AWS em cada tipo de família têm tamanhos fixos de vCPU e memória e definem limites máximos de IOPS, armazenamento e taxa de transferência de rede.
Por exemplo, os tipos de instância disponíveis nas famílias R5 e R6i incluem:
Regra geral: Uma maneira simplificada de dimensionar uma instância EC2 a partir de métricas locais conhecidas para a nuvem é arredondar os requisitos de vCPU locais recomendados para o próximo tamanho de instância EC2 disponível.
Ressalvas: Pode haver várias outras considerações. Por exemplo, diferenças nos tipos e nas velocidades dos processadores locais e do EC2, ou um armazenamento mais eficiente na nuvem do que em um sistema local antigo, podem significar que os requisitos de vCPU mudam. Por exemplo, é possível ter mais IO e fazer mais trabalho em menos tempo, aumentando o pico de utilização da vCPU. Os servidores locais podem ter um processador de CPU completo, incluindo hyper-threading, e as vCPUs das instâncias na nuvem serem um único hyper thread. Por outro lado, as instâncias EC2 são otimizadas para transferir parte do processamento para placas Nitro integradas. Assim, os principais núcleos de vCPU gastam mais ciclos processando as cargas de trabalho, melhorando o desempenho das instâncias. Porém, em resumo, a regra acima é um ótimo guia para começar. A vantagem da nuvem é que, com monitoramento contínuo, você pode planejar e mudar o tipo de instância para otimizar o desempenho e custo.
Por exemplo, para traduzir 30 ou 36 vCPUs locais em tipos de instância EC2 semelhantes:
Observe o máximo de IOPS. Isso será importante mais tarde.
Uma instância r512xlarge foi selecionada para os espelhos do banco de dados do IRIS para a migração.
Nas semanas seguintes à migração, o monitoramento mostrou que o tipo de instância de 48 vCPUs sustentou picos de quase 100% de utilização da vCPU. No entanto, em geral, o processamento chegou a aproximadamente 70%. Isso está bem dentro da faixa aceitável e, se os períodos de alta utilização forem atribuídos a um processo que pode ser otimizado, há bastante capacidade de reserva para considerar o dimensionamento para uma especificação inferior e um tipo de instância EC2 mais barato.
Um tempo depois, o tipo de instância permaneceu igual. Uma verificação do desempenho do sistema mostra que o pico de utilização da vCPU caiu para cerca de 50%. No entanto, ainda há picos temporários perto de 100%.
É necessário monitoramento contínuo. Com o monitoramento constante, o sistema pode ser dimensionado corretamente para alcançar o desempenho necessário e ter uma execução mais barata.
Os picos temporários na utilização da vCPU devem ser investigados. Por exemplo, um relatório ou uma tarefa em lote podem ser retirados do horário comercial, diminuindo o pico geral da vCPU e reduzindo qualquer impacto negativo nos usuários interativos do aplicativo.
Revise os requisitos de IOPS e taxa de transferência de armazenamento antes de mudar o tipo de instância. Não se esqueça que os tipos de instância têm limites máximos fixos de IOPS.
As instâncias podem ser dimensionadas usando o espelhamento de tolerância a falhas. Etapas simplificadas:
Observação: durante a tolerância a falhas do espelho, haverá uma breve interrupção para todos os usuários, interfaces etc. No entanto, se forem usados servidores de aplicações ECP, poderá não haver nenhuma interrupção para os usuários. Os servidores de aplicações também podem fazer parte de uma solução de escalonamento automático.
Outras opções econômicas incluem executar o espelho de backup em uma instância menor. No entanto, há um risco significativo de desempenho reduzido (e usuários insatisfeitos) se uma tolerância a falhas ocorrer em momentos de pico de processamento.
Ressalvas: As vCPUs e memória das instâncias são fixas. Recomeçar com uma instância e pegada de memória menores implica em um cache de buffer global menor, o que pode aumentar a taxa de IOPS de leitura do banco de dados. Considere os requisitos de armazenamento antes de reduzir o tamanho da instância. Automatize e teste o dimensionamento para minimizar o risco de erro humano, especialmente se for uma ocorrência comum.
Um desempenho de IO de armazenamento previsível com baixa latência é essencial para fornecer escalabilidade e confiabilidade para seus aplicativos.
O armazenamento do Amazon Elastic Block Store (EBS) é recomendado para a maioria dos aplicativos de banco de dados do IRIS com altas taxas de transações. O EBS oferece vários tipos de volumes que permitem otimizar o desempenho do armazenamento e o custo para uma ampla variedade de aplicativos. O armazenamento baseado em SSD é necessário para cargas de trabalho transacionais, como aplicativos que usam bancos de dados do IRIS.
Dos tipos de armazenamento SSD, os volumes gp3 são geralmente recomendados para bancos de dados do IRIS, porque equilibram o preço e o desempenho para aplicativos transacionais. No entanto, para casos excepcionais com taxas muito altas de IOPS ou de transferência, o io2 pode ser usado (geralmente por um custo mais alto). Há outras opções, como as soluções de armazenamento temporário anexado localmente e arrays virtuais de terceiros. Se você tiver requisitos que ultrapassam as capacidades do io2, fale com a InterSystems sobre suas necessidades.
O armazenamento acompanha limites e custos, por exemplo.
Lembre-se: as instâncias EC2 também têm limites de IOPS e taxa de transferência total do EBS. Por exemplo, o r5.8xlarge tem 32 vCPUs e um máximo de 30.000 IOPS. Nem todos os tipos de instâncias são otimizados para usar os volumes do EBS.
Quando um sistema local existente está disponível, o planejamento da capacidade significa medir o uso atual de recursos, traduzindo isso para os recursos na nuvem pública e adicionando recursos para o crescimento previsto a curto prazo.
Os dois recursos essenciais que devem ser considerados:
Antes da migração, as leituras de disco de banco de dados atingiam cerca de 8.000 IOPS.
A taxa de IOPS de leitura e escrita ultrapassava 40.000 em alguns dias. Embora, durante o horário comercial, os picos sejam bem mais baixos.
A taxa de transferência total de leituras e escritas atingiu cerca de 600 MB/s.
Lembre-se: as instâncias EC2 e os volumes do EBS têm limites de IOPS E taxa de transferência*. O limite que for atingido primeiro resultará na restrição desse recurso pela AWS, causando a degradação do desempenho e possivelmente afetando os usuários do seu sistema. Você precisa provisionar IOPS E taxa de transferência.
Os volumes gp3 são usados para equilibrar o preço e o desempenho. No entanto, nesse caso, o limite de 16.000 IOPS para um único volume gp3 foi excedido, e há a expectativa de que os requisitos aumentarão no futuro.
Para permitir o provisionamento de uma taxa IOPS mais alta do que o possível em um único volume gp3, é usada uma distribuição do LVM.
Para a migração, o banco de dados é implantado usando uma distribuição do LVM de quatro volumes gp3 com o seguinte:
O processo exato de planejamento de capacidade foi realizado para o Write Image Journal (WIJ) e os discos locais de diário de transações. O WIJ e os discos de diário foram provisionados em um único disco gp3 cada.
Para mais detalhes e um exemplo de como usar uma distribuição do LVM, veja: https://community.intersystems.com/post/using-lvm-stripe-increase-aws-ebs-iops-and-throughput
Regra geral: Se os seus requisitos ultrapassarem os limites de um único volume gp3, investigue a diferença de custo entre usar IOPS provisionadas do gp3 do LVM e do io2.
Ressalvas: Garanta que a instância EC2 não limite as taxas de IOPS ou de transferência.
Nas semanas seguintes à migração, as IOPS de escrita de banco de dados atingiram cerca de 40.000 IOPS, semelhante a no local. No entanto, as IOPS de leitura de banco de dados foram muito mais baixas.
Uma menor taxa de IOPS de leitura é esperada devido à instância EC2 ter mais memória disponível para armazenar dados em cache nos buffers globais. Mais dados do conjunto de trabalho do aplicativo na memória significa que eles não precisam ser chamados de um armazenamento SSD muito mais lento. Lembre-se, acontecerá o oposto se você reduzir a pegada de memória.
Durante os momentos de pico de processamento, o volume do banco de dados teve picos de latência acima de 1 ms. No entanto, os picos são temporários e não afetam a experiência do usuário. O desempenho do armazenamento é excelente.
Depois, uma verificação de desempenho do sistema mostra que, embora haja alguns picos, geralmente, a taxa de IOPS de leitura ainda é menor do que no local.
É necessário monitoramento contínuo. Com o monitoramento constante, o sistema pode ser dimensionado corretamente para alcançar o desempenho necessário e ter uma execução mais barata.
O processo de aplicação responsável pelos 20 minutos de alta IOPS de escrita de banco de dados durante a noite (gráfico não exibido) deve ser analisado para entender o que ele está fazendo. As escritas não são afetadas por grandes buffers globais e ainda estão na faixa de 30-40.000 IOPS. O processo poderia ser concluído com um menor provisionamento de IOPS. No entanto, haverá um impacto mensurável na latência de leitura do banco de dados se as escritas sobrecarregarem o caminho de IO, afetando negativamente os usuários interativos. A latência de leitura precisa ser monitorada atentamente se as leituras forem limitadas por um longo período.
O provisionamento de IOPS e taxa de transferência de disco do banco de dados pode ser ajustado pelas APIs da AWS ou interativamente pelo console da AWS. Como quatro volumes do EBS compõem o disco LVM, os atributos de IOPS e de taxa de transferência dos volumes do EBS precisam ser ajustados igualmente.
O WIJ e o diário também devem ser monitorados continuamente para entender se é possível fazer alguma alteração no provisionamento de IOPS e de taxa de transferência.
Observação: o volume do WIJ tem requisitos de alta taxa de transferência (não IOPS) devido ao tamanho do bloco de 256 kB. A taxa de IOPS do volume do WIJ pode estar abaixo da linha de base de 3.000 IOPS, mas a taxa de transferência está atualmente acima da linha de base de taxa de transferência de 125 MB/s. É provisionada uma taxa de transferência adicional no volume do WIJ.
Ressalvas: Diminuir o provisionamento de IOPS para limitar o período de altas escritas noturnas resultará em um ciclo mais longo do daemon de escrita (WIJ mais escritas aleatórias de banco de dados). Isso pode ser aceitável se as escritas forem concluídas em 30-40 segundos. No entanto, pode haver um grave impacto na latência de leitura e IOPS de leitura e, portanto, na experiência dos usuários interativos no sistema por 20 minutos ou mais. Prossiga com cautela.
Isso pode ser obtido usando a consulta AllFields query da classe %SYS.ProcessQuery.
Para obter mais detalhes, consulte o documento Process (Job)【IRIS】／Process (Job).
Um exemplo de execução no terminal é o seguinte.
#O problema
Temos o seguinte cenário, você trabalha em um laboratório, que até então atendia apenas exames realizados em uma região geográfica especifica, porém dentro de um curto espaço de tempo, percebe que seu negócio está expandindo para outras regiões, a demanda pela entrega dos resultados dos exames passa a não ser mais suportada pelo servidor principal, quedas e lentidões devido a alta repentina de solicitações, passam a ser mais frequentes e seus clientes passam a reclamar da indisponibilidade do sistema, como lidar com essa situação ?
Obviamente sua aplicação precisa ter a infraestrutura aprimorada, caso esteja utilizando a plataforma de dados InterSystems IRIS/Caché, a utilização de ECP’s pode ser uma saída para o problema.
#ECP
ECP - “Enterprise Cache Protocol” protocolo com arquitetura de cache de dados distribuídos, permite distribuir dados e lógica de aplicativos de forma eficiente em vários sistemas de servidores.
Ao contrário de outras arquiteturas multicamadas, o ECP é uma opção de configuração, que não requer usar código especial ou técnicas de desenvolvimento para criar aplicativos de banco de dados distribuídos, fazendo com que diversos servidores executem a aplicação usando a mesma base de código, permitindo que os desenvolvedores se concentrem na funcionalidade central centrada no cliente, tornando o aplicativo mais simples de manter.
#Configuração ECP’s?
Para compreender a configuração de um E.C.P, é importante entender como os artefatos de código e dados são organizados dentro da plataforma InterSystems IRIS.
#Mapeamento de namespaces.
Namespace é uma unidade lógica de organização em InterSystems IRIS que permite a separação de objetos e recursos do sistema em grupos distintos. Tornando mais fácil a administração e o gerenciamento do sistema.
Cada Namespace é configurado para utilizar banco de dados de globais e rotinas, que é utilizado para armazenar e gerenciar os dados globais e objetos de rotinas.
O Banco de dados provedor de globais, é usado para armazenar e gerenciar os dados globais em um determinado namespace.
##- Banco de dados provedor de Rotinas: Rotinas são artefatos do banco que executam tarefas específicas no sistema, plataformas de dados InterSystems utilizando o provedor de rotinas como um banco de dados especializado para armazenar e gerenciar as rotinas de código em um namespace.
#Realizar os mapeamentos Para configurar o ECP (Enterprise Cache Protocol), é necessário seguir alguns passos simples. Primeiramente, é preciso instalar uma nova máquina com uma instância de InterSystems IRIS ou Cache. Em seguida, é necessário configurar os servidores de aplicação no servidor de dados e vice-versa, para que o ambas instâncias Intersystems possam se comunicar, podendo configurar e distinguir entre bancos de dados locais e remotos entre as instâncias.
• Banco de dados local: É o banco de dados que reside fisicamente na mesma máquina em que o banco IRIS/Caché está sendo executado, associado a uma instância InterSystmes, sendo acessado e gerenciado pela própria instância do IRIS no servidor local.
• Banco de dados remoto: Banco de dados que está localizado em um servidor separado, ou seja, em uma máquina diferente daquela onde o IRIS está sendo executado.
Em seguida, devemos configurar o E.C.P (novo servidor de aplicação) para utilizar os bancos de dados remotos, provenientes do servidor de dados principal (onde possui os seus apontamentos locais), com a possibilidade de organização do namespace apontar para os bancos de global (dados) e rotinas (código) remotos, seguindo a seguinte estrutura:
Ao configurar o Enterprise Cache Protocol (ECP) e o namespace no InterSystems IRIS com o uso de bancos de dados remotos, ocorre uma distribuição de tarefas e recursos entre o servidor de aplicação (onde está o ECP) e o servidor de dados (onde estão os bancos de dados locais).
#Rede de E.C.Ps:
No cenário de configuração de diversos E.C.P.s com bancos de dados remotos, os processos (JOBs), são executados no servidor de aplicação controlando o fluxo de trabalho e garantindo a escalabilidade e o balanceamento de carga.
No entanto, os dados e as rotinas são armazenados no servidor de dados, onde estão localizados os bancos de dados locais. Ele fornece o armazenamento centralizado para os dados e as rotinas utilizados pelos processos executados no servidor de aplicação.
Essa arquitetura distribuída permite que o processamento e o armazenamento sejam separados, essa configuração permite um ambiente distribuído eficiente, com recursos compartilhados.
Desta forma você pode escalar sua aplicação, para atender uma demanda que seu sistema necessita, sem a alteração de códigos de sua aplicação, a expansão do seu laboratório para outras regiões geográficas pode trazer desafios significativos em relação à capacidade e disponibilidade do sistema. No entanto, a utilização dos ECPs (Enterprise Cache Protocol) no InterSystems IRIS/Caché pode ser solução viável para lidar com essa situação. Ao implementar uma infraestrutura aprimorada e distribuída, é possível alcançar uma maior capacidade de processamento, melhorar o desempenho e garantir a disponibilidade dos resultados dos exames.
Os ECPs permitem uma distribuição eficiente da carga de trabalho, com processos sendo executados nos servidores de aplicação e os dados sendo armazenados nos servidores de dados.
Essa abordagem proporciona uma maior escalabilidade e balanceamento de carga, evitando quedas e lentidões causadas pelo aumento repentino na demanda. Além disso, a infraestrutura distribuída permite a centralização e o gerenciamento eficiente dos dados, facilitando a expansão para novas regiões sem comprometer a qualidade do serviço.
Ao adotar os ECPs no InterSystems IRIS/Caché, você estará preparando sua aplicação para suportar o crescimento e atender às demandas dos clientes em diferentes regiões geográficas. Essa solução proporciona maior escalabilidade e desempenho, permitindo que seu laboratório ofereça um serviço de qualidade, com resultados de exames entregues.
Dentre as diversas soluções que desenvolvemos aqui na Innovatium, um desafio comum é a necessidade de acesso ao tamanho das bases de dados. Entretanto, notei que isso não é algo tão trivial no IRIS. Esse tipo de informação é importante para manter um controle do fluxo de dados e do custo em GB's de um sistema a ser implementado. Contudo, o que realmente me chamou atenção é a necessidade dela para uma função muito importante: migrar para cloud. Afinal, quem não quer migrar seus sistemas para cloud hoje em dia, certo?