BR112016013559B1

BR112016013559B1 - Método e sistema de computador para preservar memória virtual

Info

Publication number: BR112016013559B1
Application number: BR112016013559-8A
Authority: BR
Inventors: Mark E. Russinovich
Original assignee: Microsoft Technology Licensing, Llc
Priority date: 2013-12-20
Filing date: 2014-12-18
Publication date: 2022-02-22
Also published as: BR112016013559A8; US9875115B2; BR112016013559A2; CN105830020B; WO2015095427A1; EP3084595A1; CN105830020A; EP3084595B1; US20150178097A1

Abstract

REINICIALIZAÇÃO PRESERVANDO MEMÓRIA. A presente invenção refere-se a técnicas para preservar o estado de aplicativo em memória virtual durante a reinicialização do sistema operacional. Uma alocação de memória virtual preservada que foi preenchida com estado por um aplicativo é identificada. O aplicativo é desligado durante a reinicialização do OS. O sistema operacional é reinicializado sem modificar a alocação de memória virtual preservada. Por exemplo, memória física e páginas de arquivo de paginação associadas com a alocação de memória virtual preservada no sistema de computação não são modificadas quando o sistema operacional é reinicializado. O aplicativo é reiniciado após o sistema operacional ter sido reinicializado. As alocações de memória virtual preservadas são identificadas após o aplicativo ser reiniciado, tal como por verificar conteúdos de uma região da memória ou por um valor de retorno de API. Então, o aplicativo é reconectado com a alocação de memória virtual preservada, o que permite ao aplicativo imediatamente acessar o estado preservado sem ter que reconstruir novo estado.

Description

ANTECEDENTES

[001] As reinicializações do sistema operacional perturbam os aplicativos por causar que os mesmos fiquem inativos e por destruir estados derivados e colocados em memória cache que eles mantêm na memória virtual, desse modo degradando sua performance. Reinicializar um sistema operacional envolve desligar o sistema operacional em funcionamento e imediatamente iniciar o mesmo. Existem várias razões para reinicializar um sistema operacional. Por exemplo, a manutenção e atualização de hardware tipicamente requerem que o sistema operacional esteja off-line antes do hardware poder ser modificado. Mais frequentemente, uma reinicialização é requerida para aplicar atualizações de código e de configuração, o sistema operacional não pode adotar estas atualizações sem reinicialização.

[002] Reinicializar o sistema operacional perturba os aplicativos executando no sistema, os quais devem fechas as conexões cliente, confirmar seu estado para armazenamento, e desligar. Durante o reinício, estes aplicativos então devem restaurar seu estado, reconstruir caches de memória, e reiniciar a aceitação das conexões cliente. Estas perturbações são aumentadas em um ambiente virtualizado devido a afetar não somente os aplicativos operando em uma partição hospedeira, mas também os aplicativos executando nas máquinas virtuais hospedadas.

[003] Durante uma reinicialização, o aplicativo executando em uma máquina virtual ficará off-line durante o tempo requerido para: desligar a máquina virtual, desligar o hospedeiro, executar Autoanálise de ativação (POST) de firmware, inicializar o hospedeiro, inicializar a máquina virtual, e inicializar o aplicativo. Em alguns casos, a duração desta interrupção pode ser na ordem de trinta minutos ou mais. Se um Contrato de Nível de Serviço (SLA) exigir uma disponibilidade específica para o aplicativo, o tempo inativo causado por reinicializações do sistema operacional hospedeiro irá consumir pelo menos uma parte da quantidade de tempo inativo do SLA. Isto levará a menos tempo na quantidade de tempo inativo do SLA para interrupções não planejadas, as quais são imprevisíveis em termos de frequência e duração.

[004] Para abrandar o impacto de reinicializações causadas no hospedeiro em relação às máquinas virtuais, a maior parte das plataformas de virtualização em pequena escala tem implementado migração ao vivo, a qual permite que as máquinas virtuais diretamente se movam de um servidor para outro de modo a evitar uma reinicialização planejada do hospedeiro. As desvantagens da migração ao vivo são que ela adiciona complexidade significativa para o gerenciamento do sistema como um todo, apresenta uma sobrecarga em relação aos recursos de interoperabilidade, e estende o tempo requerido para aplicar atualizações. Reinicializar um grupo de servidores requer migrar cada máquina virtual pelo menos uma vez. Além disso, a não ser que um servidor vazio seja emparelhado com cada servidor hospedando máquinas virtuais que serão migradas, a migração de máquinas virtuais se torna um jogo de ladrilho aleatório e atualização do servidor pode se tornar uma operação serial.

[005] Suspender - Atualizar - Reiniciar Máquina Virtual (VM- SUR) é uma alternativa a desligar máquinas virtuais baseado na tecnologia existente de máquina virtual. Com esta abordagem, o OS hospedeiro suspende máquinas virtuais, salva seu estado (incluindo RAM e CPU virtual) para o disco, reinicia o servidor dentro do OS hospedeiro atualizado, e então reinicia as máquinas virtuais. Isto permite que as máquinas virtuais retenham suas caches em memória e evita que as máquinas virtuais desliguem e religuem. A deficiência da VM-SUR é que a RAM de todas as máquinas virtuais hospedada em um servidor deve ser lida e gravada junto ao armazenamento local como parte da atualização do OS hospedeiro, tempo durante o qual as máquinas virtuais ficam suspensas. Utilizando números aproximados que refletem o hardware em nuvem contemporâneo, o salvamento e a restauração de 100 GB de RAM para armazenamento local que produz taxa efetiva de dados de 100 MB/S levaria ao redor de trinta minutos. Esta interrupção não é melhor do que a causada por um desligamento / reinício típico e apesar de as máquinas virtuais reterem suas caches, o tempo inativo seria longo o suficiente para causar uma interrupção visível para máquinas virtuais de instância única.

SUMÁRIO

[006] Este Sumário é proporcionado para introduzir uma seleção de conceitos em uma forma simplificada, os quais são adicionalmente descritos abaixo na Descrição Detalhada. Este Sumário não é pretendido para identificar aspectos chave ou aspectos essenciais do assunto reivindicado, nem é pretendido para ser utilizado para limitar o escopo do assunto reivindicado.

[007] Concretizações da invenção utilizam suporte do sistema operacional para reinicialização com memória persistente. O suporte consiste de dois mecanismos, ambos contribuindo para a redução do impacto de reinicializações. O primeiro mecanismo é saltar o POST de firmware, o que pode ser um contribuinte significativo para o tempo de reinicialização e em ambientes físicos pode ativar falhas de hardware. O segundo mecanismo é permitir aos aplicativos preservarem estados especificados na memória através de uma reinicialização. Juntos, estes aprimoramentos são referidos neste documento como Reinicialização com Preservação de Memória (MPR). Estes mecanismos podem dramaticamente reduzir o tempo inativo do aplicativo e a degradação de performance que é causada pelas reinicializações, particularmente para aplicativos de base de dados, científicos e outros aplicativos com grande uso de memória. A MPR também aprimora a utilização de recurso do sistema e reduz o custo de operações.

[008] Em uma concretização ilustrativa, sistemas e métodos para preservar memória virtual em um sistema de computador identificam uma alocação de memória virtual preservada onde a alocação de memória virtual preservada foi preenchida com estado por um aplicativo. A alocação de memória virtual preservada pode ser identificada pelo aplicativo utilizando uma API para selecionar memória virtual persistente com reinicialização. O aplicativo é desligado como parte de uma reinicialização de OS. O sistema operacional então é reinicializado sem modificar a alocação de memória virtual preservada. Por exemplo, memória física e páginas de arquivo de paginação associadas com a alocação de memória virtual preservada no sistema de computador ficam inalteradas quando o sistema operacional é reinicializado. O aplicativo é reiniciado após o sistema operacional ter sido reinicializado. As alocações de memória virtual preservadas são identificadas após o aplicativo ser reiniciado, tal como por verificar conteúdos de uma região da memória ou por um valor de retorno de API. O aplicativo então é reconectado com a alocação de memória virtual preservada, o que permite ao aplicativo imediatamente acessar o estado preservado sem ter que reconstruir o novo estado.

BREVE DESCRIÇÃO DOS DESENHOS

[009] Para adicionalmente esclarecer as vantagens e aspectos acima e outros das concretizações da presente invenção, uma descrição mais particular de concretizações da presente invenção será fornecida por referência aos desenhos anexos. É apreciado que estes desenhos representam somente concretizações típicas da invenção e, portanto, não são para ser considerados limitando seu escopo. A invenção será descrita e explicada com especificidade e detalhes adicionais através do uso dos desenhos acompanhantes, nos quais:

[0010] A figura 1 ilustra o Impacto da Reinicialização sobre a Performance do Aplicativo, o impacto de uma reinicialização de OS sobre a performance de um aplicativo de Bse de dados.

[0011] As figuras 2A até 2C ilustram a preservação de RAM física designada para máquinas virtuais através de reinicializações de hospedeiro.

[0012] A figura 3 ilustra o impacto reduzido de uma reinicialização quando um aplicativo tira vantagem de Reinicialização com Preservação de Memória.

[0013] A figura 4A até 4C ilustram o comportamento básico de memória virtual preservada.

[0014] A figura 5 é um fluxograma ilustrando um processo ou método para atualizar um sistema operacional hospedeiro enquanto preservando as máquinas virtuais executando em um servidor hospedeiro.

[0015] A figura 6 é um fluxograma ilustrando um processo ou método para atualizar um sistema operacional hospedeiro enquanto preservando as máquinas virtuais executando em um servidor hospedeiro.

[0016] A figura 7 ilustra um exemplo de um ambiente de computação e de interoperabilidade para atualizar um sistema operacional hospedeiro de acordo com uma concretização.

DESCRIÇÃO DETALHADA

[0017] Para minimizar o impacto de uma reinicialização de sistema operacional ("OS"), dois mecanismos são utilizados juntos para permitir aos aplicativos preservarem estado em memória virtual ou física durante a reinicialização. O primeiro mecanismo é uma reinicialização leve do sistema operacional. Este mecanismo é revelado no Pedido de Patente US 14/379.972 para "Virtual MachinePreserving Host Updates", depositado em 4 de dezembro de 2012. O segundo mecanismo inclui serviço do OS que permite aos aplicativos especificarem partes de memória que devem ser preservadas intactas durante uma reinicialização e que permite aos aplicativos utilizarem a memória preservada após uma reinicialização.

[0018] Os computadores devem reinicializar por várias razões. Algumas alterações de hardware precisam um reinício do hardware físico no qual o OS está executando. Mais frequentemente, as reinicializações de OS ocorrem devido às atualizações do OS ou do aplicativo exigirem reiniciar a execução a partir de um estado inicial para aplicar as atualizações. Exemplos típicos de tais atualizações incluem atualizações para os componentes principais do OS, as quais podem adicionar nova funcionalidade ou reparar erros de segurança, e alterações de configuração. Em vários casos, a complexidade requerida para manter a consistência de um estado de um componente atualizando, especialmente apesar de o mesmo continuar a oferecer serviço para componentes dependentes, sobrepuja os benefícios de suportar atualizações online. Independente do fato de que as reinicializações são perturbadoras para aplicativos e usuários finais, elas não podem ser eliminadas.

[0019] As reinicializações de OS interrompem os aplicativos de dois modos principais. Primeiro, as reinicializações causam que o aplicativo fique inativo. A duração de uma interrupção de reinicialização para um aplicativo inclui o tempo requerido para desligar o aplicativo, desligar o OS, fazer o POST de firmware, reinicializar o OS, e reiniciar o aplicativo. Mesmo se este tempo inativo puder ser minimizado ou mesmo reduzido para zero, os aplicativos perdem todos os estados gerados, derivados, e colocados em cache que estão armazenamentos somente na memória virtual. Isto causa uma segunda interrupção após o aplicativo ser reiniciado. Pode ser possível que um aplicativo rapidamente regenere seu estado após o reinício, mas vários aplicativos requerem um período estendido e várias transações para reconstruir o estado. Se o estado do aplicativo for pequeno em relação à velocidade de armazenamento persistente, um aplicativo pode preservar seu estado por serializar o estado para armazenamento durante o desligamento da reinicialização e então retirar a serialização do estado após o reinício. Quando o estado do aplicativo é grande em relação à velocidade de armazenamento persistente, entretanto, o tempo permitido pelo OS para o aplicativo desligar pode não permitir a serialização do estado para armazenamento. Mesmo se fornecido tempo suficiente, a degradação de performance incorrida durante a serialização e a retirada de serialização subsequente pode ser significativo e efetivamente causar que um aplicativo e seus clientes experimentem efeitos negativos de uma reinicialização durante dezenas de minutos ou mesmo horas depois.

[0020] A figura 1 ilustra o Impacto da Reinicialização sobre a Performance do Aplicativo e o impacto da reinicialização do OS sobre a performance de um aplicativo de base de dados. Neste exemplo, um aplicativo de base de dados executa em um servidor com uma grande quantidade de RAM e com armazenamento durável relativamente lento. Após operar durante algum tempo 101, o aplicativo preencheu totalmente a RAM com seu estado de base de dados colocado em cache e obteve performance ideal. Então, uma atualização do OS é implementada, a qual requer que o servidor reinicialize (ou pode apenas requerer que o aplicativo de base de dados desligue e reinicie). Neste cenário, não existe ponto no aplicativo de base de dados serializando o estado colocado em cache devido ao mesmo poder recriar o estado da cache a partir de bases de dados fonte. Por consequência, o aplicativo confirma as transações existentes e rapidamente desliga 102 e limpa sua cache 103. Então, o OS desliga após os aplicativos terem fechado 104. O firmware do servidor reinicializa 105 antes do OS reiniciar 106. Uma vez que o OS tenha reiniciado, o aplicativo pode reiniciar 107. A reinicialização leva algum tempo, durante o qual os clientes não podem acessar a base de dados, e o aplicativo inicia sem nenhum dado colocado em cache. Quando o aplicativo tiver reiniciado e estiver novamente executando 08, ele não sabe quais acessos de cliente irão surgir no futuro, e ele deve reconstruir a cache de base de dados 109. Durante esta reconstrução, a maior parte dos acessos não irá encontrar a cache e as resposta do aplicativo será lenta. Somente após executar novamente durante horas após o reinício, o aplicativo irá construir a cache novamente para obter seu nível de performance de pré- reinicialização. Em alguns cenários, pode ser possível que um aplicativo rapidamente regenere o estado após o reinício. Como resultado, a duração real da interrupção da reinicialização 110 é mais longo do que o tempo que o aplicativo estava off-line.

[0021] Quando eles tiverem que reinicializar, a base de dados e outros aplicativos de colocação em cache perdem estado que é persistido em qualquer outro lugar. Aplicativos de computação científicos e financeiros que executam cálculos em execuções longas e geram grandes quantidades de estado intermediário sofrem mais impacto do que outros aplicativos, devido, em adição a terem que ler novamente potencialmente grandes quantidades de dados, estes aplicativo também devem refazer cálculos onerosos a partir do início ou pelo menos a partir de um ponto de verificação anterior.

[0022] Reduzir o impacto de uma reinicialização sobre aplicativos requer reduzir a duração de interrupção de reinício, mas o impacto também pode ser reduzido por permitir aos aplicativos preservarem o estado derivado e colocado em cache durante as reinicializações. A Reinicialização Preservando Memória (MPR) pode ser utilizada para reduzir a interrupção da reinicialização e para prolongar a saúde do hardware por evitar a POST. A MPR utiliza serviços propostos do OS para preservar o estado do aplicativo armazenado em memória virtual durante as reinicializações.

Evitando POST

[0023] Os desenvolvedores de OS irão continuar a aprimorar a performance do OS e dos aplicativos durante o desligamento e o reinício; entretanto, evitar a POST de firmware irá produzir aprimoramentos imediatos e duráveis. A reinicialização de firmware 105 pode introduzir atraso significativo para o processo de reinicialização, especialmente para enumerações lentas de barramento. O reinício acompanhante do hardware pode levar o hardware além de um limite de falha. A VM-PHU introduz uma nova capacidade, chamada de Reinicialização Suave de Kernel (KSR), para desligar o OS até uma ponta carregadora e então reiniciar código do OS atualizado e a configuração, desse modo completamente saltando a POST de firmware. A VM-PHU é projetada para implementação de OS baseada em imagem, de modo que a reinicialização é executada em um novo disco rígido virtual de OS (VHD). A KSR irá funcionar para atualizações baseadas em componente, onde o carregador reinicializa de novo para a mesma instalação de OS atualizada.

Preservando Memória durante Reinicializações

[0024] Apesar de a KSR poder reduzir o tempo inativo do aplicativo durante a reinicialização requerendo atualizações de OS, ela não endereça a perda de estado do aplicativo. Omitir a POST permite a preservação da RAM durante reinicializações, o que foi o que motivou o desenvolvimento da KSR no contexto de VM-PHU. A VM- PHU preserva a RAM física designada para máquinas virtuais durante reinicializações de hospedeiro, como ilustrado nas figuras 2A até 2C.

[0025] A figura 2A ilustra um servidor 201 hospedando uma ou mais máquinas virtuais (VM) 202. O servidor 201 está executando um OS ativo do hospedeiro 203, o qual suporta máquinas virtuais 202. O sistema operacional ativo do hospedeiro 203 mantém um estado atual 204 para cada máquina virtual. A VM-PHU minimiza o tempo inativo da máquina virtual 202 durante atualizações do sistema operacional ativo hospedeiro por deixar as máquinas virtuais 202 intactas e suspender as mesmas somente o tempo suficiente para reiniciar um sistema operacional hospedeiro atualizado.

[0026] Na figura 2B, uma imagem do sistema operacional hospedeiro atualizado (OS Hospedeiro Atualizado) 205 foi armazenada na memória 206. O sistema operacional hospedeiro ativo 203 congela as máquinas virtuais 202, mas deixa as mesmas residentes na RAM no servidor 201. O sistema operacional hospedeiro ativo 203 grava as alocações e os estados de VM 204 para as máquinas virtuais 202 junto à RAM e/ou junto ao armazenamento local 206 como estados VM 207. O sistema operacional hospedeiro ativo 203 desliga como parte da atualização do sistema operacional e transfere a execução para o carregador 208.

[0027] Na figura 2C, o carregador 208 apaga o sistema operacional hospedeiro ativo 203 que lê o kernel do sistema operacional hospedeiro atualizado 205 para dentro a RAM. Adicionalmente, o carregador 208 passa uma invocação a partir do sistema operacional ativo 203 para o sistema operacional hospedeiro atualizado 205, a qual inclui um mapa de alocação para as máquinas virtuais 202 junto com instruções para reiniciar as máquinas virtuais 202. O carregador 208 transfere a execução para o ponto de entrada do sistema operacional hospedeiro atualizado 205. Após o sistema operacional hospedeiro atualizado 205 inicializar, ele carrega os estados VM 207 para as máquinas virtuais 202 e reinicia as mesmas. A técnica VM-PHU evita a pressão sobre o servidor 201 causada por reinícios de hardware, e, portanto, prolonga a vida útil do servidor 201.

[0028] A duração da interrupção experimentada pelas máquinas virtuais hospedadas 202 quando a técnica VM-PHU é empregada é limitada ao tempo levado para desligar o sistema operacional ativo 203 e então carregar e iniciar o sistema operacional hospedeiro atualizado 205. A técnica VM-PHU salta a POST de firmware e evita desligamento e reinício da máquina virtual 202. Os aplicativos executando nas máquinas virtuais 202 não perdem seu estado ou caches. Se o sistema operacional hospedeiro atualizado 205 for carregado rápido o suficiente, então a interrupção pode ser curta o suficiente de modo que os aplicativos executando nas máquinas virtuais 202 e seus respectivos clientes não fiquem cientes da interrupção. Ao invés disso, os clientes dos aplicativos de máquina virtual podem perceber o que parece ser um longo defeito da rede, o qual todos os clientes de rede já estão acostumados a lidar. Se a interrupção da máquina virtual for curta o suficiente, tal como menos do que trinta segundos, tempos limites de sondas padrão de equilíbrio de carga não irão ativar, desse modo mantendo as máquinas virtuais 202 em rotação para coletar trabalho assim que elas reiniciarem.

[0029] Utilizando esta mesma capacidade de preservação de RAM, um gerenciador de memória do OS pode expor uma API que irá alocar memória virtual que se preservou durante uma reinicialização. Então, os aplicativos podem seletivamente gerenciar seu estado por alavancar o suporte de preservação para estado que é oneroso para regenerar ou para persistir para armazenamento. A combinação de salto de POST e de preservação de memória define a Reinicialização com Preservação de Memória (MPR).

[0030] A figura 3 ilustra o impacto reduzido de uma reinicialização sobre o mesmo aplicativo de base de dados descrito na figura 1 quando o aplicativo tira vantagem da MPR. Como ilustrado na figura 3, o atraso da reinicialização de firmware é eliminado utilizando a técnica VM-PHU, o que permite que o aplicativo reinicie mais rápido. Além disso, a interrupção de reinicialização 301 é minimizada por preservar a memória cache, o que permite que a performance do aplicativo 302 rapidamente retorne para níveis pré-reinicialização 103.

[0031] É observado que a MPR introduz complexidade para aplicativos que utilizam a mesma. Os aplicativos devem garantir que o estado que eles preservam defina uma conclusão. Se o estado preservado possuir quaisquer referências ao estado que não sejam preservadas (por exemplo, por embutir ponteiros para estruturas de dados que foram alocadas na memória que não foi preservada), então, somente parte do estado será preservado e o aplicativo é provável de falhar após a reinicialização. Os aplicativos que optam em utilizar a MPR irá conter custos adicionais para manter e testar a conclusão de seus dados preservados.

Preservação de Memória Física e Virtual

[0032] Existem pelo menos dois modos para implementar a preservação de memória. Uma abordagem utilizando o OS Windows® da Microsoft Corporation, os processos podem utilizar APIs, chamadas de Address Windowing Extensions (AWE), para alocar RAM. Estas APIs podem ser aprimoradas para oferecer um modo de preservação de reinicialização. Entretanto, existem várias desvantagens em contar com esta API para funcionalidade de preservação de reinicialização. Uma consideração é que as AWE APIs removem a memória do gerenciamento do OS, desse modo impedindo o OS de utilizar sua visão global para melhor decidir quais dados devem ser armazenados na RAM em relação a serem paginados para fora do disco. Outra consideração é que as AWE APIs requerem um privilégio de conta que não é concedido para contas de usuários por condição preestabelecida, desse modo requerendo uma configuração e conta não padrão. A razão para isso é que dedicar recursos físicos fixos para um aplicativo específico pode degradar a performance não somente de outros aplicativos, mas do próprio OS. Além disso, é mais fácil para os aplicativos utilizarem a abstração de memória virtual, não a memória física diretamente.

[0033] Uma segunda abordagem é mais flexível, porém mais complexa e envolve oferecer para os aplicativos uma API para memória virtual persistente na reinicialização. Uma API de preservação de memória virtual obteria um único identificador de aplicativo, por exemplo, um designado pelo OS quando um processo se registra com o mesmo, bem como um identificador selecionado pelo aplicativo para cada região de memória virtual que o aplicativo deseja preservar. Estas solicitações de alocação retornariam um ponteiro de memória virtual da mesma forma que as APIs de alocação padrão. Os aplicativos iriam interagir com a memória do mesmo modo e com as mesmas API que eles utilizariam para a memória virtual padrão.

[0034] Um aplicativo não precisaria implementar lógica especial em relação à reinicialização diferente de detectar, pelo valor de retorno da API ou por verificar o conteúdo da região de memória de uma região que foi preservada a partir da reinicialização anterior. Por exemplo, a memória virtual inicializada é preenchida com zeros de modo que um valor de um byte no início da região é um indicador suficiente de que a região foi preservada. Quando uma região contém conteúdos preservados, um aplicativo pode imediatamente acessar o estado armazenado dentro da mesma.

[0035] As figuras 4A até 4C ilustram o comportamento básico de memória virtual preservada. Na figura 4A, a RAM 401 e o arquivo de paginação 402 foram preenchidos com o aplicativo 403, com o OS 404 e com o Carregador 405. O aplicativo 403 fez uma alocação de memória virtual preservada 406 e preencheu a mesma com o estado. Na figura 4B, o aplicativo 403 e o sistema operacional 404 desligaram para parte carregadora 405, deixando a memória física 01 e as páginas do arquivo de paginação 402 associadas com a memória virtual 406 não perturbadas. Na figura 4C, o aplicativo 403' reiniciou e foi reconectado com a memória preservada 406 e com seu conteúdo pelo sistema operacional atualizado 404'.

[0036] A figura 5 é um fluxograma ilustrando um método para preservar memória virtual em um sistema de computador de acordo com uma concretização. Na etapa 501, uma alocação de memória virtual preservada é identificada. A alocação de memória virtual preservada foi preenchida com o estado por um aplicativo. A alocação de memória virtual preservada pode ser identificada pelo aplicativo utilizando uma API para selecionar a memória virtual persistente durante a reinicialização. Na etapa 502, o aplicativo é desligado.

[0037] Na etapa 503, o sistema operacional no sistema de computador é reinicializado sem modificar a alocação de memória virtual preservada. Por exemplo, a memória física associada com a alocação de memória virtual preservada no sistema de computador pode não ser modificada quando o sistema operacional é reinicializado. Adicionalmente, as páginas do arquivo de paginação associadas com a alocação de memória virtual preservada no sistema de computador podem não ser modificadas quando o sistema operacional é reinicializado.

[0038] Na etapa 504, o aplicativo então é reiniciado após o sistema operacional ter sido reinicializado. Na etapa 505, as alocações de memória virtual preservadas são identificadas após o aplicativo ser reiniciado. As alocações de memória virtual preservadas podem ser identificadas pela verificação de conteúdos de uma região da memória ou por um valor de retorno de API. Na etapa 506, o aplicativo é reconectado com a alocação e memória virtual preservada, o que permite ao aplicativo imediatamente acessar o estado preservado em ter que reconstruir novo estado.

[0039] A figura 6 é um fluxograma ilustrando um processo ou método para atualizar um sistema operacional hospedeiro enquanto preservando as máquinas virtuais executando em um servidor hospedeiro. Na etapa 601, um sistema operacional hospedeiro atualizado é copiado para a RAM ou para o armazenamento local no servidor. Na etapa 602, o sistema operacional hospedeiro ativo congela as máquinas virtuais atualmente executando no servidor. Na etapa 603, o sistema operacional hospedeiro ativo grava alocações e estados para as máquinas virtuais junto à RAM ou ao armazenamento local. Na etapa 604, o sistema operacional hospedeiro ativo então se desliga e transfere a execução para um aplicativo carregador.

[0040] Na etapa 605, o carregador lê o kernel do sistema operacional hospedeiro atualizado para a RAM. Na etapa 606, a invocação a partir do sistema operacional hospedeiro ativo passa um mapa de alocação para as máquinas virtuais para o sistema operacional hospedeiro atualizado junto com instruções para reiniciar as máquinas virtuais. Na etapa 607, a execução é transferida a partir do carregador para o ponto de entrada do sistema operacional hospedeiro atualizado.

[0041] Na etapa 608, o sistema operacional hospedeiro atualizado é inicializado. Finalmente, na etapa 609, o sistema operacional hospedeiro atualizado carrega os estados das máquinas virtuais e reinicia as máquinas virtuais.

[0042] A figura 7 ilustra um exemplo de um ambiente de computação e de interoperabilidade adequado 700 no qual os exemplos das figuras 1 até 6 podem ser implementados. O ambiente de sistema de computação 700 é somente um exemplo de um ambiente de computação adequado e não é pretendido para sugerir qualquer limitação quanto ao escopo de uso ou quanto à funcionalidade da invenção. A invenção é operacional com vários outros ambientes ou configurações de sistema de computação de propósito geral ou de propósito especial. Exemplos de sistemas, ambientes, e/ou e configurações bem conhecidas que podem ser adequados para uso com a invenção incluem, mas não estão limitados a: computadores pessoais, computadores servidores, sistema multiprocessador, sistemas baseados em microprocessador, PCs de rede, minicomputadores, computadores de grande porte, ambientes de computação distribuída que incluem qualquer um dos sistemas ou dispositivos acima, dentre outros.

[0043] A invenção pode ser descrita no contexto geral de instruções executáveis por computador, tais como módulos de programa, sendo executados por um computador. Geralmente, os módulos de programa incluem rotinas, programas, objetos, componentes, estruturas de dados, e assim por diante, que executam tarefas particulares ou implementam tipos particulares de dados abstratos. A invenção também pode ser praticada em ambientes de computação distribuída, onde as tarefas são executadas por dispositivos de processamento remotos que estão ligados através de uma rede de comunicações. Em um ambiente de computação distribuída, os módulos de programa podem estar localizados em meio de armazenamento do computador local e/ou remoto, incluindo dispositivos de armazenamento em memória.

[0044] Com referência à figura 7, um sistema ilustrativo para implementar vários aspectos da invenção pode incluir um dispositivo de computação de propósito geral na forma de um computador 700. Os componentes podem incluir, mas não estão limitados aos vários componentes de hardware, tais como unidade de processamento 701, armazenamento de dados 702, tal como uma memória do sistema, e o barramento do sistema 703 que acopla vários componentes do sistema, incluindo o armazenamento de dados 702 com a unidade de processamento 701. O barramento do sistema 703 pode ser qualquer uma dentre vários tipos de estruturas de barramento incluindo um barramento de memória ou controlador de memória, um barramento periférico, e um barramento local utilizando qualquer uma dentre várias arquiteturas de barramento. A título de exemplo e não de limitação, tais arquiteturas incluem o barramento da Arquitetura Padrão da Indústria (ISA), o barramento da Arquitetura de Micro Canal (MCA), o barramento ISA Aprimorado (EISA), o barramento local da Associação de Padrões de Eletrônica e Vídeo (VESA), e o barramento da Interconexão de Componentes Periféricos (PCI) também conhecido como barramento Mezanino.

[0045] O computador 700 tipicamente inclui vários meios legíveis por computador 704. Os meios legíveis por computador 704 podem ser qualquer meio disponível que possa ser acessado pelo computador 700 e inclui tanto meio volátil como não volátil, e meio removível e não removível, mas exclui sinais propagados. A título de exemplo e não de limitação, o meio legível por computador 704 pode compreende meio de armazenamento do computador e meio de comunicação. O meio de armazenamento do computador inclui meio volátil e não volátil, removível e não removível, implementado em qualquer método ou tecnologia para armazenamento de informações tais como instruções legíveis por computador, estruturas de dados, módulos de programa, ou outros dados. O meio de armazenamento do computador inclui, mas não está limitado à RAM, ROM, EEPROM, memória flash ou outra tecnologia de memória, CD-ROM, discos versáteis digitais (DVD) ou outro armazenamento em disco ótico, cassetes magnéticos, fita magnética, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser utilizado para armazenar a informação desejada e que possa ser acessado pelo computador 700. O meio de comunicação tipicamente incorpora instruções legíveis por computador, estruturas de dados, módulos de programa ou outros dados em um sinal de dados modulado tal como uma onda portadora ou outro mecanismo de transporte e inclui qualquer meio de distribuição de informação. O termo "sinal de dados modulado" significa um sinal que tem uma ou mais de suas características estabelecidas ou alteradas de modo tal a codificar informação no sinal. A título de exemplo e não de limitação, o meio de comunicação inclui meio com uso e fios tal como uma rede com uso de fios ou conexão direta com fios, e meio sem uso de fios, tal como meio acústico, RF, infravermelho e outros meios sem uso de fios. Combinações de qualquer um dos ditos acima também põem estar incluídas dentro do escopo de meio legível por computador. O meio legível por computador pode ser incorporado como um produto de programa de computador, tal como software armazenado no meio de armazenamento do computador.

[0046] O armazenamento de dados ou a memória do sistema 702 inclui meio de armazenamento do computador na forma de memória volátil e/ou não volátil tal como memória somente para leitura (ROM) e memória de acesso aleatório (RAM). Um sistema básico de entrada / saída (BIOS), contendo rotinas básicas que ajudam a transferir informação entre elementos dentro do computador 700, tal como durante a inicialização, tipicamente é armazenado na ROM. A RAM tipicamente contém dados e/ou módulos de programa que são imediatamente acessíveis e/ou estão atualmente sendo operados pela unidade de processamento 701. A título de exemplo e não de limitação, o armazenamento de dados 702 mantém um sistema operacional, programas aplicativos e outros módulos de programa e dados de programa.

[0047] O armazenamento de dados 702 também pode incluir outros meios de armazenamento do computador removíveis / não removíveis, voláteis / não voláteis. A título somente de exemplo, o armazenamento de dados 702 pode ser uma unidade de disco rígido que lê a partir ou grava junto ao meio magnético não removível, não volátil, uma unidade de disco magnético que lê a partir ou grava junto a um disco magnético removível, não volátil, e uma unidade de disco ótico que lê a partir ou grava junto a um disco ótico removível / não volátil tal como um CD ROM ou outro meio ótico. Outros meios de armazenamento do computador removíveis / não removíveis, voláteis / não voláteis que podem ser utilizados no ambiente operacional ilustrativo incluem, mas não estão limitados aos cassetes de fita magnética, cartões de memória flash, discos versáteis digitais, fita de vídeo digital, RAM de estado sólido, ROM de estado sólido, dentre outros. As unidades e seu meio de armazenamento do computador associado, descritos acima e ilustrados na figura 6, proporcionam armazenamento de instruções legíveis por computador, de estruturas de dados, de módulos de programa e de outros dados para o computador 700.

[0048] Um usuário pode entrar com comandos e informações através de uma interface com o usuário 705 ou do dispositivo de entrada. A interface de entrada do usuário 705 pode ser acoplada com o barramento do sistema 703, mas pode ser conectada por outras estruturas de interface e de barramento. Um monitor 706 ou outro tipo de dispositivo e vídeo também pode estar conectado com o barramento do sistema via uma interface, tal como uma interface de vídeo.

[0049] O computador 700 pode operar em um ambiente de computação em rede ou em nuvem utilizando as conexões lógicas 707 com um ou mais dispositivos remotos, tal como um computador remoto. O computador remoto pode ser um computador pessoal, um servidor, um roteador, um PC de rede, um dispositivo par ou outra nó comum de rede, e tipicamente inclui vários ou todos os elementos descritos acima em relação ao computador 700. As conexões lógicas representadas na figura 6 incluem uma ou mais redes e área local (LAN) e uma ou mais redes de longa distância (WAN), mas também podem incluir outras redes. Tais ambientes em rede são comuns em escritórios, redes de computação de grandes empresas, intranets e na Internet.

[0050] Quando utilizado em um ambiente de computação em rede ou em nuvem, o computador 700 pode ser conectado com uma rede pública ou privada através de uma interface ou adaptador de rede 707. Em algumas concretizações, um modem ou outros dispositivos para estabelecer comunicações através da rede. O modem, o qual pode ser interno ou externo, pode ser conectado com o barramento do sistema 703 via a interface de rede 707 ou outro mecanismo apropriado. Um componente de interoperabilidade sem uso de fios tal como compreendendo uma interface e antena pode ser acoplado através de um dispositivo adequado tal como um ponto de acesso ou um computador par com uma rede. Em um ambiente em rede, os módulos de programa representados em relação ao computador 700, ou partes dos mesmos, podem ser armazenados no dispositivo de armazenamento em memória remoto. Pode ser apreciado que as conexões de rede apresentadas são ilustrativas e outros meios para estabelecer uma ligação de comunicações entre os computadores podem ser utilizados.

[0051] Apesar de o assunto ter sido descrito em linguagem específica para aspectos estruturais e/ou atos metodológicos, é para ser entendido que o assunto definido nas reivindicações anexas não está necessariamente limitado aos aspectos ou atos específicos descritos acima. Ao invés disso, os aspectos ou atos específicos descritos acima são revelados como formas ilustrativas para implementar as reivindicações.

Claims

1. Método para preservar memória virtual em um sistema de computador que compreende as etapas de: identificar (501) uma alocação de memória virtual que é preenchida com estado por um aplicativo, caracterizado pelo fato de que a alocação de memória virtual preservada é identificada pelo aplicativo usando uma API para selecionar memória virtual persistente à reinicialização; desligar (502) o aplicativo, deixando a memória física e os arquivos de paginação associados à alocação de memória virtual preservada inalterada; reinicializar (503) um sistema operacional no sistema de computador sem modificar a alocação de memória virtual preservada; reiniciar (504) o aplicativo após o sistema operacional ter sido reinicializado; e reconectar (506) o aplicativo com a alocação de memória virtual.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que reinicializar o sistema operacional adicionalmente compreende: receber (601) uma cópia de um sistema operacional hospedeiro atualizado; suspender (602) todas as máquinas virtuais executando no sistema de computador; gravar (603) um mapa de alocação e estado para cada uma das máquinas virtuais; transferir a execução a partir do sistema operacional hospedeiro ativo para um carregador; desligar (604) o sistema operacional hospedeiro ativo; ler (605) um kernel do sistema operacional hospedeiro atualizado para dentro da RAM via o carregador; carregar (606) o mapa de alocação e o estado para cada uma das máquinas virtuais; e reiniciar (609) a operação das máquinas virtuais pelo sistema operacional hospedeiro atualizado.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que adicionalmente compreende: deixar as máquinas virtuais residentes na RAM quando as máquinas virtuais são suspensas.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a memória física associada com a alocação de memória virtual preservada no sistema de computador não é modificada quando o sistema operacional é reinicializado.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que uma ou mais páginas de arquivo de paginação associadas com a alocação de memória virtual preservada no sistema de computador não são modificadas quando o sistema operacional é reinicializado.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: identificar alocação de memória virtual preservada após o aplicativo ser reiniciado.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a alocação de memória virtual preservada é identificada por verificar conteúdo de uma região da memória.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a alocação de memória virtual preservada é identificada por um valor de retorno de API.

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende: identificar a alocação de memória virtual preservada após o reinício do aplicativo, verificando o conteúdo de uma região de memória.

10. Sistema de computador, caracterizado pelo fato de que compreende: um processador; memória do sistema; um ou mais meios de armazenamento legíveis por computador tendo o método conforme definido em qualquer uma das reivindicações 1 a 9.