Documentação Técnica — Quarkus IRIS Monitor System

1. Objetivo e Escopo

Este módulo permite a integração entre aplicações Java baseadas em Quarkus e as capacidades nativas de monitoramento de performance do InterSystems IRIS.
Ele possibilita que o desenvolvedor anote métodos com @PerfmonReport, acionando automaticamente as rotinas ^PERFMON do IRIS durante a execução do método e gerando relatórios de performance sem intervenção manual.

2. Componentes do Sistema

2.1 Anotação: @PerfmonReport

• Definida como InterceptorBinding do CDI.
• Pode ser aplicada a métodos ou classes.
• Instrui o framework a envolver a execução do método com a lógica de monitoramento do IRIS.

2.2 Interceptor: PerfmonReportInterceptor

• Intercepta chamadas a métodos anotados.

• Fluxo de execução:

  1. Registrar evento de início (LOG.infof("INIT: …"))
  2. Chamar monitorSystem.startPerfmon()
  3. Prosseguir com context.proceed()
  4. No bloco finally:
     • Chamar monitorSystem.generateReportPerfmon(...)
     • Chamar monitorSystem.stopPerfmon()
     • Registrar evento de fim com tempo de execução

• Garante que o monitoramento sempre será encerrado, mesmo se ocorrer uma exceção.

2.3 Bean DAO: MonitorSystem

• Bean CDI anotado com @ApplicationScoped.

• Mantém uma única instância de IRIS inicializada na inicialização.

• Configuração injetada via @ConfigProperty (URL JDBC, usuário, senha).

• Utiliza DriverManager.getConnection(...) para obter uma IRISConnection nativa.

• Contém os métodos:

  • startPerfmon()
  • generateReportPerfmon(String reportName)
  • stopPerfmon()

• Cada método chama as correspondentes rotinas ObjectScript em iris.src.dc.AdapterPerfmonProc via iris.classMethodVoid(...).

2.4 Adapter ObjectScript: iris.src.dc.AdapterPerfmonProc

• Define as rotinas que encapsulam a lógica do ^PERFMON:

    Class iris.src.dc.AdapterPerfmonProc Extends %RegisteredObject
    {
        ClassMethod start() As %Status
        {
            Set namespace = $NAMESPACE
            zn "%SYS"
            set status = $$Stop^PERFMON()
            set status = $$Start^PERFMON()
            zn namespace
            return status
        }
  
        ClassMethod generateReport(nameReport As %String = "report.txt") As %Status
        {
            Set namespace = $NAMESPACE
            zn "%SYS"
            Set tempDirectory = ##class(%SYS.System).TempDirectory()
            set status = $$Report^PERFMON("R","R","P", tempDirectory_"/"_nameReport)
            zn namespace
  
            return status
        }
  
        ClassMethod stop() As %Status
        {
            Set namespace = $NAMESPACE
            zn "%SYS"
            Set status = $$Stop^PERFMON()
            zn namespace
  
            return status
        }
    }
  

  Opera no namespace %SYS para acessar as rotinas ^PERFMON e, em seguida, retorna para o namespace original.

• Opera no namespace %SYS para acessar as rotinas ^PERFMON, retornando ao namespace original.

3. Fluxo de Execução

1. Uma requisição entra na aplicação Quarkus.

2. O interceptor CDI detecta a anotação @PerfmonReport e intercepta a chamada do método.

3. monitorSystem.startPerfmon() é invocado, acionando o monitoramento ^PERFMON do IRIS.

4. O método de negócio é executado normalmente (acesso a dados, transformações, lógica, etc.).

5. Após o método retornar ou lançar uma exceção, o interceptor garante que:

   • monitorSystem.generateReportPerfmon(...) seja chamado para criar um relatório de performance .txt.
   • monitorSystem.stopPerfmon() seja executado para encerrar a sessão de monitoramento.
   • O tempo total de execução do lado Java seja registrado usando Logger.infof(...).

6. O arquivo de relatório gerado é armazenado no diretório temporário do IRIS, normalmente: /usr/irissys/mgr/Temp/

   • O nome do arquivo segue o padrão: <ClassName><MethodName><timestamp>.txt

4. Desafios Técnicos e Soluções

5. Casos de Uso e Benefícios

• Permite visibilidade em tempo real da atividade do IRIS a partir do código Java.
• Simplifica a análise de performance e otimização de consultas para desenvolvedores.
• Útil para benchmarking, profiling e testes de regressão do sistema.
• Pode servir como um registro leve de auditoria de performance para operações críticas.

6. Exemplo Prático de Uso

O código-fonte completo e o setup de deployment estão disponíveis em:

• Open Exchange: https://openexchange.intersystems.com/package/quarkus-iris-monitor-system
• Repositório GitHub: https://github.com/Davi-Massaru/quarkus-iris-monitor-system

6.1 Visão Geral

A aplicação roda um servidor Quarkus conectado a uma instância InterSystems IRIS configurada com o namespace FHIRSERVER.
A camada ORM é implementada usando Hibernate ORM com PanacheRepository, permitindo mapeamento direto entre entidades Java e classes do banco IRIS.

Quando a aplicação é iniciada (via docker-compose up), são iniciados:

• O container IRIS, hospedando o modelo de dados FHIR e rotinas ObjectScript (incluindo AdapterPerfmonProc);
• O container Quarkus, expondo endpoints REST e conectando-se ao IRIS via driver JDBC nativo.

6.2 Endpoint REST

Um recurso REST expõe um endpoint simples para recuperar informações de pacientes:

@Path("/patient")
public class PatientResource {

    @Inject
    PatientService patientService;

    @GET
    @Path("/info")
    @Produces(MediaType.APPLICATION_JSON)
    public PatientInfoDTO searchPatientInfo(@QueryParam("key") String key) {
        return patientService.patientGetInfo(key);
    }
}

Este endpoint aceita um parâmetro de consulta (key) que identifica o recurso do paciente dentro do repositório de dados FHIR.

6.3 Camada de Serviço com @PerfmonReport

A classe PatientService contém a lógica de negócio para recuperar e compor informações do paciente.
Ela é anotada com @PerfmonReport, o que significa que cada requisição para /patient/info aciona o monitoramento de performance do IRIS:

@ApplicationScoped
public class PatientService {

    @Inject
    PatientRepository patientRepository;

    @PerfmonReport
    public PatientInfoDTO patientGetInfo(String patientKey) {

        Optional<Patient> patientOpt = patientRepository.find("key", patientKey).firstResultOptional();
        Patient patient = patientOpt.orElseThrow(() -> new IllegalArgumentException("Patient not found"));

        PatientInfoDTO dto = new PatientInfoDTO();
        dto.setKey(patient.key);
        dto.setName(patient.name);
        dto.setAddress(patient.address);
        dto.setBirthDate(patient.birthDate != null ? patient.birthDate.toString() : null);
        dto.setGender(patient.gender);
        dto.setMedications(patientRepository.findMedicationTextByPatient(patientKey));
        dto.setConditions(patientRepository.findConditionsByPatient(patientKey));
        dto.setAllergies(patientRepository.findAllergyByPatient(patientKey));

        return dto;
    }
}

6.4 Fluxo de Execução

Uma requisição é feita para: GET /patient/info?key=Patient/4

O Quarkus encaminha a requisição para PatientResource.searchPatientInfo().

O interceptor CDI detecta a anotação @PerfmonReport em PatientService.patientGetInfo().

Antes de executar a lógica de serviço:

• O interceptor invoca MonitorSystem.startPerfmon(), que chama a classe IRIS iris.src.dc.AdapterPerfmonProc.start().

• O método executa a lógica de negócio, consultando dados do paciente usando os mapeamentos Hibernate PanacheRepository.

Após a conclusão do método:

• MonitorSystem.generateReportPerfmon() é chamado para criar o relatório de performance.

• MonitorSystem.stopPerfmon() interrompe o monitoramento de performance do IRIS.

Um relatório .txt é gerado em: usr/irissys/mgr/Temp/

Exemplo de nome de arquivo: PatientService_patientGetInfo_20251005_161906.txt

6.5 Resultado

O relatório gerado contém estatísticas detalhadas de execução do IRIS, por exemplo:

                         Routine Activity by Routine

Started: 10/11/2025 05:07:30PM                    Collected: 10/11/2025 05:07:31PM

Routine Name                        RtnLines  % Lines   RtnLoads  RtnFetch  Line/Load Directory
----------------------------------- --------- --------- --------- --------- --------- ---------
Other                                     0.0       0.0       0.0       0.0         0
PERFMON                                  44.0       0.0       0.0       0.0         0 /usr/irissys/mgr/
%occLibrary                         3415047.0      34.1   48278.0       0.0      70.7 /usr/irissys/mgr/irislib/
iris.src.dc.AdapterPerfmonProc.1          7.0       0.0       2.0       0.0       3.5 /usr/irissys/mgr/FHIRSERVER/
%occName                            5079994.0      50.7       0.0       0.0         0 /usr/irissys/mgr/irislib/
%apiDDL2                            1078497.0      10.8   63358.0       0.0      17.0 /usr/irissys/mgr/irislib/
%SQL.FeatureGetter.1                 446710.0       4.5   66939.0       0.0       6.7 /usr/irissys/mgr/irislib/
%SYS.WorkQueueMgr                       365.0       0.0       1.0       0.0     365.0 /usr/irissys/mgr/
%CSP.Daemon.1                            16.0       0.0       1.0       0.0      16.0 /usr/irissys/mgr/irislib/
%SYS.TokenAuth.1                         14.0       0.0       5.0       0.0       2.8 /usr/irissys/mgr/
%Library.PosixTime.1                      2.0       0.0       0.0       0.0         0 /usr/irissys/mgr/irislib/
%SYS.sqlcq.uEXTg3QR7a7I7Osf9e8Bz...      52.0       0.0       1.0       0.0      52.0 /usr/irissys/mgr/
%SYS.SQLSRV                              16.0       0.0       0.0       0.0         0 /usr/irissys/mgr/
%apiOBJ                                 756.0       0.0       0.0       0.0         0 /usr/irissys/mgr/irislib/
FT.Collector.1                            0.0       0.0       0.0       0.0         0 /usr/irissys/mgr/
SYS.Monitor.FeatureTrackerSensor.1        0.0       0.0       0.0       0.0         0 /usr/irissys/mgr/
%SYS.Monitor.Control.1                    0.0       0.0       0.0       0.0         0 /usr/irissys/mgr/
%SYS.DBSRV.1                            252.0       0.0       4.0       0.0      63.0 /usr/irissys/mgr/
%sqlcq.FHIRSERVER.cls12.1                19.0       0.0       0.0       0.0         0 /usr/irissys/mgr/irislocaldata/
%sqlcq.FHIRSERVER.cls13.1                74.0       0.0       0.0       0.0         0 /usr/irissys/mgr/irislocaldata/
%sqlcq.FHIRSERVER.cls14.1                74.0       0.0       0.0       0.0         0 /usr/irissys/mgr/irislocaldata/
%sqlcq.FHIRSERVER.cls15.1                52.0       0.0       0.0       0.0         0 /usr/irissys/mgr/irislocaldata/
%SYS.System.1                             1.0       0.0       0.0       0.0         0 /usr/irissys/mgr/

Esses dados fornecem uma visão precisa sobre quais rotinas foram executadas internamente pelo IRIS durante aquela chamada REST — incluindo compilação de SQL, execução e acesso a dados FHIR.

Observação: As rotinas %sqlcq.FHIRSERVER.* registram todas as consultas SQL cache executadas pelo Quarkus dentro do método. Monitorar essas rotinas permite aos desenvolvedores analisar a execução das queries, compreender o comportamento do código e identificar possíveis gargalos de performance. Isso as torna uma ferramenta poderosa para desenvolvimento e depuração de operações relacionadas ao FHIR.

6.6 Resumo

Este exemplo demonstra como um serviço padrão Quarkus pode utilizar de forma transparente as ferramentas nativas de monitoramento do IRIS usando a anotação @PerfmonReport.
Ele combina:

• Interceptadores CDI (Quarkus)
• Hibernate PanacheRepositories (ORM)
• Rotinas ObjectScript nativas do IRIS (^PERFMON)

O resultado é um mecanismo de profiling de performance totalmente automatizado e reproduzível, que pode ser aplicado a qualquer método de serviço na aplicação.

Oi pessoal!  Esse artigo é para quem está começando com InterSystems IRIS. Espero que ajude!

O InterSystems IRIS é uma plataforma de dados unificada: uma base de dados de alta performance com ferramentas de interoperabilidade e análise integradas em um só produto. Você tem SQL e NoSQL na mesma máquina, além de jeitos nativos de rodar Python com seus dados. Em resumo: menos peças móveis, mais capacidade de processamento.

Por que engenheiros escolhem IRIS

Uma coisa que aprendi ao longo dos anos é que, não importa o quão aprimorada seja a lógica do seu aplicativo, o desempenho do banco de dados acabará por determinar o sucesso ou fracasso da experiência do usuário. Trabalhando com o InterSystems IRIS, recentemente vivenciei isso em primeira mão. Um de nossos clientes estava construindo um painel de relatórios que funcionava perfeitamente durante os testes, mas assim que o conjunto de dados de produção cresceu para milhões, os tempos de resposta ficaram extremamente lentos.

##Introdução

MonLBL é uma ferramenta para analisar o desempenho da execução de código ObjectScript linha por linha. codemonitor.MonLBL é um wrapper baseado no pacote %Monitor.System.LineByLinedo InterSystems IRIS, projetado para coletar métricas precisas sobre a execução de rotinas, classes ou páginas CSP.

O wrapper e todos os exemplos apresentados neste artigo estão disponíveis no seguinte repositório do GitHub: iris-monlbl-example

Funcionalidades

A ferramenta permite a coleta de diversos tipos de métricas:

• RtnLine: Número de execuções da linha
• GloRef: Número de referências a globais geradas pela linha
• Time: Tempo de execução da linha
• TotalTime: Tempo de execução total, incluindo sub-rotinas chamadas

Todas as métricas são exportadas para arquivos CSV.

Além das métricas linha a linha, dc.codemonitor.MonLBL coleta estatísticas de globais:

• Tempo total de execução
• Número total de linhas executadas
• Número total de referências a globais -T empo de CPU do sistema e do usuário
  • O tempo de CPU do usuário corresponde ao tempo gasto pelo processador executando o código da aplicação.
  • O tempo de CPU do sistema corresponde ao tempo gasto pelo processador executando operações do sistema operacional (chamadas de sistema, gerenciamento de memória, E/S). -Tempo de leitura do disco.

Pré-requisitos

Para monitorar o código com MonLBL:

1. Obtenha a classe dc.codemonitor.MonLBL (disponível aqui)
2. As rotinas ou classes a serem analisadas devem ser compiladas com as flags "ck".

⚠️ Aviso Importante

O uso do monitoramento linha a linha impacta o desempenho do servidor. É importante seguir estas recomendações:

• Use esta ferramenta apenas em um conjunto limitado de código e processos (idealmente para execução única em um terminal).
• Evite usá-la em um servidor de produção (mas, às vezes, é necessário).
• Prefira usar esta ferramenta em um ambiente de desenvolvimento ou teste.

Essas precauções são essenciais para evitar problemas de desempenho que possam afetar usuários ou sistemas de produção. Observe que o código monitorado é executado aproximadamente 15-20% mais lentamente do que o código não monitorado.

Uso

Exemplo Básico

// Cria uma instância de MonLBL
Set mon = ##class(dc.codemonitor.MonLBL).%New()

//Define as rotinas a serem monitoradas
Set mon.routines = $ListBuild("User.MyClass.1")

// Começa o monitoramento
Do mon.startMonitoring()

// Código a analisar
// ...

// Para o monitoramento e gera resultados
Do mon.stopMonitoring()

Nota: O monitoramento iniciado aqui é válido apenas para o processo atual. Outros processos que executam o mesmo código não serão incluídos nas medições.

Opções de Configuração

O wrapper oferece várias opções configuráveis:

• directory:Diretório onde os arquivos CSV serão exportados (o padrão é o diretório Temp do IRIS).
• autoCompile: Recompila automaticamente as rotinas com as flags "ck" se necessário.
• metrics: Lista personalizável de métricas a serem coletadas.
• decimalPointIsComma: Usa uma vírgula como separador decimal para melhor compatibilidade com o Excel (dependendo do seu ambiente local).
• metricsEnabled:Habilita ou desabilita a coleta de métricas linha a linha.

Exemplo de Uso Avançado

Aqui está um exemplo mais completo (disponível na classe dc.codemonitor.Example):

ClassMethod MonitorGenerateNumber(parameters As %DynamicObject) As %Status
{
    Set sc = $$$OK
    Try {
        // Exibe parâmetros recebidos
        Write "* Parameters:", !
        Set formatter = ##class(%JSON.Formatter).%New()
        Do formatter.Format(parameters)
        Write !
        
        // Cria e configura o monitor
        Set monitor = ##class(dc.codemonitor.MonLBL).%New()
        
        // AVISO: Em produção, defina o autoCompile para $$$NO
        // e manualmente compile o código a monitorar
        Set monitor.autoCompile = $$$YES
        Set monitor.metricsEnabled = $$$YES
        Set monitor.directory = ##class(%File).NormalizeDirectory(##class(%SYS.System).TempDirectory())
        Set monitor.decimalPointIsComma = $$$YES

        // Configure a rotina para o monitor (formato "int" da classe)
        // Para achar o nome exato da rotina, use o comando:
        // Do $SYSTEM.OBJ.Compile("dc.codemonitor.DoSomething","ck")
        // A linha "Compiling routine XXX" deve exibir o nome da rotina
        Set monitor.routines = $ListBuild("dc.codemonitor.DoSomething.1")

        // Comece a monitorar
        $$$TOE(sc, monitor.startMonitoring())
        
        // Execute o código a monitorar com tratamento de erro
        Try {
            Do ##class(dc.codemonitor.DoSomething).GenerateNumber(parameters.Number)

            // Importante: Sempre pare o monitoramento
            Do monitor.stopMonitoring()
        }
        Catch ex {
            // Pare o monitoramento mesmo em caso de erro
            Do monitor.stopMonitoring()
            Throw ex
        }
    }
    Catch ex {
        Set sc = ex.AsStatus()
        Do $SYSTEM.Status.DisplayError(sc)
    }

    Return sc
}

Este exemplo demonstra várias melhores práticas importantes:

• Uso de um bloco Try/Catch para tratamento de erros.
• Interrupção sistemática do monitoramento, mesmo em caso de erro.
• Configuração completa do monitor.

Exemplo com Páginas CSP

O MonLBL também permite o monitoramento de páginas CSP. Aqui está um exemplo (também disponível na classedc.codemonitor.ExampleCsp):

ClassMethod MonitorCSP(parameters As %DynamicObject = {{}}) As %Status
{
    Set sc = $$$OK
    Try {
        // Exibe parâmetros recebidos
        Write "* Parameters:", !
        Set formatter = ##class(%JSON.Formatter).%New()
        Do formatter.Format(parameters)
        Write !
        
        // Cria e configura o monitor
        Set monitor = ##class(dc.codemonitor.MonLBL).%New()
        Set monitor.autoCompile = $$$YES
        Set monitor.metricsEnabled = $$$YES
        Set monitor.directory = ##class(%File).NormalizeDirectory(##class(%SYS.System).TempDirectory())
        Set monitor.decimalPointIsComma = $$$YES

        // Para monitorar uma página CSP, use a rotina gerada
        // Exemplo: /csp/user/menu.csp --> classe: csp.menu --> rotina: csp.menu.1
        Set monitor.routines = $ListBuild("csp.menu.1")

        // Páginas CSP necessitam de objetos %session, %request, e %response
        // Crie esses objetos com os parâmetros necessários
        Set %request = ##class(%CSP.Request).%New()
        // Configure os parâmetros de requisição se necessário
        // Set %request.Data("<param_name>", 1) = <value>
        Set %request.CgiEnvs("SERVER_NAME") = "localhost"
        Set %request.URL = "/csp/user/menu.csp"

        Set %session = ##class(%CSP.Session).%New(1234)
        // Configure os dados da sessão se necessário
        // Set %session.Data("<data_name>", 1) = <value>

        Set %response = ##class(%CSP.Response).%New()
            
        // Comece o monitoramento
        $$$TOE(sc, monitor.startMonitoring())
        
        Try {
            // Para evitar a exibição do conteúdo da página CSP no terminal,
            // use a classe IORedirect para redirecionar sa saída para nula
            // (requere instalação via zpm "install io-redirect")
            Do ##class(IORedirect.Redirect).ToNull() 
            
            // Chame a página CSP via seu método OnPage 
            Do ##class(csp.menu).OnPage()
            
            // Restaure a saída padrão
            Do ##class(IORedirect.Redirect).RestoreIO()

            // Pare o monitoramento
            Do monitor.stopMonitoring()
        }
        Catch ex {
            // Sempre restaure a saída e pare o monitoramento no caso de erro
            Do ##class(IORedirect.Redirect).RestoreIO()
            Do monitor.stopMonitoring()
           
            Throw ex
        }
    }
    Catch ex {
        Set sc = ex.AsStatus()
        Do $SYSTEM.Status.DisplayError(sc)
    }

    Return sc
}

Pontos chave para monitorar páginas CSP:

1. Identificação da Rotina: Uma página CSP é compilada em uma classe e uma rotina. Por exemplo/csp/user/menu.csp gera a classe csp.menu e a rotina csp.menu.1.

2. **Ambiente CSP **:É necessário criar objetos de contexto CSP (%request, %session, %response) para que a página seja executada corretamente.

3. Redirecionamento de Saída:: Para evitar a exibição de conteúdo HTML no terminal, você pode usar a ferramenta IORedirect (disponível no OpenExchange via zpm "install io-redirect").

4. Chamada da Página: A execução é feita através do método OnPage() da classe gerada.

##Exemplo de Saída

Aqui está um exemplo da saída obtida ao executar o método MonitorGenerateNumber:

USER>d ##class(dc.codemonitor.Example).MonitorGenerateNumber({"number":"100"})
* Parameters:
{
  "number":"100"
}

* Metrics are exported to /usr/irissys/mgr/Temp/dc.codemonitor.DoSomething.1.csv
* Perf results:
{
  "startDateTime":"2025-05-07 18:45:42",
  "systemCPUTime":0,
  "userCPUTime":0,
  "timing":0.000205,
  "lines":19,
  "gloRefs":14,
  "diskReadInMs":"0"
}

Nesta saída, podemos observar:

1.Exibição dos parâmetros de entrada. 2. Confirmação de que as métricas foram exportadas para um arquivo CSV. 3.Um resumo do desempenho global em formato JSON, incluindo:

• Data e hora de início
• Tempo de CPU do sistema e do usuário
• Tempo total de execução
• Número de linhas executadas
• Número de referências a globais
• Tempo de leitura do disco

Interpretando os Resultados CSV

Após a execução, arquivos CSV (um por rotina na lista de rotinas $ListBuild) são gerados no diretório configurado. Esses arquivos contêm: -Número da linha -Métricas coletadas para cada linha

• Código-fonte da linha (nota: se você não compilou com a flag "k", o código-fonte não estará disponível no arquivo CSV)

Aqui está um exemplo do conteúdo de um arquivo CSV exportado: (dc.codemonitor.DoSomething.1.csv):

Nesta tabela, podemos analisar:

• RtnLine: Indica quantas vezes cada linha foi executada (aqui, as linhas 6 e 10 foram executadas uma vez)
• GloRef: Mostra as referências globais geradas por cada linha
• Time: Apresenta o tempo de execução específico de cada linha
• TotalTime: Exibe o tempo total, incluindo chamadas para outras rotinas

Esses dados podem ser facilmente importados para uma planilha para uma análise aprofundada. As linhas que mais consomem recursos em termos de tempo ou acesso a dados podem, assim, ser facilmente identificadas.

Observação sobre a Eficiência do Cache

A eficiência do cache do banco de dados (buffer global) pode mascarar problemas reais de desempenho. Durante a análise, o acesso aos dados pode parecer rápido devido a esse cache, mas pode ser muito mais lento em certas condições de uso no mundo real.

Em sistemas de desenvolvimento, você pode limpar o cache entre as medições com o seguinte comando:

Do ClearBuffers^|"%SYS"|GLOBUFF()

⚠️ ATENÇÃO: Tenha cuidado com este comando, pois ele se aplica a todo o sistema. Nunca o utilize em um ambiente de produção, já que pode impactar o desempenho de todas as aplicações em execução.

Conclusão

O monitoramento linha a linha é uma ferramenta valiosa para analisar o desempenho do código ObjectScript. Ao identificar precisamente as linhas de código que consomem mais recursos, ele permite que os desenvolvedores economizem um tempo significativo na análise de gargalos de desempenho.

Introdução

O desempenho do banco de dados tornou-se um fator crítico de sucesso em um ambiente de aplicações moderno. Portanto, identificar e otimizar as consultas SQL que consomem mais recursos é essencial para garantir uma experiência de usuário fluida e manter a estabilidade da aplicação.

Este artigo explorará uma abordagem rápida para analisar as estatísticas de execução de consultas SQL em uma instância InterSystems IRIS para identificar áreas de otimização dentro de uma macro-aplicação.

Em vez de focar no monitoramento em tempo real, configuraremos um sistema que coleta e analisa estatísticas pré-calculadas pelo IRIS uma vez por hora. Essa abordagem, embora não permita o monitoramento instantâneo, oferece um excelente compromisso entre a riqueza de dados disponíveis e a simplicidade de implementação.

Usaremos o Grafana para visualização e análise de dados, o InfluxDB para armazenamento de séries temporais e o Telegraf para coleta de métricas. Essas ferramentas, reconhecidas por seu poder e flexibilidade, nos permitirão obter uma visão clara e explorável.

Mais especificamente, detalharemos a configuração do Telegraf para recuperar estatísticas. Também configuraremos a integração com o InfluxDB para armazenamento e análise de dados, e criaremos dashboards personalizados no Grafana. Isso nos ajudará a identificar rapidamente as consultas que exigem atenção especial.

Para facilitar a orquestração e o deploy desses vários componentes, empregaremos o Docker.

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...."

Então, HCI é uma coisa única?

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.

Então, o que é HCI novamente?

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.

Características comuns do HCI

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:

• VMware vSAN requer VMware vSphere e está disponível em hardware de vários fornecedores. Existem muitas opções de hardware disponíveis, mas estas são estritamente dependentes da Lista de Compatibilidade de Hardware (HCL) do vSAN da VMware. As soluções podem ser compradas pré-embaladas e pré-configuradas, por exemplo, EMC VxRail, ou você pode comprar componentes na HCL e construir o seu próprio.
• Nutanix também pode ser comprado e implantado como uma solução completa, incluindo hardware em blocos pré-configurados com até quatro nós em um appliance 2U. A solução Nutanix também está disponível como uma solução de software para construir o seu próprio, validada no hardware de outros fornecedores.

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:

• Máquinas Virtuais (VMs) são executadas em hypervisors como VMware ESXi, mas também outros, incluindo Hyper-V ou Nutanix Acropolis Hypervisor (AHV). O Nutanix também pode ser implantado usando o ESXi.
• Os servidores host são frequentemente combinados em blocos de computação, armazenamento e rede. Por exemplo, um Appliance 2U com quatro nós.
• Vários servidores host são combinados em um cluster para gerenciamento e disponibilidade.
• O armazenamento é em camadas, totalmente flash ou híbrido com uma camada de cache flash mais discos rígidos como camada de capacidade.
• O armazenamento é apresentado como um pool definido por software, incluindo posicionamento de dados e políticas de capacidade, desempenho e disponibilidade.
• A capacidade e o desempenho de E/S são escalados adicionando hosts ao cluster.
• Os dados são gravados no armazenamento em vários nós do cluster de forma síncrona, para que o cluster possa tolerar falhas de host ou componente sem perda de dados.
• A disponibilidade e o balanceamento de carga da VM são fornecidos pelo hypervisor, por exemplo, vMotion, VMware HA e DRS.

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.

vCPU e memória da VM

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.

Planejamento da capacidade de armazenamento

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é.

Modelo de armazenamento vSAN

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.

• Codificação de apagamento (RAID-5 ou RAID-6) para economia de espaço.
• Faixas de disco (disk stripes) para desempenho.
• Provisionamento de disco espesso (thick) ou fino (thin) (fino por padrão no vSAN).
• Outros...

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.

Camadas de armazenamento e planejamento de desempenho de E/S (IO)

Para garantir alto desempenho, existem duas camadas de armazenamento:

• Camada de cache - Deve ser flash de alta resistência.
• Camada de capacidade - Flash ou, para usos híbridos, discos rígidos (spinning disks).

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.

• Recomendação:_ Para melhor desempenho e menor TCO, considere 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.

• Recomendação:_ Se possível, escolha SSDs NVMe para a camada de cache, embora SAS ainda seja adequado.
• Recomendação:_ Escolha dispositivos flash de alta resistência na camada de cache para lidar com alto I/O..

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.

• Recomendação:_ Escolha SSDs SATA de alta capacidade para a camada de capacidade.
• Recomendação:_ Escolha SSDs empresariais com 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.

• Recomendação:_ Fique atento a novas tecnologias a serem incluídas, como o 3D Xpoint, para as camadas de cache E capacidade.

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:

• Desempenho: Ter vários dispositivos flash nas camadas aumentará os IOPS disponíveis por host.
• Domínio de falha: A falha de um disco de cache afeta todo o grupo de discos, embora a disponibilidade seja mantida, pois o vSAN reconstrói automaticamente.

Você terá que equilibrar disponibilidade, desempenho e capacidade, mas, em geral, ter vários grupos de discos por host é um bom equilíbrio.

• **Recomendação:_**Revise os requisitos de armazenamento, considere vários grupos de discos por host.

Qual desempenho devo esperar?

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!

Planejamento de capacidade e desempenho

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.

Deduplicação e Compressão

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.

• Recomendação:_ Para implementações de banco de dados, não habilite a compactação e a deduplicação.

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.

• Failover em segundos (mais rápido do que reiniciar uma VM, depois o sistema operacional e, em seguida, recuperar o Caché). -Failover em caso de falha do aplicativo/Caché (não detectada pelo VMware).

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.

Criptografia

Outra consideração é onde você escolhe criptografar os dados em repouso. Você tem várias opções na pilha de E/S, incluindo;

• Usando a criptografia do banco de dados Caché (criptografa apenas o banco de dados).
• No armazenamento (por exemplo, criptografia de disco de hardware no SSD).

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.

• Recomendação:_ Criptografe na camada mais baixa possível na pilha de E/S para um nível mínimo de criptografia. No entanto, quanto mais risco você deseja proteger, mova-se mais alto na pilha.

Falhas a tolerar (FTT)

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.

• Recomendação:_ Um cluster vSAN deve ter um mínimo de quatro hosts para disponibilidade.

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.

Codificação de Apagamento

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.

• Recomendação:_ Para bancos de dados de produção, não habilite a codificação de apagamento (erasure coding). Habilite apenas para ambientes de não produção.

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.

• Recomendação:_ Considere o custo de hosts adicionais antes de planejar a configuração da codificação de apagamento.

Striping (Distribuição de Dados)

A distribuição de dados (striping) oferece oportunidades para melhorias de desempenho, mas provavelmente só ajudará com configurações híbridas.

• Recomendação:_ Para bases de dados de produção, não habilite o striping.

Reserva de Espaço de Objeto (provisionamento fino ou espesso)

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.

• Recomendação:_ Para discos de banco de dados de produção, use reserva de 100%.
• **Recomendação:_**Para instâncias de não produção, deixe o armazenamento com provisionamento fino.

Quando devo ativar os recursos?

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.

• Recomendação:_ Dedique tempo antecipadamente para entender e configurar recursos e funcionalidades de armazenamento, como deduplicação e compressão, antes da entrada em produção e definitivamente antes que grandes bancos de dados sejam carregados.

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.

• Recomendação:_ Existem muitos recursos e permutações. Calcule seus requisitos totais de capacidade em GB como ponto de partida, revise as recomendações neste post [e com o fornecedor do seu aplicativo] e, em seguida, converse com seu fornecedor de HCI.

Sobrecarga de processamento de armazenamento

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.

• Recomendação:_ Planeje para o pior caso de 10% de utilização da CPU e, em seguida, monitore sua carga de trabalho real.

Rede

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.

• Recomendação:_ Largura de banda de rede comutada de 10GbE mínima para tráfego de armazenamento. NICs múltiplos por host, conforme as melhores práticas.

#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.

Armazenamento hoje e amanhã

Vamos revisar as capacidades das soluções de armazenamento comumente implantadas e garantir que estamos claros com a terminologia.

Disco rígido

• Velho conhecido. Discos rígidos (HDD) de 7.2, 10K ou 15K com interface SAS ou SATA. Baixo IOPS por disco. Podem ter alta capacidade, mas isso significa que os IOPS por GB estão diminuindo. Para desempenho, os dados são normalmente distribuídos em vários discos para alcançar "IOPS suficientes" com alta capacidade.

Disco SSD - SATA e SAS

• Hoje, o flash é geralmente implantado como SSDs com interface SAS ou SATA usando flash NAND. Também há alguma DRAM no SSD como um buffer de gravação. SSDs empresariais incluem proteção contra perda de energia - em caso de falha de energia, o conteúdo da DRAM é descarregado para a NAND.

Disco SSD - NVMe

• Semelhante ao disco SSD, mas usa o protocolo NVMe (não SAS ou SATA) com flash NAND. A mídia NVMe se conecta via barramento PCI Express (PCIe), permitindo que o sistema se comunique diretamente, sem a sobrecarga de adaptadores de barramento de host e estruturas de armazenamento, resultando em latência muito menor.

Array de Armazenamento

• Arrays Empresariais fornecem proteção e a capacidade de escalar. Hoje em dia, é mais comum que o armazenamento seja um array híbrido ou totalmente flash. Arrays híbridos têm uma camada de cache de flash NAND mais uma ou mais camadas de capacidade usando discos rígidos de 7.2, 10K ou 15K. Arrays NVMe também estão se tornando disponíveis.

NVDIMM de Modo Bloco

• Esses dispositivos estão sendo enviados hoje e são usados quando latências extremamente baixas são necessárias. NVDIMMs são instalados em um socket de memória DDR e fornecem latências em torno de 30ns. Hoje, eles são enviados em módulos de 8GB, portanto, provavelmente não serão usados para aplicativos de banco de dados legados, mas novos aplicativos de scale-out podem aproveitar esse desempenho.

3D XPoint

Esta é uma tecnologia futura - não disponível em novembro de 2016.

• Desenvolvido pela Micron e Intel. Também conhecido como Optane (Intel) e QuantX (Micron).
• Não estará disponível até pelo menos 2017, mas, comparado ao NAND, promete maior capacidade, >10x mais IOPS, >10x menor latência com resistência extremamente alta e desempenho consistente.
• A primeira disponibilidade usará o protocolo NVMe.

Resistência do Dispositivo SSD

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.

Resumo

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.

Plataformas de Dados e Desempenho da InterSystems - Parte 5: Monitoramento com SNMP

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.

Posts anteriores desta série:

• Plataformas de Dados InterSystems e desempenho - Parte 1
• Plataformas de Dados InterSystems e desempenho - Parte 2
• Parte 3 - Foco na CPU
• Parte 4 - Análise da memória

Comece aqui...

Comece revisando "Monitorando o Caché Usando SNMP" na documentação online do Caché..

1. Configuração 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!

2. Configuração do sistema operacional

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

3. Configure o snmpd

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.

4. Testando o acesso MIB

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.

Incluindo em Ferramentas de Monitoramento

É 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.

Fluxo de trabalho de exemplo - adicionando o MIB do Caché à ferramenta de monitoramento.

Passo 1.

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é.

Passo 2.

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.

Resumo

Existem muitas ferramentas de monitoramento, alerta e algumas ferramentas de análise muito inteligentes disponíveis, algumas gratuitas, outras com licenças para suporte e muitas funcionalidades variadas.

Você deve monitorar seu sistema e entender qual atividade é normal e qual atividade foge do normal e deve ser investigada. SNMP é uma maneira simples de expor métricas do Caché e do Ensemble.

A InterSystems está na vanguarda da tecnologia de bancos de dados desde sua criação, sendo pioneira em inovações que consistentemente superam concorrentes como Oracle, IBM e Microsoft. Ao se concentrar em um design de kernel eficiente e adotar uma abordagem intransigente em relação ao desempenho de dados, a InterSystems criou um nicho em aplicações de missão crítica, garantindo confiabilidade, velocidade e escalabilidade.

A História de Excelência Técnica

Olá pessoal, tudo bem?

Estou enfrentando problemas na replicação de dados do meu Caché 2016 para um banco PostgreSQL. Preciso lidar com cerca de 300 atualizações de dados por minuto, e, sempre que determinadas tabelas sofrem alterações, essas mudanças precisam ser refletidas em outras bases de dados.

Até o momento, já tentei várias abordagens, como:

• Configurar uma API intermediária,
• Utilizar o Azure Service Bus,
• Usar Jobs do Caché,
• E todas elas têm como ponto de entrada as triggers das minhas tabelas.

Há três coisas mais importantes para qualquer converrsa sobre performance SQL: Índices, TuneTable e Plano de Consulta.  Os PDFs anexos incluem apresentações históricas sobre esses tópicos que cobrem os fundamentos desses 3 itens em um só lugar.  Nossa documentação fornece mais detalhes sobre esses e outros tópicos de desempenho do SQL nos links abaixo.  As opções de eLearning reforçam vários desses tópicos.  Além disso, há vários artigos da Comunidade de Desenvolvedores que abordam o desempenho do SQL, e os links relevantes também estão listados.

Há uma quantidade considerável de repetição nas informações listadas abaixo. Os aspectos mais importantes do desempenho do SQL a serem considerados são:

1. Os tipos de índices disponíveis
2. O uso de um tipo de índice em vez de outro
3. As informações que o TuneTable coleta para uma tabela e o que isso significa para o Otimizador
4. Como ler um Plano de Execução para melhor entender se uma consulta é boa ou ruim

Recentemente, disponibilizamos uma nova versão do InterSystems IRIS no Vector Search Early Access Program, apresentando um novo índice Approximate Nearest Neighbor baseado no algoritmo de indexação Hierarchical Navigable Small World (HNSW). Essa adição permite pesquisas altamente eficientes e aproximadas de vizinhos mais próximos em grandes conjuntos de dados vetoriais, melhorando drasticamente o desempenho e a escalabilidade da consulta.

Então, se você está acompanhando do post anterior ou entrando agora, vamos passar para o mundo dos aplicativos eBPF e dar uma olhada no Parca, que se baseia em nossa breve investigação de gargalos de desempenho usando eBPF, mas coloca um aplicativo incrível no topo do seu cluster para monitorar todas as suas cargas de trabalho iris, continuamente, em todo o cluster!

Perfilamento Contínuo com Parca, Cargas de Trabalho IRIS em Todo o Cluster

Eu estive na Cloud Native Security Con em Seattle com total intenção de entrar no dia de OTEL, então lendo o assunto de segurança aplicada a fluxos de trabalho Cloud Native nos dias seguintes até CTF como um exercício profissional. Isso foi felizmente finalizado por um novo entendimento de eBPF, que tem minhas telas, carreira, fluxos de trabalho e atitude com muita necessidade de uma melhoria com novas abordagens para resolver problemas de fluxo de trabalho.

Então, consegui chegar à festa do eBPF e desde então tenho participado de clínica após clínica sobre o assunto. Aqui, gostaria de "desempacotar" o eBPF como uma solução técnica, mapeada diretamente para o que fazemos na prática (mesmo que esteja um pouco fora), e passar pelo eBPF através da minha experimentação em suporte a cargas de trabalho InterSystems IRIS, particularmente no Kubernetes, mas não necessariamente vazio em cargas de trabalho autônomas.

Passos eBee com eBPF e fluxos de trabalho InterSystems IRIS

Faz bastante tempo desde a última vez que escrevi uma postagem de atualização do IoP.

Então, o que há de novo desde o lançamento da interface de linha de comando IoP?

Dois novos grandes recursos foram adicionados ao IoP:

• Rebranding: o módulogrongier.pex foi renomeado para iop para refletir o novo nome do projeto.
• suporte Async: IoP agora suporta funções assíncronas e co-rotinas.

Rebranding

O módulo grongier.pex foi renomeado para iop para refletir o novo nome do projeto.

O módulo grongier.pex ainda está disponível para compatibilidade retroativa, mas será removido no futuro.

suporte Async

O IoP suporta chamadas assíncronas há um bom tempo, mas não era possível usar funções e co-rotinas assíncronas diretamente nele.

Antes de pular dentro desse novo recurso, vou explicar como chamadas assíncronas funcionam no InterSystems IRIS e apresentar dois exemplos de como usar chamadas assíncronas IoP.

Chamadas async legado

Vamos ver como chamadas async legado funcionam:

from iop import BusinessProcess
from msg import MyMessage


class MyBP(BusinessProcess):

    def on_message(self, request):
        msg_one = MyMessage(message="Message1")
        msg_two = MyMessage(message="Message2")

        self.send_request_async("Python.MyBO", msg_one,completion_key="1")
        self.send_request_async("Python.MyBO", msg_two,completion_key="2")

    def on_response(self, request, response, call_request, call_response, completion_key):
        if completion_key == "1":
            self.response_one = call_response
        elif completion_key == "2":
            self.response_two = call_response

    def on_complete(self, request, response):
        self.log_info(f"Received response one: {self.response_one.message}")
        self.log_info(f"Received response two: {self.response_two.message}")

Basicamente elas funcionam da mesma maneira que chamadas async funcionam em IRIS. O método send_request_async envia uma requisição ao Business Operation e o método on_response é chamado quando a resposta é recebida.

Você pode distinguir as respostas pelo parâmetro completion_key

Enviar múltiplas requisições síncronas

Não é exatamente um novo recurso, mas vale a pena mencionar que você pode mandar múltiplas requisições síncronas em paralelo:

from iop import BusinessProcess
from msg import MyMessage


class MyMultiBP(BusinessProcess):

    def on_message(self, request):
        msg_one = MyMessage(message="Message1")
        msg_two = MyMessage(message="Message2")

        tuple_responses = self.send_multi_request_sync([("Python.MyMultiBO", msg_one),
                                                        ("Python.MyMultiBO", msg_two)])

        self.log_info("All requests have been processed")
        for target,request,response,status in tuple_responses:
            self.log_info(f"Received response: {response.message}")

Aqui estamos mandando duas requisições ao mesmo Business Operation em paralelo.

A resposta é uma tupla com o objetivo, requisição, resposta e status de cada chamada.

É bastante útil quando você precisa enviar múltiplas requisições e não se importa com a ordem das respostas.

Funções Async e co-rotinas

Agora vamos ver como usar funções assíncronas e co-rotinas no IoP:

import asyncio

from iop import BusinessProcess
from msg import MyMessage


class MyAsyncNGBP(BusinessProcess):

    def on_message(self, request):

        results = asyncio.run(self.await_response(request))

        for result in results:
            print(f"Received response: {result.message}")

    async def await_response(self, request):
        msg_one = MyMessage(message="Message1")
        msg_two = MyMessage(message="Message2")

        # use asyncio.gather to send multiple requests asynchronously
        # using the send_request_async_ng method
        tasks = [self.send_request_async_ng("Python.MyAsyncNGBO", msg_one),
                 self.send_request_async_ng("Python.MyAsyncNGBO", msg_two)]

        return await asyncio.gather(*tasks)

Neste exemplo, estamos enviando múltiplas requisições para o mesmo Business Operation em paralelo usando o método send_request_async_ng.

Se você leu esse post cuidadosamente até este ponto, por favor comente "Boomerang". Isso pode ser um detalhe para você, mas para mim significa muito. Obrigado!

O método await_response é uma co-rotina que envia múltiplas requisições e espera por todas as respostas. Graças a função asyncio.gather`, podemos esperar por todas as respostas serem recebidas em paralelo

Os benefícios das funções e co-rotinas assíncronas são:

• Melhor performance: você pode enviar múltiplas requisições em paralelo.
• Mais fácil de ler e manter: você pode usar a palavra chave await para esperar por respostas.
• Maior flexibilidade: você pode usar o módulo asyncio para criar fluxos de trabalho complexos
• Mais controle: você pode usar o módulo asyncio para lidar com exceções e timeouts.

Conclusão

Quais são as diferenças entre send_request_async, send_multi_request_sync e send_request_async_ng?

• send_request_async: envia uma requisição ao Business Operation e espera a resposta se o método on_response for implementado e o parâmetro completion_key usado
  • benefício: você pode usar chamadas assíncronas da maneira que está acostumado.
  • desvantagem: pode ser difícil de manter se você precisa enviar múltiplas requisições em paralelo.
• send_multi_request_sync: envia múltiplas requisições ao mesmo Business Operation em paralelo e espera por todas as respostas para serem recebidas.
  • benefício: fácil de usar.
  • desvantagem: você pode controlar a ordem das respostas (quero dizer se a lista de respostas não for ordenada)
• send_request_async_ng: envia múltiplas requisições ao mesmo Business Operation em paralelo e espera por todas as respostas.
  • benefício: você pode controlar a ordem das respostas
  • desvantagem: você precisa usar funções e co-rotinas assíncronas.

Feliz multithreading!

Um cliente perguntou recentemente se o IRIS era compatível com o OpenTelemetry, pois queria medir o tempo que os serviços SOAP implementados pelo IRIS levavam para serem concluídos. O cliente já tem diversas outras tecnologias compatíveis com o OpenTelemetry para o tracing de processos.  No momento, o InterSystems IRIS (IRIS) não oferece suporte nativo ao OpenTelemetry.  

É verdade que a plataforma de dados do IRIS tem várias maneiras de capturar, registrar e analisar o desempenho de uma instância em execução. Essas informações não saem do IRIS por outros componentes do OpenTelemetry, como Agentes ou Coletores, em uma arquitetura do OpenTelemetry implementada.  Várias tecnologias já são compatíveis com o OpenTelemetry, que parece estar se tornando um padrão para a Observabilidade.

Embora haja desenvolvimento contínuo para oferecer suporte nativo a esse recurso em versões futuras do IRIS, este artigo explica como, com a ajuda do Embedded Python e das bibliotecas correspondentes do Python,  os desenvolvedores de aplicativos IRIS podem começar a publicar eventos de Trace para seus back-ends do OpenTelemetry com pouco esforço.  Mais importantemente, meu cliente pode começar a adotar algo hoje mesmo. 

Observabilidade. 

A observabilidade geralmente é composta de três aspectos principais:

• Captura de métricas, que é a captura de medidas quantitativas sobre o desempenho e o comportamento de um sistema, parecido com o que o IRIS publica pela /api/monitor/metrics api
• Registros, que envolvem capturar e armazenar informações relevantes geradas por um aplicativo ou sistema, como o que aparece nas saídas de Logs do Sistema ou o arquivo messages.log gerado por instâncias do IRIS.
• Tracing: que envolve o rastreamento do fluxo de uma transação ou solicitação de serviço enquanto se move por vários componentes de uma solução. O tracing distribuído permite que você siga o caminho de uma solicitação em vários serviços, oferecendo uma representação visual de todo o fluxo da transação.

Este artigo e o aplicativo complementar encontrado aqui focam apenas no Tracing de Serviços SOAP.

Nessa implementação, que só usa o IRIS como a tecnologia para gerar telemetria, um trace e um Span raiz são iniciados com a inicialização do Serviço SOAP.

Abordagem de implementação:

Transforme a classe %SOAP.WebService do IRIS com a lógica de implementação do OpenTelemetry e as funções das bibliotecas Python em uma nova classe chamada SOAP.WebService. Inclua Macros que possam ser usados no código do usuário para contribuir mais com a observabilidade e o tracing. Devem ser necessárias mudanças mínimas na implementação do SOAP (troque o uso de %SOAP.WebService pelo SOAP.WebService como a superclasse de serviço web para implementar o SOAP.
O diagrama abaixo ilustra essa abordagem:

Recursos dessa implementação:

• Por padrão, todo Serviço SOAP será rastreado e relatará informações de traces.
• Quando um Serviço SOAP é usado pela primeira vez, a implementação inicializará um objeto Tracer do OpenTelemetry. Uma combinação do nome do servidor IRIS e instância é fornecida como a origem da telemetria, e a ação SOAP é usada como o nome do span raiz padrão que rastreia o serviço soap.
• Os traces de telemetria e o span padrão serão encerrados automaticamente quando a chamada do método SOAP for finalizada
• Depois da criação, os pares de chave/valor dos atributos podem ser adicionados ao span raiz padrão, como o ID da sessão do CSP ou o número do trabalho
• Os usuários podem usar o $$$OTELLog(...), para adicionar registros manuais a um span, usando uma string simples ou um array de pares chave-valor 
• Os usuários podem usar o $$$OTELPushChildSpan(...)/$$$OTELPopChildSpan(...) para criar spans não raiz em torno de seções do código que desejam identificar de maneira independente com sua lógica

Instalação e teste

• Faça o git pull/clone do repositório em qualquer diretório local

$ git clone https://github.com/pisani/opentelemetry-trace-soap.git

• Abra uma janela de terminal nesse diretório e digite o seguinte para criar as imagens IRIS com código de amostra:

$ docker-compose build

• Depois de criar a imagem iris, no mesmo diretório, digite o seguinte para iniciar os contêineres Jaeger e IRIS:

$ docker-compose up -d

Isso iniciará dois contêineres: o contêiner back-end de destino do OpenTelemetry Jaeger (também expondo uma interface do usuário) e uma instância do IRIS que servirá como o endpoint do servidor dos serviços web SOAP.  Três serviços web simples foram desenvolvidos na instância do IRIS para testar a solução.

• Usando seu navegador, acesse as informações SOAP e páginas de teste por esse URL. Faça login como um superusuário/SYS quando solicitado:

http://localhost:52773/csp/irisapp/SOAP.MyService.cls

(Observação: essas páginas não são ativadas por padrão, e a segurança na instância do IRIS em execução precisa ser relaxada para ativar esse recurso, facilitando o teste)

Selecione cada um dos métodos da web que você quer testar, para gerar a atividade SOAP.  Para ver essa implementação gerar um Erro nos traces observados, use zero (0) como o segundo número no método SOAP Divide(), forçando um erro <DIVDE>.

• Abra outra guia do navegador e acesse a IU do Jaeger pelo seguinte URL

http://localhost:16686

• A página de destino resultante mostra todos os serviços que contribuem para as leituras de telemetria e deve ser parecida com a captura de tela abaixo: 

Conclusão

Resumindo, este artigo mostra como o Embedded Python pode ser usado para adicionar mais recursos ao IRIS, no meu caso, implementar o tracing de Observabilidade para os serviços SOAP.  As opções disponíveis pelo Python e a capacidade do IRIS de aproveitar as bibliotecas Python são vastas.

Reconheço que é possível trabalhar para criar uma classe mais genérica de suporte ao OpenTelemetry que implemente o mesmo para os serviços REST, além de ampliar as assinaturas de Class Method para rastrear o timing de qualquer Class method por esse framework.

[Contexto]

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!

[O que há de novo em relação a outras ferramentas]

Baixe mypButtons.mac no OpenExchange.

• ^mypButtons combina o mgstat e o log de desempenho do Windows em uma linha. Por exemplo, você pode criar um gráfico incluindo "PhyWrs" (mgstat) e "Disk Writes/sec" (Win perfmon) no mesmo período.
• ^mypButtons lê vários arquivos HTML ao mesmo tempo e gera um único arquivo CSV combinado.
• ^mypButtons gera um único arquivo CSV no seu laptop, então é muito mais fácil criar seu gráfico como quiser.
• ^mypButtons gera um CSV e inclui colunas que recomendo muito conferir como o primeiro passo para ver o desempenho do produto da InterSystems. Assim, todo mundo pode aproveitar um gráfico de desempenho com esse utilitário facilmente!

Observação! Se você quiser reproduzir mypButtons.csv, carregue os arquivos HTML SystemPerformance com o perfil "a cada 1 segundo".

[Como executar]

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.

• mgstat.csv
• perfmon.csv
• mypButtons.csv

Aqui, mypButtons.csv inclui as seguintes colunas por padrão, que recomendo muito verificar primeiro para ver o desempenho:

• mgstat: Glorefs, PhyRds, Gloupds, PhyWrs, WDQsz, WDphase
• perfmon: Available MBytes, Disk Reads/sec, Disk Writes/sec, % Processor Time

Esse utilitário funciona para o InterSystems IRIS, InterSystems IRIS for Health, Caché e Ensemble para Windows.

[Etapas de exemplo para criar o gráfico de desempenho do seu servidor IRIS com ^mypButtons]

(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: 3

Observaçã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.

[Editar ^mypButtons para as colunas relatadas]

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 😆

O Subsistema Windows para Linux (WSL) é um recurso do Windows que permite executar um ambiente do Linux na sua máquina do Windows, sem precisar de uma máquina virtual separada ou inicialização dupla. 

O WSL foi projetado para oferecer uma experiência perfeita e produtiva a desenvolvedores que querem usar ambos o Windows e o Linux ao mesmo tempo**.

O WSL 2 é o tipo de distro padrão ao instalar uma distribuição Linux. O WSL 2 usa tecnologia de virtualização para executar um kernel do Linux dentro de uma máquina virtual (VM) utilitária leve. As distribuições Linux são executadas como contêineres isolados dentro da VM gerenciada pelo WSL 2. As distribuições Linux executadas pelo WSL 2 compartilham o mesmo namespace de rede,  árvore de dispositivos (além de /dev/pts), CPU/kernel/memória/swap, binário /init, mas têm o próprio  namespace PID, namespace Montar, namespace de usuário, namespace Cgroup e processo de inicialização.

O WSL 2 melhora o desempenho do sistema de arquivos e adiciona a compatibilidade total de chamadas do sistema em comparação com a arquitetura do WSL 1.

O Docker é uma plataforma aberta para desenvolver, enviar e executar aplicativos. Ele permite que você separe seus aplicativos da sua infraestrutura, para entregar software rapidamente. Com o Docker, você pode gerenciar sua infraestrutura da mesma forma que gerencia seus aplicativos. Ao aproveitar as vantagens das metodologias do Docker para envio, teste e implantação de código, você pode reduzir significativamente o atraso entre a escrita do código e a execução na produção.****

Aqui, vamos aprender a migrar facilmente a imagem do Docker da Community Edition do IRIS para o WSL 2.

Exporte o tar de um contêiner

Abra a linha de comando (Bash) para uma distribuição Linux que você já instalou da Microsoft Store (CentOS Stream nesse exemplo, para Ubuntu os comandos são os mesmos, com exceção do uso de service em vez de systemctl).

Inicie o serviço do Docker:

Faça o pull da imagem do DockerHub:

Execute o contêiner IRIS dentro do Docker:

Pegue o ID do contêiner IRIS usando grep e awk (de uma guia diferente do WSL, de preferência):  

É opcional parar o contêiner do docker antes dessa etapa, no entanto, se você não fizer isso, só precisará parar/iniciar a instância após a importação para o WSL

Exporte o ID do contêiner ID para um arquivo tar no seu c-drive montado:

Exemplo de importação da comunidade do IRIS

Abra o PowerShell e garanta que você tenha uma pasta criada onde quer armazenar a distribuição.

Use o comando wsl --import <DistroName> <InstallLocation> <InstallTarFile> para importar o arquivo tar.

Use o comando wsl -d IRISCommunity para executar sua distribuição Linux recém-importada.

Depois de conectado, inicialize o IRIS  (uma dica profissional, faça isso com wsl.conf!)

Aproveite sua instância!

http://localhost:52773/csp/sys/%25CSP.Portal.Home.zen

Você já pode aproveitar todos os benefícios de desempenho, flexibilidade e integração nativa do WSL2 (ou seja, acesso direto aos arquivos, acompanhamento de logs, cópia de drivers Java e muito mais) ao usar sua instância da comunidade do IRIS.

** https://learn.microsoft.com/en-us/windows/wsl/about

*** https://learn.microsoft.com/en-us/windows/wsl/use-custom-distro

**** https://docs.docker.com/get-docker/

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;

• Requisitos de computação.
• Requisitos de armazenamento.

Visão geral

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.

Requisitos de computação

Tipos de instância EC2

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:

• Núcleos de vCPU e memória.
• Máximo de IOPS e taxa de transferência de IO.

Para aplicativos IRIS como esse com um grande servidor de banco de dados, dois tipos de instâncias EC2 são apropriadas: 

• EC2 R5 e R6i estão na família de instâncias com memória otimizada e são adequadas para cargas de trabalho com uso intensivo da memória, como IRIS. Há 8 GB de memória por vCPU.
• EC2 M5 e M6i estão na família de instâncias de uso geral. Há 4 GB de memória por vCPU. Elas são mais usadas para servidores da Web, de impressão e de não produção.

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.

Planejamento de capacidade

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.

Requisitos de vCPU

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. 

Dimensionamento para a nuvem

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:

• 16 vCPUs e memória de 128 GB
• 32 vCPUs e memória de 256 GB
• 48 vCPUs e memória de 384 GB
• 64 vCPUs e memória de 512 GB
• E assim por diante.

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:

• O r5.8xlarge tem 32 vCPUs, 256 GB de memória e um máximo de 30.000 IOPS.
• O r512xlarge tem 48 vCPUs, 384 GB de memória e um máximo de 40.000 IOPS

Observe o máximo de IOPS. Isso será importante mais tarde.

Resultados

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%.

Recomendação

É 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:

• Desligue o espelho de backup.
• Ligue o espelho de backup usando uma instância menor ou maior com configurações alteradas para montar o armazenamento do EBS e contar com uma menor pegada de memória (considere, por exemplo, hugepages do Linux e buffers globais do IRIS).
• Aguarde a atualização do espelho de backup.
• Aplique a tolerância a falhas ao espelho de backup para que se torne principal.
• Repita, redimensione o espelho restante, coloque-o online novamente e atualize.

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.

Requisitos de armazenamento

Um desempenho de IO de armazenamento previsível com baixa latência é essencial para fornecer escalabilidade e confiabilidade para seus aplicativos.

Tipos de armazenamento

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.

• Os volumes gp3 oferecem uma linha de base de medição de desempenho de 3.000 IOPS e 125 MiBps em qualquer tamanho de volume, com uma latência de milissegundos de um dígito 99% do tempo para o custo base da capacidade de GB de armazenamento. Os volumes gp3 podem ser escalonados para 16.000 IOPS e 1.000 MiBps de taxa de transferência por um custo adicional. O armazenamento é precificado por GB e com base no provisionamento de IOPS acima da linha de base de 3.000 IOPS.
• Os volumes io2 oferecem uma linha de base de medição de desempenho constante de até 500 IOPS/GB para um máximo de 64.000 IOPS com uma latência de milissegundos de um dígito 99% do tempo. O armazenamento é precificado por GB e com base no provisionamento de IOPS.

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.

Planejamento de capacidade

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:

• Capacidade de armazenamento. Quantos GB de armazenamento de banco de dados são necessários e qual é o crescimento esperado? Por exemplo, você sabe o crescimento médio histórico de banco de dados do seu sistema local para uma taxa de transações conhecida. Nesse caso, você pode calcular os tamanhos de banco de dados futuros com base em qualquer crescimento previsto da taxa de transações. Você também precisará considerar outros tipos de armazenamento, como diários.
• IOPS e taxa de transferência. Esse é o mais interessante e é abordado em detalhes abaixo.

Requisitos de banco de dados

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.

Dimensionamento para a nuvem

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:

• 8.000 IOPS provisionadas em cada volume (para um total de 32.000 IOPS).
• Taxa de transferência de 250 MB/s provisionada em cada volume (para um total de 1.000 MB/s).

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.

Resultados

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.

Recomendação

É 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.

Links úteis

• Os gráficos são criados com "yaspe" https://community.intersystems.com/post/yaspe-yet-another-system-performance-extractor

AWS

• Confira detalhes do Elastic Cloud Computing (EC2) da AWS aqui: https://aws.amazon.com/ec2/
• Confira detalhes do Elastic Block Store (EBS) da AWS aqui: https://aws.amazon.com/ebs/

A maioria dos aplicativos transacionais tem um perfil de leitura/escrita (RW) de 70:30. No entanto, alguns casos especiais têm perfis de IO extremamente altos.

Realizei testes de IO de armazenamento na região da AWS ap-southeast-2 (Sydney) para simular os padrões de IO do banco de dados do IRIS e uma taxa de transferência semelhante a de um aplicativo com uma alta taxa de escrita.

O objetivo do teste era determinar se os tipos de instância EC2 e os tipos de volume do EBS disponíveis nas regiões australianas da AWS oferecem suporte às altas taxas de IO e transferência necessárias.

Foram realizados ajustes mínimos no sistema operacional e no IRIS (veja a configuração do sistema operacional e do IRIS abaixo).

• Os tipos de instância EC2 e de volume do EBS foram selecionados para maximizar as taxas de IOPS e transferência.

Os seguintes testes foram realizados:

• O uso de um único volume io2 Block Express para cada banco de dados e WIJ.
• O uso de um volume distribuído do Logical Volume Manager (LVM) de 16 discos gp3 para o banco de dados e um volume distribuído do LVM de cinco discos gp3 para o WIJ.
• Duas instâncias em zonas de disponibilidade separadas usando o espelhamento do banco de dados síncrono do IRIS com um único volume io2 Block Express para o banco de dados e o WIJ em cada instância.

Resumo

Foi executado um número limitado de testes. No entanto, os resultados mostram que é possível executar uma carga de trabalho do IRIS de alta taxa de IO na região de Sydney da AWS.

Há limites em todo lugar na nuvem

• É importante notar que, além dos limites das taxas de IOPS e de transferência publicados para instâncias e armazenamento, a AWS tem limites no nível da conta. A AWS precisou aumentar as cotas regionais de IOPS padrão da conta da InterSystems para 600.000 a fim de possibilitar os testes com altas taxas de IO — especificamente, EBS — de volumes de Provisioned IOPS SSD (io2).
  • Lembre-se de revisar os limites antes de começar os testes, principalmente para os testes de espelhamento, já que todos os volumes na região são incluídos no mesmo total.

Tipos de volume do EBS

• Os testes de IO foram realizados com o banco de dados do IRIS usando um único volume io2 Block Express do EBS e vários (16) volumes gp3 do EBS utilizando o Logical Volume Manager (LVM).
  • A taxa de IOPS de escrita, a taxa de transferência e a latência do banco de dados foram semelhantes nos testes de io2 Block Express e de gp3 LVM. A latência da escrita do banco de dados foi de aproximadamente 1 ms.
  • A latência de leitura do gp3 foi duas vezes maior que o io2 Block Express. No entanto, a latência de leitura máxima do gp3 ainda era aceitável a menos de 0,8 ms.
  • A latência de escrita do WIJ foi cerca de 50% mais alta em um único volume io2 Block Express do que em cinco volumes gp3 distribuídos do LVM.
  • Para detalhes sobre o io2 Block Express, confira https://aws.amazon.com/ebs/provisioned-iops/.
  • Para detalhes sobre o gp3, confira https://aws.amazon.com/ebs/general-purpose/.

Tipos de instância EC2

• Durante o teste em julho de 2023, somente um tipo de instância EC2 otimizada para a memória (r5b) na região de Sydney usava o sistema nitro capaz de executar os volumes io2 Block Express.
  • O tipo de instância EC2 selecionado precisa ser capaz de corresponder ou exceder a IO e a taxa de transferência do armazenamento necessárias para os volumes de dados e WIJ.
  • Os únicos tipos de instâncias em Sydney que são compatíveis com o io2 Block Express são r5b e c7g. c7g não foi usado devido a menor IOPS e baixa memória.
  • O io2 Block Express é necessário para uma maior taxa de transferência e de IOPS (256.000 IOPS por volume) em comparação com o io2 padrão (64.000 IOPS por volume).
  • As instâncias EC2 capazes de usar o io2 Block Express não estão disponíveis em Melbourne no momento.

Testes

• Os utilitários RANREAD e RANWRITE disponíveis para o público foram usados para simular o perfil de IO do IRIS. Por exemplo, o RANWRITE usa o ciclo de WD do IRIS, resultando em uma rajada de grandes IOs do WIJ e escritas aleatórias de bancos de dados que geralmente não são esperadas ou compreendidas pelos fornecedores de armazenamento.
  • Para uma visão geral do LVM e dos utilitários RANREAD e RANWRITE, confira https://community.intersystems.com/post/using-lvm-stripe-increase-aws-ebs-iops-and-throughput.
  • Com uma taxa mais alta de transferência e de IOPS, os resultados gerais e o perfil de IO não devem mudar. Por exemplo, o ciclo de WD no pico de IOPS de armazenamento será mais longo na latência observada.

Ambiente da AWS

O seguinte ambiente foi testado em ap-southeast-2 (Sydney). O mesmo tipo de instância foi usado para todos os testes, fazendo uma comparação equivalente.

Perfil de instância EC2

Tipo de instância EC2: 

• R5b.24xlarge: 96 vCPU, 780 GB de memória, 25 Gbps de rede.
  • Limites do EBS por instância EC2: 
    • Taxa de transferência máxima de (MB/s) 7.500
    • Taxa de IOPS máxima de 260.000

O pacote de benchmark usa uma distribuição do LVM de 4 MB mesmo se houver um ou vários volumes. Todos os volumes usam o sistema de arquivo xfs.

Testes de benchmark

• Para o teste 1 e 2, o WIJ está em um volume separado.
  • O WIJ e o banco de dados podem estar no mesmo volume para reduzir os custos de armazenamento.
  • No entanto, ter o WIJ em um volume separado isola o impacto do WIJ nas leituras do banco de dados.
  • O volume do diário é sempre separado dos volumes do WIJ e do banco de dados.

Teste 1 - io2 Block Express

Layout do armazenamento

• Diário
  • Único volume gp3. Usei os valores padrão: 3.000 IOPS e taxa de transferência de 125 MB/s.
• WIJ
  • Único volume io2 Block Express. 256.000 IOPS e taxa de transferência de 4.000 MB/s.
• Banco de dados
  • Único volume io2 Block Express. 100.000 IOPS e taxa de transferência de 4.000 MB/s.

Teste 2 - distribuição de LVM gp3

Layout do armazenamento

• Diário
  • Único volume gp3. Usei os valores padrão: 3.000 IOPS e taxa de transferência de 125 MB/s.
• WIJ
  • Cinco volumes gp3. Cada um com 16.000 IOPS e taxa de transferência de 1.000 MB/s. Total de 80.000 IOPS e taxa de transferência de 5.000 MB/s.
• Banco de dados
  • 16 volumes gp3. Cada um com 16.000 IOPS e taxa de transferência de 1.000 MB/s. Total de 256.000 IOPS e taxa de transferência de 16.000 MB/s.

Teste 3 - espelho de banco de dados assíncrono do IRIS - io2 Block Express

Foi criado um espelho do banco de dados com o membro espelho principal na zona b de disponibilidade da AWS e o membro espelho de backup na zona c de disponibilidade. O árbitro estava na zona de disponibilidade a.

• A mesma taxa de IO de leitura/escrita foi executada como nos outros testes.

Layout do armazenamento

• Devido à cota total de 600.000 IOPS em todos os volumes, o WIJ e o banco de dados estão no mesmo volume io2 Block Express. Isso permite um total de (256K + 256K) 512 IOPS em todos os espelhos.

• Diário

  • Único volume gp3. Usei os valores padrão: 3.000 IOPS e taxa de transferência de 125 MB/s.

• WIJ e banco de dados

  • Único volume io2 Block Express. 256.000 IOPS e taxa de transferência de 4.000 MB/s.

Observações

IO de leitura do banco de dados

O gráfico abaixo mostra um io2 Block Express com aproximadamente metade da latência como uma distribuição do LVM de volumes gp3. O andamento dos testes de benchmark é controlado usando vários processos, resultando na metade de IOPS e no dobro da latência. Um teste baseado em aplicativo pode oferecer resultados diferentes ou o andamento dos testes pode ser alterado para aumentar os processos e a taxa de IOPS resultante.

IO de escrita do banco de dados

O gráfico abaixo mostra um pico semelhante de IOPS e latência entre o io2 Block Express e uma distribuição do LVM de volumes gp3. A maior latência de escrita do banco de dados do espelho principal ocorre porque o WIJ está no mesmo volume. A maior latência é o WIJ. A latência de escrita do banco de dados aleatório foi semelhante ao io2 Block Express. A latência é medida para escritas diferentes de zero.

IO de escrita do WIJ

O gráfico abaixo mostra a maior taxa de transferência para uma distribuição do LVM de volumes gp3. No entanto, isso é enganoso, já que o volume io2 Block Express teve uma taxa de transferência mais alta e um tempo de escrita do WIJ menor. Investigações adicionais podem mostrar, por exemplo, mais IOs no volume io2 Block Express. A latência é medida para escritas diferentes de zero.

Taxa de transferência

A taxa de transferência é uma das métricas cobradas pela AWS e tem um limite para cada instância EC2 (10.000 MB/s) e cada volume do EBS (4.000 MB/s para io2 Block Express e 1.000 MB/s para gp3). Semelhante à forma como IOPS são monitoradas e restringidas pela AWS ao aumentar a latência. O gráfico a seguir mostra a taxa de transferência em kB/s. Os requisitos da taxa de transferência precisam ser conhecidos para garantir que o subprovisionamento dessa taxa não se torne um gargalo. A taxa de transferência do WIJ é mais alta do que a taxa de transferência provisionada por volume. Isso pode ocorrer, já que a AWS leva alguns segundos para registrar que está ocorrendo uma taxa de IOPS ou de transferência mais alta do que o provisionado antes de limitá-la.

As escritas do banco de dados afetam a latência de leitura do banco de dados.

O gráfico mostra as tendências. No entanto, surgem vários detalhes ao examinar as métricas de forma mais detalhada. Por exemplo, as escritas do banco de dados são afetadas por uma rajada de escritas no mesmo volume. As escritas de maior tamanho do WIJ têm um impacto mais significativo. Os padrões de IO dos diferentes tipos de volumes também são interessantes.

io2 Block Express

O seguinte gráfico mostra os aumentos escalonados no processo de leitura durante o teste de io2 Block Express. Observe a queda nas leituras quando o armazenamento precisa ler e escrever ao mesmo tempo.

O gráfico a seguir mostra os picos correspondentes na latência. Observe a taxa de IOPS de leitura suave no gráfico acima e a latência achatada abaixo.

Distribuição do LVM gp3

Os mesmos gráficos da distribuição do LVM dos discos gp3 mostram um padrão de IO menos estável (às vezes, chamado de "jitter") dos discos gp3.

Compare a latência de leitura da linha de base com a latência máxima para os diferentes tipos de volumes.

Outros detalhes

Configuração do IRIS

A versão do IRIS do teste foi "2023.2.0.204.0".

A configuração do IRIS foi mínima. É exibido abaixo um fragmento do arquivo cpf.

[config]
Asyncwij=16
:
globals=0,0,589824,0,0,0
:
wdparm=16,32,512,128
wduseasyncio=1

• Asyncwij = 16 significa 16 escritas do WIJ em trânsito por vez. O padrão é oito.

O parâmetro wdparm é usado para configurar o número de daemons de escrita (WDs) escravos, o tamanho da tabela do ID do dispositivo (usado para atribuir escritas a WDs) e o número máximo de escritas pendentes em todos os WDs, além de determinar se o banco de dados ajustará ou não o número de escritas permitidas POR WD e se alguns WDs estão inativos ou serão encerrados mais cedo em uma determinada passagem.

16 = número de daemons de escrita (8 é o padrão)
32 = tamanho da tabela de ID do dispositivo (32 é o padrão)
512 = número máximo de IOs pendentes para todos os daemons de escrita
128 = número máximo de IOs pendentes por daemon de escrita

Tempo de ping das zonas de disponibilidade (AZ) da AWS no dia do teste de espelho

O espelho principal estava na AZ b; o de backup, na AZ c.

• O ping da AZ b para AZ c foi uma média de 1,16 ms
• O ping da AZ c para AZ b foi uma média de 1,12 ms

Ola Comunidade,

Assista este video para aprender como a plataforma da InterSystems permite a escalabilidade horizontal e vertical:  

⏯ Scaling for User and Data Volume in InterSystems IRIS

De acordo com o relatório Global Fraud and Identity Report 2020 da Experian, as fraudes no setor financeiro globalmente ultrapassaram a marca de US$ 42 bilhões em 2020, com destaque para fraudes de identidade, bancárias, em cartões de crédito e débito, em empréstimos e em aplicativos móveis bancários. A pandemia do COVID-19 impulsionou o crescimento de fraudes relacionadas à saúde, como fraudes em benefícios de seguro-saúde e em programas de ajuda financeira do governo. Considerando tais dados, fica claro que é essencial que as instituições financeiras adotem soluções eficientes para detectar

Certifique-se em Administração de Sistema InterSystems IRIS!

Olá Comunidade,

Após o teste beta do novo exame de Certificação de Especialista em Administração de Sistemas InterSystems IRIS, a equipe de certificação dos Serviços de Aprendizagem InterSystems realizou a calibração e os ajustes necessários para liberá-lo para nossa comunidade. Já está pronto para compra e agendamento no catálogo de exames de certificação da InterSystems. Os candidatos em potencial podem analisar os tópicos do exame e as questões práticas para ajudar a orientá-los quanto às abordagens e conteúdo das questões do exame. A aprovação no exame permite que você reivindique um selo de certificação eletrônico que pode ser incorporado a contas de mídia social, como o Linkedin..  

Olá Comunidade,

Bom dia a todos.

Preciso consultar informações das tabelas/classes que estejam em lock

Eu achei na documentação a classe %SYS.LockQuery mas no exemplo ela parece ser uma Class Query(não estou acostumado com esse conceito) e só consigo consumir os dados via Object Script usando um %ResultSet

Existe alguma forma de consumir essas informações diretamente via SQL ?

Grato por qualquer ajuda

Na última postagem, agendamos a coleta de métricas de desempenho durante 24 horas usando pButtons. Nesta postagem, vamos ver algumas métricas essenciais que estão sendo coletadas e como elas estão ligadas ao hardware do sistema. Também começaremos a explorar a ligação entre as métricas do Caché (ou de qualquer plataforma de dados InterSystems) e as métricas do sistema. Além disso, veremos como você pode usar essas métricas para entender a integridade diária de seus sistemas e diagnosticar problemas no desempenho.

Grupos alimentares de hardware

Como você verá a medida que avançarmos por esta série de postagens, os componentes do servidor que afetam o desempenho podem ser categorizados como:

• CPU
• Memória
• E/S de armazenamento
• E/S de rede

Se algum desses componentes estiver sobrecarregado, o desempenho do sistema e a experiência do usuário serão prejudicados. Todos esses componentes estão inter-relacionados, e mudanças em um deles pode afetar os outros, às vezes com consequências inesperadas. Já vi um caso em que corrigir um problema de gargalo de E/S em uma matriz de armazenamento fez o uso de CPU subir para 100%, e a consequência foi uma experiência do usuário ainda pior, pois o sistema ficou livre de repente para fazer mais trabalho, mas não tinha os recursos de CPU necessários devido ao aumento da atividade e taxa de transferência dos usuários.

Também veremos como a atividade do sistema do Caché tem impacto direto nos componentes do sistema. Se houver recursos de E/S de armazenamento limitados, uma mudança positiva que pode ser feita é o aumento da memória do sistema e o aumento da memória dos buffers globais do Caché, o que pode diminuir a E/S de leitura de armazenamento do sistema (mas talvez aumente o uso de CPU!).

Uma das métricas de sistema mais óbvias que deve ser monitorada regularmente ou verificada se os usuários relatarem problemas é o uso de CPU. Pode-se verificar utilizando o top ou nmon no Linux e AIX, ou Monitor de Desempenho do Windows. Como a maioria dos administradores de sistema verificam os dados de CPU regularmente, ainda mais quando são apresentados em gráficos, uma olhada rápida fornece uma boa compreensão da integridade atual do sistema: o que está normal, ou um surto repentino de atividade, que pode ser anormal ou indicar um problema. Nesta postagem, vamos dar uma olhada rápida nas métricas de CPU, mas nos concentraremos nas métricas do Caché. Começaremos verificando os dados do mgstat e como ver os dados em gráficos pode dar uma boa compreensão da integridade do sistema rapidamente.

Introdução ao mgstat

O mgstat é um dos comandos do Caché incluídos e executados no pButtons. O mgstat é uma ferramenta excelente para coletar métricas básicas de desempenho para ajudar a entender a integridade dos sistemas. Veremos os dados do mgstat coletados durante 24 horas em um pButtons, mas, se você quiser capturar dados além do pButtons, o mgstat também pode ser executado sob demanda de forma interativa ou como um trabalho em segundo plano pelo terminal do Caché.

Para executar o mgstat sob demanda pelo namespace %SYS, o formato geral é:

do mgstat(sample_time,number_of_samples,"/caminho_do_arquivo/arquivo.csv",page_length)

Por exemplo, veja abaixo o comando para executar em uma tarefa em segundo plano por uma hora com um período de amostragem de 5 segundos e salvar a saída em um arquivo csv:

job ^mgstat(5,720,"/data/mgstat_data_e_hora_de_hoje.csv")

Por exemplo, para exibir na tela sem algumas colunas, chame a rotina através do label dsp132: Deixarei como tarefa para vocês a verificação da saída para que vocês entendam melhor a diferença.

do dsp132^mgstat(5,720,"",60)

As informações detalhadas das colunas do mgstat estão disponíveis no Guia de monitoramento do Caché na documentação mais recente do Caché: Documentação online da InterSystems

Sobre os dados do mgstat

O pButtons agrupa os dados em um único arquivo HTML, facilitando a navegação e empacotando os dados para envio aos especialistas de suporte da Central de Suporte (WRC) para diagnosticar problemas no desempenho. Entretanto, quando você executa o pButtons por conta própria e deseja exibir os dados em gráficos, eles podem ser separados novamente em um arquivo csv para processamento em gráficos, por exemplo, com o Excel, usando um script de linha de comando ou apenas cortando e colando os dados.

Nesta postagem analisaremos algumas métricas do mgstat para mostrar como somente uma visão rápida dos dados pode indicar se o sistema está com bom desempenho ou se há problemas atuais ou potenciais que afetarão a experiência do usuário.

Glorefs e CPU

O gráfico abaixo mostra o uso de CPU do servidor de banco de dados em um local que executa uma aplicação de hospital com uma alta taxa de transações. Note o pico de atividade durante a manhã, quando há vários ambulatórios, com uma queda durante o almoço, diminuindo então à tarde e à noite. Neste caso, os dados vêm de _(Total)% Tempo do Processador do Monitor de Desempenho do Windows. O formato do gráfico corresponde ao perfil diário de trabalho, sem picos ou depressões incomuns, o que é normal para esse local. Fazendo o mesmo em seu local, você pode começar a estabelecer uma linha de base do que é "normal". Um grande pico, especialmente um de longa duração, pode ser um indicador de problema. Uma postagem futura se concentrará na CPU.

Como referência, este banco de dados está em um servidor Dell R720 com dois processadores E5-2670 de 8 núcleos. O servidor tem 128 GB de memória e 48 GB de buffers de globais.

O próximo gráfico mostra mais dados do mgstat: Glorefs (referências globais) ou acessos ao banco de dados no mesmo dia que o gráfico de CPU. As glorefs indicam a quantidade de trabalho ocorrendo durante a carga de trabalho atual. Embora as referências a globais consumam tempo de CPU, nem sempre elas consomem outros recursos do sistema, como leituras físicas, devido à maneira como o Caché usa o pool global de buffers de memória.

Nas aplicações típicas do Caché, há uma correlação muito forte entre as glorefs e o uso de CPU.

Outro modo de olhar esses dados de CPU e glorefs é dizendo que a redução das glorefs reduz o uso de CPU, permitindo a implantação em servidores com menos núcleos ou a escalabilidade de sistemas existentes. É possível reduzir as referências globais tornando uma aplicação mais eficiente. Voltaremos a esse conceito em postagens futuras.

PhyRds e Rdratio

O formato da representação gráfica dos dados PhyRds (leituras físicas) e Rdratio (proporção de leituras) do mgstat também pode fornecer informações do que se esperar do desempenho do sistema e ajudar a planejar a capacidade. Vamos analisar com mais detalhes a E/S de armazenamento no Caché em postagens futuras.

PhyRds são simplesmente Operações de Entrada e Saída por Segundo (IOPS) de leitura nos bancos de dados do Caché. Você deverá ver os mesmos valores nas métricas do sistema operacional para discos lógicos e físicos. Lembre-se de que, ao verificar as Operações de Entrada e Saída por Segundo (IOPS) do sistema operacional, também podem estar sendo exibidos dados de outras aplicações que não o Caché. Dimensionar o armazenamento sem levar em conta as Operações de Entrada e Saída por Segundo (IOPS) esperadas é uma receita para o desastre. Você precisa saber as IOPS de seu sistema em horários de pico para planejar a capacidade corretamente. O gráfico abaixo mostra PhyRds entre meia-noite e 15h30.

Observe o grande salto de leituras entre 5h30 e 10h. Também há picos menores às 11h e um pouco antes das 14h. Qual você acha que é a causa desses picos? Você também vê esse tipo de picos em seus servidores?

Rdratio é um pouco mais interessante: é a proporção de leituras de blocos lógicos em comparação a leituras de blocos físicos. Portanto, é a proporção de quantas leituras são de buffers de globais (lógicos) da memória e quantas são do disco, que são algumas ordens de grandeza mais lentas. Uma Rdratio alta é uma boa coisa, e chegar perto de zero por longos períodos não é bom.

Observe que, quando as leituras físicas estão altas, Rdratio cai para perto de zero. Nesse local, me pediram para investigar quando o departamento de TI começou a receber ligações de usuários informando que o sistema estava lento por longos períodos. Isso estava acontecendo de maneira aparentemente aleatória durante várias semanas quando me pediram para verificar o sistema.

_Como o pButtons havia sido agendado para execução diária de 24 horas, foi relativamente simples analisar os dados de várias semanas passadas para começar a ver um padrão de PhyRds alta e Rdratio baixa, com uma correlação com as ligações de suporte.*

Após uma análise mais detalhada, descobriu-se que a causa era um novo funcionário que executava diversos relatórios com parâmetros ruins, além de consultas mal escritas sem índices apropriados, o que causava muitas leituras no banco de dados. Essa era a causa da lentidão aparentemente aleatória. Como esses relatórios de longa execução lêem dados dos buffers de globais, a consequência é que os dados interativos dos usuários estavam sendo obtidos do armazenamento físico, em vez da memória, e o armazenamento estava sendo sobrecarregado para atender às solicitações de leitura.

O monitoramento das métricas PhyRds e Rdratio dará uma ideia da integridade de seus sistemas e talvez permitirá que você descubra relatórios ou consultas ruins. Pode haver um motivo válido para uma PhyRds alta: talvez um relatório precise ser executado em determinada hora. Com os sistemas operacionais modernos de 64 bits e servidores com alta capacidade de memória física, você deverá conseguir minimizar a PhyRds em seus sistemas de produção.

Caso a PhyRds esteja alta em seu sistema, você pode considerar algumas estratégias: - Melhorar o desempenho aumentando o número de buffers (globais) de banco de dados (e a memória do sistema). - Relatórios ou extrações de longa duração podem ser feitos fora do horário comercial. - Relatórios somente leitura de longa duração, trabalhos em lote ou extrações de dados podem ser feitos em um servidor Shadow ou um membro de espelhamento assíncrono para minimizar o impacto nos usuários interativos e para diminuir a carga de recursos do sistema, como CPU e Operações de Entrada e Saída por Segundo (IOPS).

Geralmente, é bom ter uma PhyRds baixa, e é nossa meta ao dimensionar os sistemas. Entretanto, se a PhyRds estiver baixa e os usuários estiverem reclamando do desempenho, você pode verificar outros fatores para confirmar que o armazenamento não é o gargalo. A quantidade de leituras pode estar baixa porque o sistema não consegue mais atender à demanda. Veremos o armazenamento com mais detalhas em uma postagem futura.

Resumo

Nesta postagem, verificamos como olhar graficamente as métricas coletadas no pButtons pode fornecer uma compreensão da integridade rapidamente. Em postagens futuras, analisarei com mais detalhes a ligação entre as métricas de sistema e do Caché e como você pode usá-las para se planejar para o futuro.

Desde o Caché 2017, o mecanismo SQL inclui um novo conjunto de estatísticas. Ele registra o número de vezes que uma consulta é executada e o tempo que leva para executá-la.

Esta é uma mina de ouro para qualquer pessoa que está monitorando e tentando otimizar o desempenho de uma aplicação que inclui muitas instruções SQL, mas que não é tão fácil de acessar os dados como algumas pessoas desejam.

Sua aplicação está implantada e tudo está funcionando bem. Ótimo, bate aqui! Então, do nada, o telefone começa a tocar sem parar – são os usuários reclamando que, às vezes, a aplicação está "lenta". Mas o que isso significa? Às vezes? Quais ferramentas você tem e quais estatísticas você deve examinar para encontrar e resolver essa lentidão? A infraestrutura do seu sistema está à altura da tarefa de carga do usuário? Que perguntas de design de infraestrutura você deveria ter feito antes de entrar em produção? Como você pode planejar a capacidade de um novo hardware com confiança sem excesso de especificações? Como você pode parar o telefone de tocar? Como você poderia ter impedido o telefone de tocar em primeiro lugar?

Veja aqui uma lista das outras postagens desta série

Esta será uma jornada

Este é a primeira postagem de uma série que explorará as ferramentas e métricas disponíveis para monitorar, revisar e solucionar problemas de desempenho de sistemas, bem como considerações de design e arquitetura de sistema que afetam o desempenho. Ao longo do caminho, iremos percorrer algumas trilhas para entender o desempenho do Caché, sistemas operacionais, hardware, virtualização e outras áreas que se tornam tópicos a partir de seu feedback nos comentários.

Seguiremos o ciclo de feedback fornecido pelos dados de desempenho para visualizar as vantagens e limitações das aplicações e da infraestrutura implantadas e, em seguida, voltar para uma melhor concepção e planejamento de capacidade.

Não é preciso dizer que você deve revisar as métricas de desempenho constantemente. É lamentável o número de vezes que os clientes são surpreendidos por problemas de desempenho que estavam visíveis por um longo tempo, se eles tivessem olhando os dados. Mas, é claro, que a questão é: quais dados? Começaremos a jornada coletando algumas métricas básicas do Caché e do sistema para que possamos ter uma ideia da integridade do seus sistema atual. Em postagens posteriores, mergulharemos no significado das principais métricas.

Há muitas opções disponíveis para o monitoramento do sistema – internamente do Caché e externamente. Vamos explorar um monte deles nesta série. 

Para começar, veremos minha ferramenta favorita para coleta contínua de dados que já está instalada em todos os sistemas Caché – o ^pButtons.

Para ter certeza de que você tem a última cópia do pButtons, reveja a seguinte postagem:

https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-how-update-pbuttons

Coletando métricas de desempenho do sistema – ^pButtons

O utilitário Caché pButtons gera um relatório de desempenho em HTML legível a partir dos arquivos de log que ele cria. A saída das métricas de desempenho pelo pButtons pode ser facilmente extraída, mapeada e revisada. 

Os dados coletados no arquivo HTML pelo pButtons incluem:

• Configuração do Caché: com configuração, mapeamentos de unidades, etc.
• mgstat: Métricas de desempenho do Caché – a maioria dos valores são médios por segundo.
• Unix: vmstat e iostat – recursos do sistema operacional e métricas de desempenho.
• Windows: monitor de desempenho – recursos do Windows e métricas de desempenho.
• Outras métricas que serão úteis.

A coleta de dados do pButtons tem muito pouco impacto no desempenho do sistema, as métricas já estão sendo coletadas pelo sistema, o pButtons simplesmente as empacota para facilitar o arquivamento e transporte. 

Para manter uma linha de base, para análise de tendências e solução de problemas, é uma boa prática realizar uma coleta com o pButtons de 24 horas (meia-noite à meia-noite) todos os dias, para um ciclo de negócios completo. Um ciclo de negócios pode durar um mês ou mais, por exemplo, para capturar dados de processamento no final do mês. Se você não tiver nenhum outro monitoramento de desempenho externo ou coleta, você pode executar o pButtons durante o ano todo. 

Os seguintes pontos-chave devem ser observados:

• Mude o diretório de log para um local longe dos dados de produção para armazenar arquivos de saída acumulados e evitar problemas de disco cheio!
• Execute um script do sistema operacional ou compacte e arquive o arquivo pButtons regularmente. Isso é especialmente importante no Windows, pois os arquivos podem ser grandes.
• Revise os dados regularmente!

No caso de um problema que necessite de análise imediata, os dados do pButtons podem ser visualizados (coletados imediatamente) enquanto as métricas continuam a ser armazenadas para a coleta no final dos dias de execução.

Para obter mais informações sobre pButtons, incluindo visualização, interrupção de uma execução e adição de coleta de dados personalizados, veja o Guia de Monitoramento Caché na documentação mais recente do  Caché: 

http://docs.intersystems.com

Os dados do arquivo HTML pButtons podem ser separados e extraídos (para arquivos CSV, por exemplo) para processamento em gráficos ou outra análise por script ou simplesmente recortar e colar. Veremos exemplos da saída em gráficos posteriormente na próxima postagem.

É claro que, se você tiver problemas urgentes de desempenho, entre em contato com a Central de Suporte (WRC).

Agende a coleta de dados de 24 horas do pButtons

O ^pButtons pode ser iniciado manualmente a partir do prompt do terminal ou agendado. Para agendar uma coleta diária de 24 horas:

1. Inicie o terminal Caché, mude para o %SYS namespace e execute o pButtons manualmente uma vez para configurar as estruturas de arquivo do pButtons:

   %SYS>d ^pButtons Current log directory: /db/backup/benchout/pButtonsOut/ Available profiles: 1 12hours - 12 hour run sampling every 10 seconds 2 24hours - 24 hour run sampling every 10 seconds 3 30mins - 30 minute run sampling every 1 second 4 4hours - 4 hour run sampling every 5 seconds 5 8hours - 8 hour run sampling every 10 seconds 6 test - A 5 minute TEST run sampling every 30 seconds

Selecione a opção 6. para teste, amostragem de execução de TESTE de 5 minutos a cada 30 segundos. Observe que sua numeração pode ser diferente, mas o teste deve ser óbvio.

Durante a execução, execute Collect^pButtons (conforme mostrado abaixo), você verá informações incluindo o runid. Neste caso, “20160303_1851_test”.

%SYS>d Collect^pButtons
Current Performance runs:
    <strong>20160303_1851_test</strong>        ready in 6 minutes 48 seconds nothing available to collect at the moment.
%SYS>

Observou que esta execução de 5 minutos leva 6 minutos e 48 segundos para finalizar? O pButtons adiciona um período de carência de 2 minutos a todas as execuções permitindo um tempo para a coleta e ordenação dos logs no formato HTML. 

2. IMPORTANTE! Altere o diretório de saída do log pButtons - o local de saída padrão é a pasta /mgr. Por exemplo, no Unix, o caminho para o diretório de log pode ser assim:

do setlogdir^pButtons("/algum_lugar_com_muito_espaço/perflogs/")

Certifique-se de que o Caché tenha permissões de gravação para o diretório e que haja espaço em disco suficiente disponível para acumular os arquivos de saída.

3. Crie um novo perfil de 24 horas com intervalos de 30 segundos executando o seguinte:

write $$addprofile^pButtons("<strong>My_24hours_30sec</strong>","24 hours 30 sec interval",30,2880)

Verifique se o perfil foi adicionado ao pButtons:

%SYS>d ^pButtons
Current log directory: /db/backup/benchout/pButtonsOut/
Available profiles:
     1  12hours     - 12 hour run sampling every 10 seconds
     2  24hours     - 24 hour run sampling every 10 seconds
     3  30mins      - 30 minute run sampling every 1 second
     4  4hours      - 4 hour run sampling every 5 seconds
     5  8hours      - 8 hour run sampling every 10 seconds
     6  My_24hours_30sec- 24 hours 30 sec interval
     7  test        - A 5 minute TEST run sampling every 30 seconds

select profile number to run:

4. Dica Para sites UNIX, revise o comando disk. Os parâmetros padrão usados com o comando 'iostat' podem não incluir os tempos de resposta do disco. Primeiro exiba quais comandos de disco estão configurados atualmente:

%SYS>zw ^pButtons("cmds","disk")
^pButtons("cmds","disk")=2
^pButtons("cmds","disk",1)=$lb("iostat","iostat ","interval"," ","count"," > ")
^pButtons("cmds","disk",2)=$lb("sar -d","sar -d ","interval"," ","count"," > ")

Para coletar estatísticas de disco, use o comando apropriado para editar a sintaxe de sua instalação do UNIX. Observe o espaço à direita. Aqui estão alguns exemplos:

LINUX:     set $li(^pButtons("cmds","disk",1),2)="iostat -xt "
AIX:       set $li(^pButtons("cmds","disk",1),2)="iostat -sadD "
VxFS:      set ^pButtons("cmds","disk",3)=$lb("vxstat","vxstat -g DISKGROUP -i ","interval"," -c ","count"," > ")

Você pode criar arquivos HTML pButtons muito grandes, executando os comandos iostat e sar. Para avaliações regulares de desempenho, geralmente uso apenas o iostat. Para configurá-lo há apenas um comando:

set ^pButtons("cmds","disk")=1

Mais detalhes sobre como configurar pButtons estão na documentação on-line.

5. Programe o pButtons para iniciar à meia-noite no Portal de Gerenciamento > Operação de Sistema > Gerenciado de Tarefas:

Namespace: %SYS
 Task Type: RunLegacyTask
 ExecuteCode: Do run^pButtons("My_24hours_30sec")
 Task Priority: Normal
 User: superuser
 How often: Once daily at 00:00:01

Coletando dados com pButtons

O pButtons disponível em versões mais recentes das Plataformas de Dados InterSystems incluem a coleta automática. Para coletar e ordenar manualmente os dados em um arquivo HTML no %SYS namespace, execute o seguinte comando para gerar quaisquer arquivos de saída HTML pButtons pendentes:

do Collect^pButtons

O arquivo HTML estará no logdir que você configurou no passo 2 (se você não configurou, vá e faça agora!). Caso contrário, o local padrão é <Caché install dir/mgr> <Caché install dir/mgr>

Os arquivos são nomeados como <hostname_instance_Name_date_time_profileName.html><hostname_instance_Name_date_time_profileName.html> Ex. vsan-tc-db1_H2015_20160218_0255_test.html

Considerações sobre o Monitor de Desempenho do Windows

Se o sistema operacional for Windows, o Monitor de Desempenho do Windows (perfmon) pode ser usado para coletar dados em sincronia com as outras métricas coletadas. Em distribuições Caché mais antigas do pButtons, o perfmon do Windows precisa ser configurado manualmente. Se houver uma demanda nos comentários da postagem, escreverei uma postagem sobre a criação de um template perfmon para definir os contadores de desempenho a serem monitorados e agendar a execução para o mesmo período e intervalo que o pButtons.

Resumo

Esta postagem nos fez começar a coletar alguns dados para analisar. No final da semana, começarei a examinar alguns dados de amostra e o que isso significa. Você pode acompanhar os dados coletados em seus próprios sistemas. Vejo você então.

http://docs.intersystems.com

Introdução

Recentemente, a InterSystems concluiu uma comparação de desempenho e escalabilidade da IRIS for Health 2020.1, cujo foco foi a interoperabilidade do HL7 versão 2. Este artigo descreve a taxa de transferência observada para diversas cargas de trabalho e também apresenta diretrizes de configuração geral e dimensionamento para sistemas nos quais a IRIS for Health é usada como um mecanismo de interoperabilidade para as mensagens do HL7v2.

A versão 2020.1 da IRIS for Health demonstrou uma taxa de transferência sustentada de mais de 2,3 bilhões de mensagens (entrada e saída) por dia com um servidor simples com processadores escaláveis Intel® Xeon® de 2ª geração e armazenamento Intel® Optane™ SSD DC P4800X Series. Os resultados mais que dobraram a escalabilidade em relação à comparação de taxa de transferência anterior do Ensemble 2017.1 HL7v2.

Durante os testes, a IRIS for Health foi configurada para preservar a ordem PEPS (primeiro a entrar, primeiro a sair) e para fazer a persistência completa das mensagens e filas para cada mensagem de entrada e saída. Ao fazer a persistência das filas e mensagens, a IRIS for Health proporciona proteção dos dados caso haja travamento do sistema, além de recursos completos de procura e reenvio de mensagens passadas.

Além disso, as diretrizes de configuração são abordadas nas seções abaixo, que ajudarão a escolher uma configuração e implantação adequadas para atender às exigências de desempenho e escalabilidade de suas cargas de trabalho.

Os resultados mostram que a IRIS for Health consegue atender a altíssimas taxas de transferência de mensagens em hardware de prateleira e, na maioria dos casos, permite que um único servidor pequeno forneça interoperabilidade de HL7 para toda a organização.

Visão geral dos resultados

Foram usadas três cargas de trabalho para representar diferentes aspectos da atividade de interoperabilidade do HL7:

• Carga de trabalho T1: usa passagem simples de mensagens HL7, com uma mensagem de saída para cada mensagem de entrada. As mensagens são passadas diretamente do serviço empresarial do Ensemble (Ensemble Business Service) para a operação de negócios do Ensemble (Ensemble Business Operation), sem um mecanismo de roteamento. Nenhuma regra de roteamento foi usada, e nenhuma transformação foi executada. Foi criada uma instância de mensagens HL7 no banco de dados por mensagem de entrada.
• Carga de trabalho T2: usa um mecanismo de roteamento para alterar uma média de 4 segmentos da mensagem de entrada e roteá-la para uma única interface de saída (1 para 1 com uma transformação). Para cada mensagem de entrada, foi executada uma transformação de dados, e foram criados dois objetos de mensagem HL7 no banco de dados.
• Carga de trabalho T4: usa um mecanismo de roteamento para rotear separadamente mensagens modificadas para cada uma das quatro interfaces de saída. Em média, 4 segmentos da mensagem de entrada foram modificadas em cada transformação (1 entrada para 4 saídas com 4 transformações). Para cada mensagem de entrada, foram executadas quatro transformações de dados, foram enviadas quatro mensagens de saída, e foram criados cinco objetos de mensagem HL7 no banco de dados.

As três cargas de trabalha foram executadas em um sistema físico de 48 núcleos com dois processadores escaláveis Intel® Xeon® Gold 6252, com das unidades Intel® Optane™ SSD DC P4800X de 750 GB, com o Red Hat Enterprise Linux 8. Os dados são apresentados como o número de mensagens por segundo (e por hora) de entrada, o número por segundo (e por hora) de saída, bem como o total de mensagens (de entrada e de saída) em 10 horas por dia. Além disso, o uso de CPU é apresentado como medida dos recursos de sistema disponíveis para determinado nível de taxa de transferência. 

Resultados de escalabilidade

Tabela 1: Resumo da  taxa de transferência das quatro cargas de trabalho nesta configuração de hardware testada:

*Carga de trabalho combinada, com 25% de T1, 25% de T2 e 50% de T4

Descrição e metodologia das cargas de trabalho

As cargas de trabalho testadas incluíram mensagens de Patient Administration (ADT) e Observation Result (ORU) do HL7v2, com um tamanho médio de 1,2 KB e uma média de 14 segmentos. Cerca de 4 segmentos foram modificados pelas transformações (para cargas de trabalho T2 e T4). Os testes representam 48 a 128 interfaces de entrada de 48 a 128 interfaces de saída enviando e recebendo mensagens por TCP/IP.

Na carga de trabalho T1, foram usados quatro namespaces separados, cada um com 16 interfaces; na carga de trabalho T2, foram usados três namespaces, cada um com 16 interfaces; na carga de trabalho T4, foram usados quatro namespaces, cada um com 32 interfaces; e, na última "carga de trabalho combinada", foram usados três namespaces, com 16 interfaces para carga de trabalho T1, 16 para carga de trabalho T2 e 32 para carga de trabalho T4.

A escalabilidade foi mensurada aumentando-se gradualmente o tráfego em cada interface para descobrir a taxa de transferência mais alta com critérios de desempenho aceitável. Para que o desempenho seja aceitável, as mensagens devem ser processadas a uma taxa sustentada, sem filas, sem atrasos mensuráveis na entrada das mensagens, e o uso médio de CPU deve ficar abaixo de 80%.

Testes anteriores demonstraram que o tipo de mensagem HL7 usado não é significativo para o desempenho e a escalabilidade do Ensemble. Os fatores significativos são o número de mensagens de entrada, o tamanho das mensagens de entrada e saída, o número de novas mensagens criadas no mecanismo de roteamento e o número de segmentos modificados.

Além disso, testes anteriores demonstraram que o processamento de campos específicos de uma mensagem HL7 em uma transformação de dados não costuma impactar o desempenho de forma significativa. As transformações feitas nesses testes usaram atribuições bem simples para criar novas mensagens. É importante salientar que processamentos complexos (como o uso de consultas SQL extensivas em uma transformação de dados) podem fazer os resultados variarem.

Testes anteriores também indicaram que o processamento de regras não costuma ser significativo. Os conjuntos de regras de roteamento usados nos testes tiveram uma média de 32 regras, e todas eram simples. É importante salientar que conjuntos de regras extremamente grandes ou complexos podem fazer os resultados variarem. 

Hardware 

Configuração do servidor

Os testes utilizaram um servidor com processadores escaláveis Intel® Xeon® Gold 6252 "Cascade Lake" de 2ª geração, com 48 núcleos de 2,1 GHz em um sistema com 2 soquetes, 24 núcleos por soquete com 192 GB de DR4-2933 DRAM e interface de rede Ethernet de 10 Gbits. Foi usado o sistema operacional Red Hat Enterprise Linux Server 8 para esse teste, com a IRIS for Health 2020.1

Configuração do disco

É feita a persistência completa no disco das mensagens que passam pela IRIS for Health. Nesse teste, duas unidades Intel® Optane™ SSD DC P4800X de 750 GB internas do sistema foram usadas, dividindo-se os bancos de dados em una unidade e os registros de log em outro. Além disso, para garantir uma comparação real, foi ativado o commit síncrono nos registros de log para forçar a durabilidade dos dados. Para a carga de trabalho T4 descrita anteriormente neste documento, cada mensagem HL7 de entrada gera aproximadamente 50 KB de dados, que podem ser divididos conforme indicado na tabela 2. Os diários de transações geralmente são mantidos na linha por menos tempo que os logs ou dados das mensagens, e isso deve ser levado em conta ao calcular o espaço em disco total necessário.

Tabela 2: Requisitos de disco por mensagem HL7 de entrada para carga de trabalho T4  

Lembre-se de que a carga de trabalho T4 usa um mecanismo de roteamento para rotear separadamente mensagens modificadas para cada uma das quatro interfaces de saída. Em média, 4 segmentos da mensagem de entrada foram modificadas em cada transformação (1 entrada para 4 saídas com 4 transformações). Para cada mensagem de entrada, foram executadas quatro transformações de dados, foram enviadas quatro mensagens de saída e foram criados cinco objetos de mensagem HL7 no banco de dados.

Ao configurar sistemas para uso em produção, os requisitos reais devem ser calculados considerando-se os volumes de entrada diários, bem como o agendamento de limpeza de mensagens HL7 e a política de retenção de arquivos de registros de logs. Além disso, é necessário configurar no sistema um espaço adequado para registros de log, para evitar que os volumes de disco de registros de log fiquem cheios. Os arquivos de registros de log devem ficar em discos separados fisicamente dos arquivos de banco de dados, tanto por questões de desempenho quanto de confiabilidade.

Conclusão

A taxa de transferência de mensagens HL7v2 da InterSystems IRIS for Health demonstrada nesses testes ilustra a enorme capacidade de taxa de transferência com uma configuração básica de servidor de prateleira com 2 soquetes para dar suporte a cargas de trabalho de mensagens bastante exigentes de qualquer organização. Além disso, a InterSystems está comprometida a aprimorar constantemente o desempenho e a escalabilidade a cada versão, além de aproveitar os benefícios das tecnologias mais recentes de servidor e nuvem.

O gráfico abaixo apresenta uma visão geral e um comparativo do aumento da taxa de transferência das comparações anteriores do Ensemble 2015.1 e Ensemble 2017.1 com processadores Intel® E5-2600 v3 (Haswell) e a comparação do Ensemble 2017.1 com processadores escaláveis Intel® Platinum Series (Skylake) de 1ª geração em relação aos resultados mais recentes com os processadores escaláveis Intel® Xeon® Gold Series (Cascade Lake) de 2ª geração executando a IRIS for Health 2020.1.

Gráfico 1: Taxa de transferência de mensagens (em milhões) por 10 horas em um único servidor

A InterSystems IRIS for Health continua aumentar a taxa de transferência de interoperabilidade a cada versão, além de oferecer flexibilidade quanto aos recursos de conectividade. Como o gráfico acima mostra, a taxa de transferência de mensagens aumentou significativamente e, com cargas de trabalho T2, dobrou em relação a 2017 e mais que triplicou em relação a 2015 na mesma janela de 10 horas e sustentou mais de 2,3 bilhões de taxas de mensagens em 24 horas.

Outro indicador importante dos avanços da IRIS for Health é a melhoria da taxa de transferência com cargas mais complexas T2 e T4, que incorporam transformações e regras de roteamento, ao contrário da operação única de passagem da carga de trabalho T1.  

A InterSystems está disponível para conversar sobre soluções de acordo com as necessidades de interoperabilidade de sua organização.