Ative a alta disponibilidade de máquina virtual no IBM SmartCloud Enterprise+

HA baseada em SLA para System x e System p na nuvem

A alta disponibilidade (HA) é um recurso essencial da infraestrutura em nuvem. Este artigo resume a abordagem multifacetada adotada pelo IBM SmartCloud Enterprise+ para garantir HA. Também traz detalhes de implementação de HA para máquinas virtuais executadas em plataformas System x® e System p®.

Bhanu P Tholeti, Systems Engineer and Architect, IBM

Bhanuprakash trabalhou no segmento de mercado de software nos últimos oito anos com várias tecnologias e produtos, como desenvolvimento de aplicativos em computadores de bolso, aplicativos com base na web, soluções de fluxo de vídeo e produtos como Tivoli Workload Scheduler, WebSphere Data Interchange, Tivoli Service Automation Manager e Tivoli Provisioning Manager. Como membro do IBM SmartCloud Enterprise, ele obteve grande conhecimento sobre as infraestruturas de nuvem e hypervisors.



K. Sowjanya Chakravarthi, Systems Engineer, IBM

Sowjanya CK trabalhou na IBM nos últimos quatro anos em vários produtos. Participou da migração do Tivoli Provisioning Manager para z/linux, do desenvolvimento do plugin Go Symphony e do desenvolvimento de SCEplus.



08/Out/2012

Alta disponibilidade (HA) — um termo muito associado a soluções de infraestrutura de nuvem — significa essencialmente continuidade de negócios com mínimo tempo de inatividade da máquina. A ativação de HA em qualquer infraestrutura de nuvem deve ter especificamente esses objetivos:

  • Reduzir o tempo de inatividade planejado
  • Evitar tempo de inatividade não planejado
  • Rápida recuperação em caso de indisponibilidade
  • Disponibilidade contínua

Os hypervisors modernos que fundamentam as infraestruturas de nuvem fornecem a maioria dos recursos e funcionalidades que tornam possível obter HA. Este artigo explica brevemente como o IBM SmartCloud Enterprise+ lida com tempo de inatividade planejado e não planejado no servidor, recupera-se de indisponibilidades e garante a disponibilidade contínua do servidor. Em seguida, descreve a implementação de HA no IBM SmartCloud Enterprise+ para máquinas virtuais (VMs) executadas em partições lógicas (LPARs) do VMware e AIX em plataformas IBM System x e System p.

Reduzir o tempo de inatividade planejado

Tempos de inatividade são geralmente planejados para fins de manutenção de software ou releases, upgrades ou reparos planejados em equipamentos. A maioria dos provedores em nuvem planeja tempo de inatividade, mas, como seus negócios se baseiam em fornecer um alto tempo de atividade, essa inatividade é reduzida ao mínimo.

O IBM SmartCloud Enterprise+ tem uma maneira automática de aplicar correções em VMs com atualizações de segurança e de outros tipos no sistema operacional. O software automaticamente implementa as atualizações em ciclos regulares predefinidos — com o cliente determinando o conjunto de VMs que necessita de correções para cada ciclo — sem qualquer intervenção manual. Essa maneira totalmente automática de correção reduz consideravelmente o tempo de inatividade planejado, deixando as VMs disponíveis a maior parte do tempo para obter continuidade de negócios.

Evitar tempo de inatividade não planejado

O tempo de inatividade não planejado em um ambiente de nuvem pode ter várias causas. As principais são falhas na infraestrutura do hypervisor, falhas no sistema operacional e falhas de rede.

O IBM SmartCloud Enterprise+ cuida da maioria dessas falhas com tempo de inatividade mínimo. Como veremos mais adiante, agentes de monitoramento no System x e um daemon nativo no System p podem detectar falhas do SO, enquanto os intervalos de tempo de pulsação do VMware no System x e alguns daemons nativos no System p podem detectar falhas de rede.

Rápida recuperação em caso de indisponibilidade

Em casos de indisponibilidade devido a tempo de inatividade não planejado, o tempo de recuperação depende da natureza da falha. A indisponibilidade pode ser resultada de falhas na plataforma host ou no armazenamento, ou em falhas no sistema operacional ou rede. A indisponibilidade causada por falha na plataforma do host ou no armazenamento pode resultar em uma maior perda de dados e de tempo de execução, caso o provedor em nuvem não tenha se preparado adequadamente para isso.

Mecanismos de failover no IBM SmartCloud Enterprise+ permitem recuperação rápida em casos de falhas de plataforma host ou armazenamento. Toda a carga de trabalho em uma plataforma host com falha é distribuída para outras plataformas host, com tempo de inatividade mínimo. Para lidar com falhas de armazenamento, são usados armazenamentos de dados espelhados. Todos os dados em uma VM são replicados em dois armazenamentos de dados. Se um deles falhar, a VM pode continuar operando com o armazenamento duplicado.

Disponibilidade contínua

A redução do tempo de inatividade planejado e não planejado e a rápida recuperação em caso de indisponibilidade contribuem para a disponibilidade contínua, na qual o servidor (em uma nuvem de plataforma como serviço) está ativo na maior parte do tempo, com tempo de inatividade muito pequeno. A disponibilidade contínua é possível através de:

  • Configuração adequada dos recursos de HA dos hypervisors subjacentes
  • Uso de recursos do sistema operacional para detecção de falha
  • Serviços de monitoramento que podem monitorar a existência de falhas no sistema operacional
  • Monitoramento de aplicativo para verificar se há alta disponibilidade de aplicativos

O IBM SmartCloud Enterprise+ usa a maioria dos recursos de HA fornecidos pelo hypervisor, como mecanismos de failover em plataformas host, prioridade de reinicialização, intervalos de pulsação, detecção de falha e de monitoramento de sistemas operacionais, e detecção de travamento.

HA baseado em SLA

A configuração de HA no IBM SmartCloud Enterprise+ é baseada no acordo de nível de serviço (SLA) que o cliente escolhe para suas VMs particulares. Para VMs nas plataformas System x e System p, o IBM SmartCloud Enterprise+ define quatro níveis de SLA:

  • Platinum
  • Gold
  • Silver
  • Bronze

O SLA Platinum tem a maior configuração de prioridade para reinicialização, com tempos limites mínimos em situações de erro. Gold, Silver e Bronze têm prioridades de reinicialização cada vez menores e maiores tempos limite em situações de erro. O restante deste artigo explica em detalhes essas prioridades e tempos limites. Observação: Os SLAs incluem um componente de infraestrutura, além de um componente de VM. Este artigo aborda apenas o componente de VM.

Ativando HA para System x

O recurso de alta disponibilidade do VMware vSphere (HA do VMware) no IBM SmartCloud Enterprise+ permite configuração automática de HA para VMs fornecidas no IBM System x. Seus dois principais recursos são a prioridade de reinicialização e a pulsação.

Prioridade de reinicialização

Os valores de prioridade de reinicialização de VM solucionam a contenção de recursos. A prioridade determina a preferência que a HA do VMware dá a uma VM se não houver capacidade suficiente disponível para ativar todas as VMs com falha. As VMs de alta prioridade em um host têm preferência sobre as VMs de baixa prioridade.

Os parâmetros válidos para uma configuração de HA para uma única VM são disable, high, medium e low.

Intervalo de tempo de pulsação

O recurso de monitoramento de funcionamento de VM do VMware no IBM SmartCloud Enterprise+ sempre verifica a resposta dos serviços de pulsação de uma VM, que são executados nas ferramentas do VMware de cada VM em um determinado host. Se o serviço de pulsação não responder ao serviço de monitoramento de funcionamento dentro de um intervalo de tempo configurável, o sistema tem uma VM com falha, e a ação correspondente de reconfiguração será realizada.

Quanto menor o valor de um intervalo de tempo limite de pulsação, mais rápido a VM reinicia. O SLA Platinum tem o menor intervalo para esse período, seguido por Gold, Silver e Bronze.

A Tabela 1 mostra a prioridade de reinicialização e valores de pulsação configurados para cada nível de SLA:

Tabela 1. Prioridades de reinicialização e valores de pulsação para VMs no System x
SLAPrioridade de reinicializaçãoIntervalo do tempo limite de pulsação (segundos)*
Platinumhigh30
Goldmedium60
Silverlow120
Bronzelow180

*A IBM recomenda esses valores. Os fornecedores, administradores em nuvem ou usuários podem ajustar os intervalos de tempo limite, dependendo do ambiente prevalecente e das condições de carga de trabalho.

Além das configurações na Tabela 1, as VMs Platinum recebem espaço nos armazenamentos de dados, que proporcionam disponibilidade contínua das VMs mesmo em caso de falha dos dispositivos de armazenamento.

Implementação com APIs do VMware vSphere

A VMware fornece APIs do vSphere, flexíveis e fáceis de usar, para configurar programaticamente as definições de configuração de HA necessárias.

Para configurar a prioridade de reinicialização, o IBM SmartCloud Enterprise+ usa a API reconfigureComputeResource_Task e alguns objetos de dados do vSphere. O segmento de código na Listagem 1 mostra que o objeto de dados ClusterConfigSpecEx é passado para o método reconfigureComputeResource_Task da interface VIPort:

Listagem 1. Configurando a prioridade de reinicialização programaticamente
// Initialize the ClusterConfigSpceEx data object and subobjects 
// required for enabling restart priority.
ClusterConfigSpecEx spec = new ClusterConfigSpecEx();
ClusterDasVmConfigSpec[] clusterDasVmConfigSpec = new ClusterDasVmConfigSpec[1];
clusterDasVmConfigSpec[0] = new ClusterDasVmConfigSpec();
spec.setDasVmConfigSpec(clusterDasVmConfigSpec);
ClusterDasVmConfigInfo clusterDasVmConfigInfo = new ClusterDasVmConfigInfo();
clusterDasVmConfigSpec[0].setInfo(clusterDasVmConfigInfo);
ArrayUpdateOperation arrayUppdateSpec = ArrayUpdateOperation.add;
clusterDasVmConfigSpec[0].setOperation(arrayUppdateSpec);

// VM managed object reference (MOR) must be provided as a key for ClusterDasVmConfigInfo.
clusterDasVmConfigInfo.setKey(VM MOR);

// Set the restart priority for the VM
ClusterDasVmSettings clusterDasVmSettings = new ClusterDasVmSettings();
clusterDasVmConfigInfo.setDasSettings(clusterDasVmSettings);

// Restart priority value is obtained from the SLA (see Table 1). 
clusterDasVmSettings.setRestartPriority(restartPriority based on SLA);
ManagedObjectReference taskMor 
   = con._service.reconfigureComputeResource_Task(clsMor, spec, true);

A configuração do intervalo de pulsação também usa a API reconfigureComputeResource_Task e alguns objetos de dados do vSphere. O segmento de código na Listagem 2 mostra o objeto de dados ClusterConfigSpecEx sendo passado para o método reconfigureComputeResource_Task da interface VIPort:

Listagem 2. Configurando o intervalo de pulsação programaticamente
// Initialize the ClusterConfigSpceEx data object and subobjects
//  required for enabling the heartbeat interval.
ClusterConfigSpecEx spec = new ClusterConfigSpecEx();
ClusterDasVmConfigSpec[] clusterDasVmConfigSpec = new ClusterDasVmConfigSpec[1];
clusterDasVmConfigSpec[0] = new ClusterDasVmConfigSpec();
spec.setDasVmConfigSpec(clusterDasVmConfigSpec);
ClusterDasVmConfigInfo clusterDasVmConfigInfo = new ClusterDasVmConfigInfo();
clusterDasVmConfigSpec[0].setInfo(clusterDasVmConfigInfo);
ArrayUpdateOperation arrayUppdateSpec = ArrayUpdateOperation.add;
clusterDasVmConfigSpec[0].setOperation(arrayUppdateSpec);

// VM managed object reference (MOR)must be provided as a key for ClusterDasVmConfigInfo.
clusterDasVmConfigInfo.setKey(VM MOR);

// Set the heartbeat interval for the VM.
ClusterDasVmSettings clusterDasVmSettings = new ClusterDasVmSettings();
clusterDasVmConfigInfo.setDasSettings(clusterDasVmSettings);
ClusterVmToolsMonitoringSettings clusterVmToolsMonitoringSettings = 
   new ClusterVmToolsMonitoringSettings();
clusterDasVmSettings.setVmToolsMonitoringSettings(clusterVmToolsMonitoringSettings);

// Heartbeat interval is obtained from the SLA (see Table 1) 
clusterVmToolsMonitoringSettings.setFailureInterval(heartBeatInterval based on SLA);
ManagedObjectReference taskMor 
   =con._service.reconfigureComputeResource_Task(clsMor, spec, true);

Ativando HA para System p

As propriedades que permitem HA no System p são detecção de interrupção por prioridade, detecção de interrupção de E/S perdida e detecção de travamento.

A Tabela 2 mostra os valores configurados para esses recursos de HA em cada SLA:

Tabela 2. Configurações de SLA para propriedades de ativação de HA no System p
SLATempo limite de problema de prioridade (segundos)*Tempo limite de E/S perdida (segundos)*Detecção de travamento
Platinum1020enable
Gold2040enable
Silver3560enable
Bronze60180enable

*A IBM recomenda esses valores. Os fornecedores, administradores em nuvem ou usuários podem ajustar os intervalos de tempo limite, dependendo do ambiente prevalecente e das condições de carga de trabalho.

Detecção de interrupção por prioridade

Todos os processos (também chamados de encadeamentos) são executados com uma certa prioridade. Essa prioridade está na faixa de 0-126, com 0 sendo a maior prioridade e 126, a menor. A prioridade padrão para todos os encadeamentos é 60. Qualquer usuário pode diminuir a prioridade de um processo, usando o comando nice. Qualquer pessoa com propriedade de administrador também pode aumentar a prioridade de um processo.

O planejador do kernel sempre escolhe o encadeamento executável com maior prioridade para colocar em um CPU. Portanto, é possível que um número suficiente de encadeamentos de alta prioridade ocupe totalmente a máquina, de modo que aqueles de menor prioridade nunca são executados. Se os encadeamentos em execução tiverem uma prioridade acima do valor padrão de 60, isso pode bloquear todos os shells e logins normais, a ponto de parecer que o sistema caiu. O recurso de detecção de queda do sistema é um mecanismo para detectar essa situação e dar ao administrador do sistema um meio de recuperação. Esse recurso é implementado como um daemon (shdaemon) que é executado na maior prioridade de processo. Esse daemon consulta o kernel para saber qual foi o encadeamento de menor prioridade executado em um intervalo específico. Se a prioridade desse encadeamento estiver acima de um limite configurado, o daemon pode realizar uma de várias ações. Cada uma dessas ações pode ser ativada independentemente, para ser acionada em qualquer prioridade e em qualquer intervalo de tempo.

A detecção de queda do sistema é configurada no IBM SmartCloud Enterprise+ com uma ação de reinicialização do sistema usando o comando shconf:

$: shconf -l pio -a pp_reboot=enable -a pp_rto=priority hang timeout based on SLA

Detecção de interrupção de E/S perdida

O AIX também pode detectar condições de interrupção de E/S e tentar recuperar-se delas, com base em ações definidas pelo usuário.

Erros de E/S podem fazer com que o caminho de E/S fique bloqueado, afetando ainda mais a E/S no caminho. Nessas circunstâncias, é essencial que o sistema operacional alerte o usuário e execute ações definidas por ele. Como parte da detecção e notificação de E/S perdida, o shdaemon— com a ajuda do Gerenciador de Volume Lógico — monitora o buffer de E/S por um certo período e verifica se alguma E/S está pendente por tempo demais. Se o tempo de espera exceder o limite definido no arquivo shconf, um E/S perdido é detectado e outras medidas são tomadas. As informações sobre a E/S perdida são documentadas no log de erro. Também com base nas configurações do arquivo shconf, o sistema pode ser reinicializado para recuperar-se da situação de E/S perdida.

A detecção de interrupção de E/S perdida é configurada no IBM SmartCloud Enterprise+ com uma ação para reinicializar o sistema, através do comando shconf:

$: shconf -l lio -a lio_reboot=enable -a lio_to=Lost I/O timeout based up on SLA

Detecção de travamento

Se o sistema operacional travar, uma reinicialização automática deve ser ativada, para fins de continuidade. A detecção de travamento no IBM SmartCloud Enterprise+ ativa a reinicialização usando o comando chdev, que altera a propriedade do dispositivo de objeto do sistema chamada autorestart para true.

$: chdev -l sys0 -a autorestart=true

Conclusão

Os recursos de HA discutidos neste artigo fazem do IBM SmartCloud Enterprise+ uma das mais confiáveis ofertas de nuvem no mercado corporativo, sempre prometendo continuidade de negócios. Caso os requisitos de HA da empresa mudem, é fácil passar de um nível de SLA menor para um maior.

Recursos

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing
ArticleID=839049
ArticleTitle=Ative a alta disponibilidade de máquina virtual no IBM SmartCloud Enterprise+
publish-date=10082012