Para quem é este artigo?
Este artigo pode ser do interesse de administradores de sistemas que foram confrontados com a tarefa de criar um serviço de trabalhos "únicos".
Prólogo
Solicitou-se ao departamento de suporte de TI de uma empresa jovem em desenvolvimento dinâmico com uma pequena rede regional que organizasse "estações de autoatendimento" para uso de seus clientes externos. Os dados da estação deveriam ser usados para registro nos portais externos da empresa, para baixar dados de dispositivos externos e trabalhar com portais do governo.
Um aspecto importante foi o fato de a maioria do software ser "aprimorada" no MS Windows (por exemplo, "Declaração") e, apesar do movimento em direção a formatos abertos, o MS Office continua sendo o padrão dominante na troca de documentos eletrônicos. Portanto, não foi possível recusar o MS Windows ao resolver esse problema.
O principal problema era a possibilidade de acumular vários dados das sessões do usuário, o que poderia levar ao vazamento para terceiros.
Esta situação já decepcionou o MFC . Mas, diferentemente do MFC quase judicial (instituição autônoma do estado), as organizações não estatais serão punidas muito mais por essas deficiências. A próxima questão crítica foi o requisito de trabalhar com mídia de armazenamento externo, na qual, por todos os meios, haverá um monte de malware malicioso. A probabilidade de entrada de malware da Internet foi considerada menos provável devido à restrição de acesso à Internet por meio de uma lista branca de endereços.Os funcionários de outros departamentos se uniram para elaborar os requisitos, fazendo seus requisitos e desejos, os requisitos finais foram os seguintes:
Requisitos de SI- Após o uso, todos os dados do usuário (incluindo arquivos temporários e chaves do registro) devem ser excluídos.
- Todos os processos iniciados pelo usuário devem ser concluídos no final do trabalho.
- Acesso à Internet através de uma lista branca de endereços.
- Restrições à capacidade de executar código de terceiros.
- Se a sessão estiver ociosa por mais de 5 minutos, a sessão deve terminar automaticamente, a estação deve executar uma limpeza.
Requisitos do cliente- O número de estações clientes por filial não é superior a 4.
- O tempo mínimo de espera para a prontidão do sistema, desde o momento em que "me sentei em uma cadeira" até o início do trabalho com o software cliente.
- A capacidade de conectar dispositivos periféricos (scanners, unidades flash) diretamente do local de instalação da "estação de autoatendimento".
- Desejos do cliente
- Demonstração de materiais publicitários (fotos) no momento do encerramento do complexo.
Farinha de criatividade
Tendo jogado o suficiente com o Windows LiveCD, chegamos à conclusão unânime de que a solução resultante não satisfaz pelo menos três pontos críticos. Eles são carregados por um longo período de tempo, ou não são totalmente ao vivo, ou sua personalização foi associada a uma dor intensa. Talvez tenhamos pesquisado mal, e você pode aconselhar um conjunto de algumas ferramentas, ficarei grato.
Além disso, começamos a olhar para a VDI, mas para esta tarefa, a maioria das soluções é muito cara ou requer muita atenção. E eu queria uma ferramenta simples com uma quantidade mínima de mágica, a maioria dos problemas que poderiam ser resolvidos simplesmente reiniciando / reiniciando o serviço. Felizmente, tínhamos equipamentos de servidor, de classe baixa nas filiais, do serviço desativado, que poderíamos usar para a base tecnológica.
Qual é o resultado? Mas não poderei contar o que aconteceu no final, porque a NDA, mas no processo de pesquisa, desenvolvemos um esquema interessante que se mostrou bem em testes de laboratório, embora não tenha entrado em série.
Algumas isenções de responsabilidade: o autor não afirma que a solução proposta resolve completamente todas as tarefas e o faz voluntariamente e com a música. O autor concorda com a afirmação de que Sein Englishe sprache é zehr schlecht. Como a solução não se desenvolve mais, você não pode contar com uma correção de bug ou uma alteração na funcionalidade, tudo está em suas mãos. O autor supõe que você esteja pelo menos um pouco familiarizado com o KVM e leia um artigo de revisão sobre o protocolo Spice, e você trabalhou um pouco com o Centos ou outra distribuição GNU Linux.
Neste artigo, eu gostaria de analisar a espinha dorsal da solução resultante, a saber, a interação do cliente e do servidor e a essência dos processos no ciclo de vida das máquinas virtuais na estrutura da solução em questão. Se o artigo for interessante para o público, descreverei os detalhes da implementação de imagens ao vivo para criar thin clients baseados no Fedora e falarei sobre os detalhes do ajuste de máquinas virtuais e servidores KVM para otimizar o desempenho e a segurança.
Se você pegar papel colorido,
Tintas, pincéis e cola,
E um pouco mais de destreza ...
Você pode fazer cem rublos!
Esquema e descrição da bancada de testes
Todo o equipamento está localizado dentro da rede da filial, apenas o canal da Internet sai. Historicamente, já existe um servidor proxy, não é nada extraordinário. Mas é nele, entre outras coisas, que o tráfego das máquinas virtuais será filtrado (abrevie VM mais adiante no texto). Nada impede a colocação desse serviço no servidor KVM, a única coisa que você precisa observar é como a carga dele no subsistema de disco é alterada.
Estação cliente - de fato, “estações de autoatendimento”, “front-end” do nosso serviço. São nettops do Lenovo IdeaCentre. Para que serve esta unidade? Sim, quase todo mundo, especialmente satisfeito com o grande número de conectores USB e leitores de cartão no painel frontal. Em nosso esquema, um cartão SD com proteção contra gravação de hardware é inserido no leitor de cartões, no qual a imagem ao vivo modificada do Fedora 28 é gravada. É claro que um monitor, teclado e mouse estão conectados ao nettop.
Switch - um switch de hardware normal do segundo nível, fica na sala do servidor e pisca com as luzes. Não está conectado a nenhuma rede, exceto a rede de "estações de autoatendimento".
O KVM_Server é o núcleo do circuito; nos testes de bancada do Core 2 Quad Q9650 com 8 GB de RAM, ele usou com confiança três máquinas virtuais Windows 10. Subsistema de disco - adaptec 3405 2 unidades Raid 1 + SSD. Em testes de campo do Xeon 1220, o LSI 9260 + SSD mais sério conseguiu facilmente 5-6 VMs. Obteríamos o servidor do serviço aposentado, não haveria muitos custos de capital. O sistema de virtualização KVM com o pool de máquinas virtuais pool_Vm é implementado neste (s) servidor (es).
VM é uma máquina virtual, o back-end do nosso serviço. É o trabalho do usuário.
Enp5s0 é uma interface de rede que olha para a rede de "estações de autoatendimento", dhcpd, ntpd, httpd ao vivo e o xinetd ouve a porta "sinal".
Lo0 é a pseudo-interface de loopback. Standard.
Spice_console - Uma coisa muito interessante, o fato é que, diferentemente do RDP clássico, quando você ativa o pacote de protocolos KVM + Spice, uma entidade adicional aparece - a porta do console da máquina virtual. De fato, ao conectar-se a essa porta TCP, obtemos o console do Vm, sem a necessidade de conectar-se ao Vm através de sua interface de rede. Toda interação com o Vm para transmissão de sinal, o servidor assume. A função analógica mais próxima é a IPKVM. I.e. Uma imagem de um monitor de VM é transferida para essa porta, os dados sobre o movimento do mouse são transmitidos a ela e (o mais importante) a interação via protocolo Spice permite redirecionar perfeitamente dispositivos USB para uma máquina virtual, como se esse dispositivo estivesse conectado à própria VM. Testado para flash drives, scanners, webcams.
Vnet0, virbr0 e placas de rede virtual Vm formam uma rede de máquinas virtuais.
Como isso funciona
Da estação do cliente
A estação cliente é inicializada no modo gráfico a partir da imagem ao vivo modificada do Fedora 28, recebe o endereço IP por dhcp do espaço de endereço de rede 169.254.24.0/24. Durante o processo de inicialização, são criadas regras de firewall que permitem conexões com as portas do servidor "sinal" e "tempero". Após a conclusão do download, a estação aguarda a autorização do usuário do Cliente. Após a autorização do usuário, o gerenciador da área de trabalho "openbox" é iniciado e o script de inicialização automática é executado em nome do usuário autorizado. Entre outras coisas, o script de execução automática executa o script remote.sh.
$ HOME / .config / openbox / scripts / remote.sh /etc/client.conf server_ip=169.254.24.1 vdi_signal_port=5905 vdi_spice_port=5906 animation_folder=/usr/share/backgrounds/animation background_folder=/usr/share/backgrounds2/fedora-workstation
Descrição das variáveis do arquivo client.conf
server_ip - endereço KVM_Server
vdi_signal_port - porta KVM_Server na qual o xinetd "fica"
vdi_spice_port - porta de rede KVM_Server, da qual a solicitação de conexão será redirecionada do cliente visualizador remoto para a porta de especiarias do Vm selecionado (detalhes abaixo)
animation_folder - pasta de onde as imagens são tiradas para demonstração de animação besteira
background_folder - a pasta de onde as imagens são tiradas para apresentações em espera. Mais sobre animação na próxima parte do artigo.
O script remote.sh obtém as configurações do arquivo de configuração /etc/client.conf e usa nc para conectar-se à porta “vdi_signal_port” do servidor KVM e recebe um fluxo de dados do servidor, entre os quais espera a sequência “RULE ADDED, CONNECT NOW”. Quando a linha desejada é recebida, o processo do visualizador remoto é iniciado no modo quiosque, estabelecendo uma conexão com a porta do servidor “vdi_spice_port”. A execução do script é suspensa até o final da execução do visualizador remoto.
O visualizador remoto conectado à porta "vdi_spice_port", devido a um redirecionamento no lado do servidor, chega à porta "spice_console" da interface lo0, ou seja, para o console da máquina virtual e o trabalho do usuário ocorre diretamente. Enquanto aguarda a conexão, o usuário recebe uma animação besteira, na forma de uma apresentação de slides de arquivos jpeg, o caminho para o diretório com imagens é determinado pelo valor da variável animation_folder do arquivo de configuração.
Se a conexão com a porta "spice_console" da máquina virtual for perdida, o que sinaliza o desligamento / reinicialização da máquina virtual (ou seja, o final real da sessão do usuário), todos os processos em nome do usuário autorizado serão encerrados, o que levará ao reinício do lightdm e retornará à tela de autorização .
Do lado do servidor KVM
Na porta "sinal" da placa de rede, enp5s0 está aguardando a conexão xinetd. Após conectar-se à porta "signal", o xinetd executa o script vm_manager.sh sem passar nenhum parâmetro de entrada para ele e redireciona o resultado do script para a sessão nc da Estação Cliente.
/etc/xinetd.d/test-server service vdi_signal { port = 5905 socket_type = stream protocol = tcp wait = no user = root server = /home/admin/scripts_vdi_new/vm_manager.sh }
/home/admin/scripts_vdi_new/vm_manager.sh /etc/vm_manager.confsrv_scripts_dir = / home / admin / scripts_vdi_new
srv_pool_size = 4
srv_start_port_pool = 5920
srv_tmp_dir = / tmp / vm_state
base_host = win10_2
input_iface = enp5s0
vdi_spice_port = 5906
count_conn_tryes = 10
Descrição das variáveis do arquivo de configuração vm_manager.conf
srv_scripts_dir - pasta de local do script vm_manager.sh, vm_connect.sh, vm_delete.sh, vm_create.sh, vm_clear.sh
srv_pool_size - tamanho do pool Vm
srv_start_port_pool - a porta inicial, após a qual as portas de tempero dos consoles da máquina virtual serão iniciadas
srv_tmp_dir - pasta para arquivos temporários
base_host - base Vm (imagem dourada) a partir da qual os clones Vm serão transformados no pool
input_iface - a interface de rede do servidor, olhando para estações cliente
vdi_spice_port - a porta de rede do servidor a partir da qual a solicitação de conexão será redirecionada do cliente do visualizador remoto para a porta de especiarias da VM selecionada
count_conn_tryes - um timer de espera, após o qual se considera que não ocorreu uma conexão com o Vm (para obter detalhes, consulte vm_connect.sh)
O script vm_manager.sh lê o arquivo de configuração do arquivo vm_manager.conf, avalia o estado das máquinas virtuais no conjunto de acordo com vários parâmetros, a saber: quantas VMs são implementadas, se existem VMs limpas gratuitas. Para fazer isso, ele lê o arquivo clear.list que contém os números de portas "spice_console" das máquinas virtuais "recém-criadas" (consulte o ciclo de criação da VM abaixo) e verifica se há uma conexão estabelecida com elas. Se uma porta com uma conexão de rede estabelecida for detectada (o que absolutamente não deveria ser), um aviso será exibido e a porta será transferida para waste.list Quando a primeira porta for encontrada no arquivo clear.list com o qual não há conexão no momento, vm_manager.sh chama o script vm_connect.sh e passa ele como parâmetro o número dessa porta.
/home/admin/scripts_vdi_new/vm_connect.sh O script vm_connect.sh apresenta regras de firewall que criam um redirecionamento "vdi_spice_port" da porta do servidor da interface enp5s0 para a "porta do console de especiarias" da VM localizada na interface do servidor lo0, transmitida como parâmetro de inicialização. A porta é transferida para conn_wait.list, a VM é considerada uma conexão pendente. A linha REGRA ADICIONADA, CONECTAR AGORA é enviada para a sessão da Estação Cliente na porta de "sinal" do servidor, o que é esperado pelo script remote.sh em execução. Um ciclo de espera de conexão começa com o número de tentativas determinadas pelo valor da variável "count_conn_tryes" do arquivo de configuração. A cada segundo da sessão nc, a sequência "REGRA ADICIONADA, CONECTAR AGORA" será fornecida e a conexão estabelecida com a porta "spice_console" será verificada.
Se a conexão falhar para o número definido de tentativas, a porta spice_console será transferida de volta para clear.list. A execução do vm_connect.sh será concluída, a execução do vm_manager.sh será retomada, iniciando o ciclo de limpeza.
Se a Estação Cliente se conectar à porta spice_console na interface lo0, as regras do firewall que criarão um redirecionamento entre a porta do servidor spice e a porta spice_console serão excluídas e a conexão será mantida por um mecanismo para determinar o status do firewall. No caso de uma conexão desconectada, a reconexão com a porta spice_console falhará. A porta spice_console é transferida para waste.list, a VM é considerada suja e não pode retornar ao conjunto de máquinas virtuais limpas sem passar pela limpeza. A execução do vm_connect.sh é concluída, a execução do vm_manager.sh é retomada, o que inicia o ciclo de limpeza.
O ciclo de limpeza começa examinando o arquivo waste.list, para o qual são transferidos os números spice_console das portas da máquina virtual para as quais a conexão é estabelecida. A presença de uma conexão ativa é determinada em cada porta spice_console da lista. Se não houver conexão, considera-se que a máquina virtual não está mais em uso e a porta é transferida para recycle.list e o processo de exclusão da máquina virtual (veja abaixo) ao qual essa porta pertence é iniciado. Se uma conexão de rede ativa for detectada na porta, presume-se que a máquina virtual esteja sendo usada, nenhuma ação será executada. Se a porta não for tocada, presume-se que a VM esteja desligada e não seja mais necessária. A porta é transferida para recycle.list e o processo de remoção da máquina virtual é iniciado. Para fazer isso, o script vm_delete.sh é chamado, para o qual o número "spice_console" é transferido para a porta da VM como o parâmetro, que deve ser excluído.
/home/admin/scripts_vdi_new/vm_delete.sh Remover uma máquina virtual é uma operação bastante trivial, o script vm_delete.sh determina o nome da máquina virtual que possui a porta passada como o parâmetro de inicialização. A VM é forçada a parar, a VM é removida do hipervisor, o disco rígido virtual desta VM é excluído. A porta spice_console é removida de recycle.list. A execução do vm_delete.sh termina, a execução do vm_manager.sh continua
O script vm_manager.sh, no final das operações para limpar máquinas virtuais desnecessárias da lista waste.list, inicia o ciclo de criação de máquinas virtuais no pool.
O processo começa com a determinação das portas spice_console disponíveis para hospedagem. Para fazer isso, com base no parâmetro do arquivo de configuração "srv_start_port_pool", que define a porta inicial do pool "spice_console" de máquinas virtuais e o parâmetro "srv_pool_size", que determina o limite do número de máquinas virtuais, todas as variantes de porta possíveis são enumeradas sequencialmente. Para cada porta específica, é pesquisada em clear.list, waste.list, conn_wait.list, recycle.list. Se uma porta for encontrada em qualquer um desses arquivos, a porta será considerada ocupada e será ignorada. Se a porta não for encontrada nos arquivos especificados, ela será inserida no arquivo recycle.list e o processo de criação de uma nova máquina virtual será iniciado. Para fazer isso, o script vm_create.sh é chamado para o qual o número spice_console da porta para a qual você deseja criar uma VM é passado.
/home/admin/scripts_vdi_new/vm_create.sh O processo de criação de uma nova máquina virtual
O script vm_create.sh lê no arquivo de configuração o valor da variável "base_host" que determina a máquina virtual de amostra com base na qual o clone será feito. Descarrega a configuração xml da VM da base do hipervisor, realiza uma série de verificações na imagem de disco da VM e, após a conclusão bem-sucedida, cria o arquivo de configuração xml para a nova VM e a imagem de disco "clone vinculado" da nova VM. Depois disso, a configuração xml da nova VM é carregada no banco de dados do hipervisor e a VM é iniciada. A porta spice_console é transferida de recycle.list para clear.list. A execução do vm_create.sh termina e a execução do vm_manager.sh termina.
A próxima vez que você se conectar, começará do começo.
Para casos de emergência, o kit inclui um script vm_clear.sh que executa forçosamente todas as VMs do pool e as remove zerando os valores das listas. A chamada no estágio de carregamento permite iniciar (abaixo) a VDI do zero.
/home/admin/scripts_vdi_new/vm_clear.sh Sobre isso, gostaria de terminar a primeira parte da minha história. O exposto acima deve ser suficiente para os administradores de sistema experimentarem underVDI nos negócios. Se a comunidade achar esse tópico interessante, na segunda parte, falarei sobre a modificação do livecd Fedora e sua transformação em um quiosque.