O livro branco da KAL explica como a Virtualização do SO pode ajudar os bancos a executar o Windows 10 nos ATM sem qualquer atualização de hardware

Sumário executivo

Em janeiro de 2020, o apoio ao Windows 7 terminará e deverá ser substituído pelo Windows 10. Esta migração coloca um grande problema aos bancos: a despesa e complexidade da atualização do seu software e hardware dos ATM.

A mudança do Windows XP para Windows 7 em 2014 custou ao setor global milhares de milhões de dólares porque a atualização do sistema operativo dos ATM também implicou a atualização do hardware. Os bancos estão prestes a deparar-se novamente com o mesmo problema quando tiverem de atualizar para o Windows 10.

Mas há uma resposta: a Virtualização do SO. Isto utiliza uma tecnologia conhecida como hipervisor para separar a placa-mãe de hardware do sistema operativo de modo a que os drivers de software que não são suportados pelo Windows 10 possam ser suportados pelo software hipervisor.

A tecnologia hipervisor elimina a necessidade de atualizar o hardware atual quando os ATM passarem para o Windows 10, protegendo os investimentos feitos por 20 000 bancos em todo o mundo, em software e hardware, mantendo-se ao mesmo tempo em conformidade com o PCI.

Esta tecnologia não só é importante quando se migra para o Windows 10, como se tornará essencial na gestão dos futuros lançamentos de software do canal de manutenção em longo prazo, conhecido como LTSC, sob o Windows 10, o que poderá exigir atualizações de hardware ainda mais frequentes.

Saiba mais neste livro branco.

Introdução

Os ATM existem há mais de 50 anos, mas mudaram lentamente durante a maior parte desse tempo.

Durante os primeiros 20 anos, as arquiteturas dos ATM eram propriedade do fabricante dos mesmas, com hardware e software provenientes do mesmo fornecedor. A primeira revolução teve lugar por volta de 1990, quando o OS2 da IBM fez incursões como um sistema operativo para ATM abrindo um pouco a caixa negra dos ATM com o uso de um sistema operativo padrão. O Windows assumiu depois o lugar do OS2 que se foi afastando, tornando-se o ambiente operacional padrão com o Windows NT primeiro, seguido do Windows 2000, Windows XP, Windows 7 e agora o Windows 10. A maior parte dos ATM de nível mundial funcionam atualmente com alguma forma de Windows.

Uma segunda revolução teve início por volta do ano 2000 com a introdução da norma XFS. Todos os dispositivos de hardware especializados dentro dos ATM, tais como dispensadores de notas e leitores de cartões, começaram a ter drivers de software padrão construídos de acordo com a norma CEN XFS. Isto deu origem à era do software multifornecedor que separava as aplicações de software do hardware.

Estamos agora no alvorecer de outra revolução. É a Virtualização do SO e resolve um grande problema para o setor.

Até agora, cada vez que o sistema operativo dos ATM exigia uma atualização importante da versão (por exemplo, de Windows XP para Windows 7 em 2014), era também necessária uma atualização de hardware. As despesas para o setor a nível global eram enormes. Custou milhares de milhões de dólares atualizar os 3,5 milhões de caixas multibanco em todo o mundo.

Mais uma vez, está previsto um novo ciclo de atualizações em 2020, quando terminar o suporte para o Windows 7 e este tiver de ser substituído pelo Windows 10. Não é de surpreender que os bancos se recusem a gastar mais biliões de dólares na atualização dos sseus ATM

O problema das atualizações

2014 foi um mau ano para os bancos que gerem caixas multibanco. Quando a Microsoft abandonou o suporte para XP, depressa se tornou claro que os bancos tinham pouca escolha senão atualizar todos os seus ATM para o Windows 7.

Para a Microsoft, o setor dos ATM é pequeno. Três milhões de ATM a nível mundial é um número menor em comparação com os dois mil milhões ou mais de computadores pessoais em todo o mundo, muitos dos quais utilizam o Windows. Os utilizadores de computadores pessoais têm sempre a opção de adiar a atualização dos seus computadores pessoais ou de comprar atualizações relativamente baratas da motherboard – opções que não estão disponíveis para os bancos usarem com os seus ATM. As atualizações das placas-mãe dos ATM são caras – até 4 000 USD em pequeno volume, mais talvez mais 1 000 USD para enviar técnicos treinados para atualizar os ATM em locais por todo o país.

Como os bancos mantêm os ATM durante 10 anos ou mais, muitos dos modelos mais antigos nem sequer podem ser melhorados e precisam de ser substituídos. Os novos ATM podem custar entre 10 000 e 30 000 USD dependendo da sua capacidade funcional, mais o custo da substituição física, que pode ser exorbitante para ATM “inseridos numa parede” num local movimentado como o centro de Paris, Londres ou Nova Iorque. Uma atualização do sistema operativo dos ATM não traz nenhum benefício direto ao cliente, mas representa um enorme custo apenas por questões de conformidade.

Os ATM estão sujeitos a requisitos regulamentares – especialmente de PCI – que insistem que não pode haver software não suportado na cadeia de componentes de software necessários para gerir um ATM. Muitos bancos asiáticos ignoraram este risco. Os bancos americanos e europeus não enveredaram por esse caminho e melhoraram a sua rede de caixas multibanco. Mas muitos deles declararam que o ciclo de atualização tem de parar.

No entanto, à medida que o ano de 2020 se aproxima, os bancos encontram-se mais uma vez na mesma situação de atualização. A Microsoft está a abandonar o apoio para o Windows 7 e os bancos terão de atualizar as suas redes de ATM para o Windows 10.

Na verdade, as coisas poderão piorar ainda mais depois do Windows 10. A Microsoft anunciou que o W10 será o “último” Windows. Não haverá um Windows 11 ou um Windows 12. Isso significa que o dilema da atualização desaparecerá depois do Windows 10? Tem havido artigos de jornal que proclamam o fim das atualizações. Mas, infelizmente, a realidade é exatamente o oposto.

A nova estratégia para o Windows é fazer atualizações e melhoramentos dos sistemas operativos ainda mais frequentemente do que antes. As principais atualizações chegarão sob a forma de LTSC – pacote de canal de manutenção em longo prazo. A Microsoft planeia lançar os LTSC de três em três anos no futuro. Poderá isto significar que o hardware das ATM poderá ter de ser atualizado de três em três anos? A resposta curta é provavelmente sim!

Como chegámos aqui?

Muitos culpam a Microsoft por atualizar o seu software com demasiada frequência ou por não dar suporte aos sistemas operativos o tempo suficiente, mas consideremos para onde se dirige a indústria global de software.

O conceito de DevOps e os avanços nos testes automatizados significam que os ciclos de lançamento de software estão a ficar cada vez mais rápidos. De facto, as versões diárias não são invulgares em algumas partes da indústria de software. Por conseguinte, é evidente que a Microsoft não pode ficar presa a um ciclo de atualização de 7 anos para o Windows. De facto, o canal LTSC do Windows 10 recomendado para ATM será o ciclo mais lento da Microsoft para lançamentos do Windows. A versão do Windows para empresas em geral é o SAC (canal semestral), que se atualiza muito mais rapidamente (de seis em seis meses) e a Microsoft impõe que essas atualizações sejam implementadas. O SAC é, portanto, pouco provável que seja apropriado para os ATM.

Estes ciclos de atualização mais rápidos causam um enorme stress no ecossistema Wintel. Embora a Microsoft esteja empenhada em apoiar hardware antigo com novas atualizações de SO, o oposto não é verdade. Os fornecedores de componentes de hardware têm pouco interesse em atualizar os seus antigos drivers de software para suportar novas versões do Windows que chegam bem depois de terminarem o desenvolvimento dos drivers (a Microsoft não é diferente neste aspeto – também não dará suporte a hardware novo com um SO antigo).

É daqui que resulta o problema de suporte com atualizações de SO. Os drivers de software, tais como os drivers de chipset da Intel, suportam apenas as versões de SO que estão disponíveis no momento do lançamento dos chipsets – não os novos SO que possam ser lançados muito depois de o desenvolvimento do driver do chipset ter sido concluído.

A Intel diz que dará suporte a um máximo de dois LTSC com qualquer chipset. Dependendo da frequência de chegada de novos LTSC da Microsoft, isto limita a vida útil do hardware do ATM. De facto, quando a Microsoft anunciou inicialmente os LTSC do Windows 10, o plano era lançar um LTSC a cada 12-18 meses, enquanto a Intel disse que suportaria apenas um LTSC por chipset. A política parece ter mudado desde então, com a Microsoft a assentar num ciclo de lançamento de três anos por LTSC e a Intel a concordar em suportar dois LTSC por chipset. Os LTSC até agora lançados foram os “1507, 1607, 1809 e 19H1” – estes nomes são de facto as datas de lançamento da Microsoft, ou seja, julho de 2015, julho de 2016, setembro de 2018 e H1 2019 – pelo que os LTSC chegaram muito mais rapidamente do que a promessa futura de uma a cada três anos.

Como podem ver, esta situação causa uma grande dor de cabeça para a indústria dos ATM. O ciclo de atualização no futuro parece que poderá ser de seis em seis anos, mas poderá facilmente ser tão curto como um a cada 12 meses, dependendo da forma como os LTSC, e o suporte para eles, evoluírem no futuro. A causa principal é que, à medida que os ciclos de software se tornam mais rápidos, nenhum dos fornecedores de hardware da cadeia de suporte deseja suportar novos lançamentos de SO com os seus antigos componentes e drivers de hardware – não têm qualquer intenção de reabrir o desenvolvimento de drivers antigos de software para os integrarem com futuros lançamentos de SO.

No meio de um dilema

Isto deixa a indústria dos ATM com poucas opções. Os bancos estão habituados a gerir as suas caixas multibanco durante um período de 10 anos e muitos bancos gerem caixas multibanco ainda durante mais tempo do que isso. De facto, a manutenção do hardware dos ATM tem mais em comum com a manutenção de aeronaves do que com a manutenção de computadores pessoais. As aeronaves podem ser utilizadas durante várias décadas, mas durante esse período muitos dos componentes de hardware podem ter mudado várias vezes, de um modo tal que talvez só a estrutura da aeronave tenha verdadeiramente 30 anos de idade.

Da mesma forma, um ATM com 15 anos de idade teve provavelmente múltiplas mudanças do leitor de cartões, do distribuidor de dinheiro e talvez também do núcleo do PC ao longo da sua vida útil. A parte complicada, no entanto, é o sistema operativo. Se o sistema operativo for alterado com a mesma regularidade com que a Microsoft envia atualizações, a placa-mãe terá também de ser atualizada juntamente com o sistema operativo – com custos significativos para o banco. A alternativa é executar um SO não suportado e correr o risco de não estar em conformidade com o PCI, para além dos riscos de segurança muito reais, tais como malware (e a má publicidade associada que acompanha as violações de segurança).

Haverá outra resposta? A KAL tem-se concentrado neste problema desde 2014, avaliando as opções, tentando compreender as causas de raiz e verificando que portas podem potencialmente levar a uma solução de longo prazo.

Encontrar uma solução

O ATM atualizável? Não.

Uma opção que tivemos em consideração foi saber se o núcleo de PC de um ATM poderia ser tornado mais “atualizável”.

Imagine um cenário em que uma atualização do núcleo do PC fosse tão fácil como mudar um DVD num leitor de DVD? De facto, a Intel suporta este tipo de conceito com o seu “cartão de computação”. É um núcleo de PC com o tamanho de um cartão de crédito que pode ser facilmente trocado. No entanto, isto exigiria um novo desenho dos ATM a nível grossista em todo o mundo e ainda precisaria de uma troca de hardware relativamente dispendiosa com intervenção no local.

Não atualizar de todo? Não.

Há um número significativo de ATM que ainda hoje funcionam com Windows XP em alguns bancos asiáticos. Esta opção de simplesmente não atualizar o sistema operativo e continuar a executar o Windows XP nos ATM é claramente uma estratégia arriscada. Não só não é compatível com o PCI para executar software não suportado, como também expõe o banco e os seus clientes a potenciais ciberataques e malware, uma vez que as vulnerabilidades em sistemas operativos não suportados são exploradas por bandos criminosos. Isto não deve ser considerado uma opção séria.

No entanto, existe uma alternativa a “não atualizar” os ATM que pode, potencialmente, funcionar no futuro com o Windows 10 e posteriores lançamentos de LTSC.

Vamos assumir que um banco atualiza inicialmente os seus ATM para o Windows 10, conforme necessário. A versão do Windows 10 em 2019 chama-se Windows 10 LTSC 1809 e funciona em conjunto com um chipset que suporta esse LTSC. A Microsoft, a Intel e a indústria dos ATM suportarão essa combinação durante 10 anos. Isso pode parecer resolver o dilema da atualização, mas na realidade não o faz. Ora veja:

• Os novos LTSC do Windows 10, à medida que chegam não podem ser executados naquele ATM de 2019 – ou seja, ao longo de toda a vida útil de 10 anos em que o ATM precisaria de executar o LTSC original.
• Considere agora o ciclo anual de substituição do ATM. Como exemplo, um grande banco com, digamos, 10 000 ATM substituiria 10% do seu património todos os anos à medida que os ATM fossem envelhecendo. Cada ano o banco poderia comprar 1 000 novos ATM que seriam entregues com o LTSC mais recente da Microsoft e o atual chipset da Intel. Em 2023, por exemplo, receberiam o LTSC 23XX. Enquanto esses novos ATM irão funcionar com LTSC 23XX, os antigos ATM convertidos em 2019 só podem funcionar com o LTSC 1809. Após 10 anos, a rede de ATM teria potencialmente 10 LTSC diferentes de LTSC mais combinações de chipset a executar diferentes versões do SO e capacidades de funcionalidades diferentes.
• Embora cada ATM tivesse uma pilha de software suportada durante um período de 10 anos, isto seria conseguido não atualizando o sistema operativo à medida que os LTSC vão chegando, resultando numa rede fragmentada, potencialmente com muitas versões diferentes de sistemas operativos em toda a rede. Este seria um cenário insustentável para a maioria dos bancos.

Mudar a estratégia de suporta da Intel aos ATM? Não.

Aravinda Korala, CEO da KAL, e Mike Lee, CEO da ATMIA, empreenderam conjuntamente uma série de conversas com a Intel para compreender se considerariam um regime especial de suporte aos seus drivers de chipset para o setor dos ATM.

A conversa foi liderada por Oania Wei e Alec Gefrides, Diretor Geral, Segmento Transacional do Retalho da Intel. Explorámos conceitos como o suporte especial pago a longo prazo aos drivers da Intel para o setor dos ATM e o licenciamento do código fonte para a ATMIA dos drivers antigos. No final, tornou-se claro que, para a Intel, os ATM são uma pequena indústria para a qual nenhuma das opções que propusemos era viável. No entanto, a Intel mencionou: “Olhem novamente para o Linux” e apresentou a KAL à Wind River, uma empresa de distribuição do Linux que, na altura, era também uma subsidiária da Intel.

Migrar os ATM para Linux? Não.

O Linux tem sido uma opção para os ATM já há muito tempo. Tem havido algum sucesso na utilização dos ATM com o Linux no Brasil – mas não em qualquer outro lugar.

A indústria global dos ATM é um mercado relativamente pequeno com apenas 3,5 milhões de ATM em todo o mundo. Apoiar um mercado fragmentado com o Linux e o Windows não era comercialmente viável para os fornecedores. Tenhamos em conta que, globalmente, existem aproximadamente 20 000 bancos. A decisão de qual o sistema operativo que devem ter os ATM é fundamentalmente tomada pelo banco – não pelos fornecedores. Os bancos simplesmente não permitirão que um sistema operativo para o qual não têm uma política seja ligado à sua rede interna – e ponto final.

Quanto tempo será necessário para convencer 20 000 bancos a aceitarem o Linux como sistema operativo nos seus ATM? Pode adivinhar a resposta. Qualquer argumento comercial para a migração para um conjunto completo de software Linux teria de enfrentar um período muito longo de fragmentação do mercado. O resultado disso é que nenhum dos principais fabricantes de ATM tem estado até agora disposto a investir no suporte tanto do Linux como do Windows nos seus ATM ao longo de um período de transição tão extenso. Como os drivers XFS são controlados pelos fabricantes, se estes drivers não forem portados para Linux, então é impossível para qualquer fornecedor de software executar uma aplicação Linux numa ATM, independentemente da profundidade dos bolsos de R&D do fornecedor de software.

Porquê considerar o Linux de todo? O Linux tem uma característica especialmente útil que quebra o bloqueio do suporte. Todos os drivers de software Linux, incluindo os drivers de chipset da Intel, são de código aberto sob Linux. Isso significa que empresas como a Wind River e a Red Hat, do ecossistema Linux, têm acesso a esse código fonte e podem fornecer suporte numa base comercial. Isto resolve o problema do PCI para os bancos.

Mas ainda nos deixa com o dilema do custo de migração do software de todos os ATM do mundo em milhares de bancos, do Windows para Linux.

A solução – Um momento eureka

Embora o Linux possa resolver o problema do suporte de software a longo prazo, tem uma enorme desvantagem em relação ao Windows, uma vez que os bancos investiram milhares de milhões de dólares em software dos ATM que corre em Windows. O custo da migração seria enorme.

Existe um obstáculo técnico, para além do financeiro. Os ATM têm drivers de hardware que utilizam a norma XFS que são implementados apenas em Windows. Mesmo que um banco desejasse migrar o seu conjunto de software para Linux, não o poderia fazer, a menos que o fornecedor de hardware também estivesse disposto a migrar os seus drivers XFS para Linux. Atualmente, não existem drivers para ATM dos principais fornecedores em Linux.

Haverá então uma forma de combinar as virtudes do Linux e do Windows?

A KAL trabalhou este problema com Wind River a partir de meados de 2017. A equipa KAL foi liderada por Aravinda Korala e Kit Patterson, enquanto a equipa da Wind River foi liderada por Kevin Konkos e Davide Ricci. A resposta a que chegámos é utilizar um Hipervisor Linux para alojar o Windows 10.

O Linux suporta uma tecnologia de hipervisor chamada QEMU. O QEMU corre em conjunto com o KVM para explorar a aceleração de hardware de virtualização suportada em Linux e consegue apresentar uma interface para Windows 10 para correr como um sistema operativo convidado em Linux. Os drivers de hardware para a placa-mãe vêm agora do kernel Linux, mas o ambiente da aplicação corre sob Windows. O suporte para QEMU, KVM e os drivers Linux provém da comunidade Linux e de empresas como a Red Hat e Wind River. A parte Linux pode, portanto, ser suportada durante qualquer período, desde que as condições comerciais funcionem para as empresas Linux.

O Windows pode assentar no Linux e ser atualizado tão frequentemente quanto a Microsoft e os bancos desejarem atualizá-lo – e tudo isso pode acontecer remotamente online, sem uma visita aos ATM no local. Isto resolve o enigma da atualização. Elimina a necessidade de atualizações forçadas de hardware, causadas por atualizações do Windows ou pelos LTSC, e os bancos podem manter-se completamente atualizados e executar as versões mais recentes de todo o software. Liberdade finalmente do ciclo de atualização forçada do hardware.

Como funciona

O que é um hipervisor e a virtualização?

A virtualização não é um conceito novo. A IBM criou pela primeira vez máquinas virtuais e ambientes virtualizados em mainframes já na década de 1960. É agora amplamente utilizada em quase todos os centros de dados do mundo.

Os hipervisores permitem que vários sistemas operativos funcionem no mesmo servidor de hardware. Um dos mais conhecidos é o hipervisor da VMware. Os centros de dados globais executam hipervisores da VMware, Red Hat, etc. para isolar o hardware do ambiente operativo.

Por exemplo, seria possível executar o Windows XP e o Windows 7 simultaneamente como sistemas operativos convidados num SO VMware anfitrião. Permitem também que os servidores sejam controlados e geridos remotamente utilizando o hipervisor. Um sistema em execução pode ser congelado a meio caminho, movido para um novo servidor de hardware e reiniciado a partir do ponto onde parou, como se nada tivesse acontecido entretanto.

Virtualização de hardware Intel e AMD

Os hipervisores de software dependem da magia do hardware da Intel e da AMD para fazerem o seu trabalho.

Nos primeiros tempos, a virtualização era apenas uma técnica de software. Baseava-se na emulação de software para permitir que um sistema operativo convidado funcionasse num sistema operativo anfitrião. Mas o esforço de emular e traduzir os comandos de acesso ao hardware de um SO para outro era dispendioso e tornava os sistemas consideravelmente mais lentos.

Por volta de 2005, a Intel e a AMD construíram suporte de virtualização de hardware nas suas novas CPU. Estas tecnologias, conhecidas como Intel VT-x e AMD-V, permitem que os executáveis de SO convidados funcionem nativamente na CPU, mas apanham chamadas de sistema para que possam ser processados pelo SO correto. O resultado é que o software de aplicação no SO convidado corre como se tivesse toda a CPU à sua disposição, sem impacto discernível no desempenho.

Nos testes da KAL, o impacto no desempenho foi medido como sendo apenas de cerca de 2% para um ATM virtualizado a executar tanto Windows como Linux, quando comparado com a execução do Windows nativamente no mesmo hardware sem virtualização. Isto é de facto mágico.

O diagrama abaixo mostra como é a arquitetura do novo software de ATM dentro de um ATM com tecnologia de virtualização de SO:

O hipervisor corre no núcleo do PC dedicado, o Windows 10 corre como um sistema operativo convidado no topo do hipervisor e o software de aplicação, juntamente com os SP do XFS do fornecedor de hardware, corre dentro de uma máquina virtual Windows. 

A que se assemelha uma solução de ATM virtualizada?

A um nível conceptual, uma solução de software virtualizada é exatamente como um conjunto de software atual, mas com a adição de um hipervisor entre o Windows e o hardware. Mas, é claro, não é assim tão simples implementar uma solução real. Comecemos com os pré-requisitos.

Pré-requisitos para uma solução de ATM virtualizada

Embora os hipervisores possam funcionar nos ATM que não tenham suporte de hardware incorporado para virtualização, através da utilização de emulação de software, é provável que isto seja demasiado lento para utilização em produção. Aqui está, então, uma lista de pré-requisitos para a virtualização dos ATM:

1. O primeiro requisito é o “VT-x” nas placas-mãe Intel e o “AMD-V” nas placas-mãe AMD. Como as CPU com estas capacidades de hardware começaram a aparecer por volta de 2006, qualquer ATM mais antigo do que isso não poderá suportar a virtualização sem uma degradação significativa do desempenho. É também provável que os ATM com estas capacidades só tenham aparecido muito depois de 2006, uma vez que os fornecedores de hardware de ATM utilizaram frequentemente stocks mais antigos de CPU durante um longo período, pelo que o corte ocorre em algum momento depois de 2006.
   
   
2. A capacidade de virtualização nas CPU que os suportam pode ser desativada por uma configuração do BIOS. Isto exigiria uma visita ao local para alterar esta configuração, adicionando assim custos à implementação de uma solução de hipervisor. Alguns fornecedores de hardware de ATM possuem ferramentas de gestão do BIOS que podem ser utilizadas remotamente. A KAL recomendaria esta opção para testar primeiro a configuração da BIOS e depois alterar essa configuração remotamente para permitir a virtualização. É mais provável que os ATM mais recentes tenham esta opção já ativada por defeito.
   
   
3. A seguir, os bancos terão de selecionar um fornecedor de hipervisor. Três empresas já manifestaram o seu interesse em apoiar o setor dos ATM – a Red Hat, a VMware e a Wind River. A KAL testou os hipervisores das três empresas e pode confirmar que todos eles funcionam. A Microsoft também tem um hipervisor chamado Hyper-V que é um elemento padrão do Windows e que poderia teoricamente funcionar, mas sofre do mesmo inconveniente que o próprio Windows. Como o código fonte do driver não está disponível para drivers de dispositivos de terceiros no Windows, os drivers não suportados com Hyper-V não têm forma de ser suportados pela Microsoft ou por mais alguém.
   
   
4. Finalmente, os bancos precisam de verificar se os seus fornecedores de hardware e software para ATM irão suportar as suas aplicações e drivers de software num ambiente virtualizado. Por exemplo, se o seu fornecedor de software de ATM for a KAL, precisam de verificar se a KAL irá suportar um ambiente virtualizado – algo que fazemos realmente – e precisam de garantir que o fornecedor de hardware para ATM irá suportar os seus SP do XFS num ambiente virtualizado. Os bancos precisam de assegurar que o apoio à virtualização seja incorporado em todos os futuros RFP bancários. Foi isso que aconteceu no ano 2000 com o XFS. Os bancos impuseram* o suporte para XFS a todos os fornecedores e isso mudou o mundo dos ATM.

Pronto para entrar em funcionamento?

Bem, não por enquanto. Cumprir os pré-requisitos não é exatamente suficiente. Os bancos também precisam de concluir um projeto de implementação:

1. A nova solução de hipervisor precisa de ser testada para assegurar que todos os scripts de teste que foram utilizados para testar a aceitação da solução atual continuam a funcionar quando o sistema operativo é virtualizado – deverá funcionar.
2. Precisam de rever o seu bloqueio de segurança dos ATM. O novo ambiente muda o envelope de segurança – precisam de bloquear o hipervisor, bem como o ambiente Windows.
3. Precisam de rever o sistema de monitorização do ATM. Idealmente, o software de hipervisor também deveria ser monitorizado, juntamente com o resto do sistema.
4. Os bancos precisarão de rever o mecanismo de distribuição do software. No melhor cenário, a mudança deveria acontecer completamente com a distribuição remota do software, sem a necessidade de enviar um técnico ao ATM. O sistema de distribuição de software precisa de ser capaz de entregar correções e atualizações ao software do hipervisor, bem como ao Windows e à Aplicação – o que deverá ocorrer online numa situação ideal (ou via DVD se essa for a única opção disponível).

Uma vez concluídos estes passos, os bancos estão prontos para entrar em funcionamento.

A KAL está pronta já hoje.

Estratégia de apoio a longo prazo

Existe um componente de software extra no conjunto de software de ATM para o qual os bancos precisam agora de ter um contrato de suporte. Precisam de garantir que o suporte ao hipervisor seja adicionado à lista. Eis o que precisam da parte do fornecedor do hipervisor:

• Compromisso de dar suporte ao hardware do ATM a longo prazo – pelo menos 10 anos, se não mais.
• Suporte para drivers de dispositivos de placa-mãe em Linux para que possam ser substituídos utilizando drivers de código aberto Linux através da virtualização, à medida que os drivers de software de terceiros a funcionar em Windows para esse hardware saiam da manutenção com novos LTSC.
• Suporte para chipsets Intel e AMD até aos mais antigos que os fornecedores de hipervisores possam fornecer, para que os ATM mais antigos da sua rede possam receber suporte.
• Suporte para futuros LTSC da Microsoft à medida que vão chegando, estando atentos a potenciais problemas relacionados com o driver de software para hardware antigo, tal como indicado acima.

Idealmente, a indústria dos ATM necessita de uma única libertação global do hipervisor de cada um dos fornecedores para suportar todos os modelos de placas-mãe de ATM em todo o mundo.

Conclusão e caminho a seguir

A virtualização resolve um dilema para os implementadores de ATM, quebrando a ligação entre as atualizações do sistema operativo Windows e as atualizações de hardware do núcleo do PC. Permite que o sistema operativo e o hardware sejam atualizados separadamente e assim elimina a enorme perturbação nas redes ATM que será causada quando o Windows 7 deixar de ter suporte em 2020.

O primeiro banco no mundo a testar o conceito de virtualização com a KAL, juntamente com dois fornecedores do hipervisor, foi um banco dos EUA. A capacidade de executar o atual conjunto de software do banco num ambiente virtualizado foi demonstrada numa prova de conceito (PoC – Proof of Concept) que durou alguns dias.

O primeiro banco europeu a testar o conceito com a KAL foi o Česká spořitelna na República Checa. Jiří Charousek expressou imediatamente apreço pela tecnologia e montou os primeiros testes. Jiří disse: “Estávamos preocupados por termos de atualizar o nosso hardware tão pouco tempo depois da atualização de XP-W7 e estamos realmente felizes por a virtualização nos proporcionar uma opção alternativa. A virtualização dos ATM foi uma ideia muito natural para nós, uma vez que se baseia num conceito Česká a longo prazo, dentro da área das infraestruturas – a virtualização já é a nossa estratégia e os ATM eram a exceção.”

Este conceito é também um trunfo para os fornecedores de hardware. Eles compram frequentemente placas-mãe e chipsets em grandes quantidades chegando depressa à conclusão que uma nova atualização do sistema operativo torna o seu antigo stock de hardware inútil. À medida que a virtualização vai rompendo a ligação estreita entre placas-mãe e sistemas operativos, a KAL acredita que isto irá poupar custos também para os fabricantes de ATM.

A virtualização dos sistemas operativos fornece o caminho para eliminar o processo complicado, caro e demorado de os bancos terem de atualizar continuamente as frotas de ATM para suportar um novo sistema operativo. Não elimina a necessidade de atualizar o hardware para sempre, mas elimina a necessidade de atualizar os ATM apenas por causa de uma atualização do sistema operativo. Os bancos ainda precisarão de atualizar os seus núcleos de PC ou porque são demasiado velhos, ou demasiado lentos, ou porque desejam utilizar futuras capacidades da CPU para fornecer novos serviços interessantes aos seus clientes. Os bancos concordarão que esta é uma boa razão para atualizarem o seu hardware.

Aqui, é essencial que os bancos exijam suporte à virtualização em todos os seus RFP para software e hardware de ATM.

Os nossos agradecimentos

Muitas pessoas contribuíram para este projeto e confirmam que funciona realmente. A KAL gostaria de lhes agradecer muito por nos ajudarem a chegar a esta solução.

• ATMIA: Mike Lee
• Citibank: Peter Kulik
• Česká: Jiří Charousek
• Intel: Oania Wei
• KAL: Kit Patterson, Andrea Vinci, Giuseppe Scardino
• Microsoft: Pat Telford
• Payment Redesign: Eric de Putter
• Red Hat: David Hutchison-Bird, Daniel Schaefer, Rich Feldman
• VMWare: Thomas Klouwer
• Wind River: Davide Ricci, Rick Anderson, Kevin Konkos

Em seguimento

Agradecemos os seus comentários, perguntas e feedback. Junte-se à discussão do blogue abaixo.

Pode descarregar uma cópia do livro branco em formato PDF..

Se tiver alguma questão relacionada com o livro branco, não hesite em contactar-nos.