Para fornecer o serviço IaaS (Virtual Data Center), nós da
Rusonyx usamos a orquestra comercial
Flexiant Cloud Orchestrator (FCO). Essa solução possui uma arquitetura bastante única, que a distingue da bem conhecida do público em geral Openstack e CloudStack.
Como hipervisores de nós de computação, são suportados KVM, VmWare, Xen, Virtuozzo6 / 7, bem como contêineres do mesmo Virtuozzo. Dos armazenamentos suportados - local, NFS, Ceph e Virtuozzo Storage.
O FCO suporta a criação e o gerenciamento de vários clusters a partir de uma única interface. Ou seja, você pode gerenciar o cluster Virtuozzo e o cluster KVM + Ceph alternando entre eles clicando no mouse.
Em essência, o FCO é uma solução abrangente para provedores de nuvem, que, além da orquestração, também inclui cobrança, com todas as configurações, plug-ins de pagamento, contas, notificações, revendedores, tarifas e assim por diante. No entanto, a parte de cobrança não é capaz de cobrir todas as nuances russas; portanto, recusamos usá-la em favor de outra solução.
O sistema flexível de distribuição de direitos a todos os recursos da nuvem é muito agradável: imagens, discos, produtos, servidores, firewalls - tudo isso pode ser "revistado" e emitido direitos entre usuários e até mesmo entre usuários de clientes diferentes. Cada cliente pode criar vários data centers independentes em sua nuvem e gerenciá-los a partir de um único painel de controle.
Arquitetonicamente, o FCO consiste em várias partes, cada uma com seu próprio código independente e algumas com seu próprio banco de dados.
Skyline - interface do administrador e do usuário
Jade - lógica de negócios, cobrança, gerenciamento de tarefas
Tigerlily é um coordenador de serviço que gerencia e coordena a troca de informações entre lógica de negócios e clusters.
XVPManager - gerenciamento de elementos de cluster: nós, armazenamento, rede e máquinas virtuais.
XVPAgent - um agente instalado nos nós para interagir com o XVPManager
Uma história detalhada sobre a arquitetura de cada componente que planejamos incluir em uma série de artigos, a menos que, é claro, o tópico seja de interesse.
A principal vantagem do FCO deriva da sua "caixa". Oferece simplicidade e minimalismo. Para o nó de controle, uma máquina virtual no Ubuntu é alocada, na qual todos os pacotes necessários estão instalados. Todas as configurações são transferidas para os arquivos de configuração na forma de valor variável:
# cat /etc/extility/config/vars … export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000" export LIMIT_MAX_LIST_USER_DEFAULT="200" export LOGDIR="/var/log/extility" export LOG_FILE="misc.log" export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log" export LOG_FILE_LOG4JJADE="jade.log" export LOG_FILE_LOG4JTL="tigerlily.log" export LOG_FILE_LOG4JXVP="xvpmanager.log" export LOG_FILE_VARS="misc.log" …
Toda a configuração é corrigida inicialmente nos modelos e, em seguida, o gerador inicia
# build-config que formará o arquivo vars e instruirá os serviços a reler a configuração. A interface do usuário é agradável e pode ser facilmente identificada.
Como você pode ver, a interface consiste em widgets, cujo gerenciamento está disponível para o usuário. Ele pode facilmente adicionar / remover widgets da página, formando o painel de que ele precisa.
Apesar de sua proximidade, o FCO é um sistema altamente personalizável. Possui um grande número de configurações e pontos de entrada para alterar o fluxo de trabalho:
- Suplementos personalizados são suportados, por exemplo, você pode escrever seu próprio método de cobrança ou seu próprio recurso externo para fornecer ao usuário
- Os acionadores personalizados para determinados eventos são suportados, por exemplo, adicionando a primeira máquina virtual ao cliente quando ele é criado
- Widgets personalizados são suportados na interface, por exemplo, incorpore vídeos do youtube diretamente na interface do usuário.
Toda a personalização é escrita na linguagem FDL, baseada em Lua. Se você conhece Lua, não haverá problemas com o FDL.
Aqui está um exemplo de um dos gatilhos mais simples que usamos. Esse gatilho não permite que os usuários compartilhem suas próprias imagens com outros clientes. Fazemos isso para que um usuário não possa criar uma imagem maliciosa para outros usuários.
function register() return {"pre_user_api_publish"} end function pre_user_api_publish(p) if(p==nil) then return{ ref = "cancelPublishImage", name = "Cancel publishing", description = "Cancel all user's images publishing", triggerType = "PRE_USER_API_CALL", triggerOptions = {"publishResource", "publishImage"}, api = "TRIGGER", version = 1, } end -- Turn publishing off return {exitState = "CANCEL"} end
A função de registro será chamada pelo kernel do FCO. Retornará o nome da função a ser chamada. O parâmetro “p” desta função armazena o concurso de chamadas e, na primeira chamada, ele estará vazio (nulo). Isso nos permitirá registrar nosso gatilho. Em triggerType, mostramos que o gatilho é chamado ANTES da operação de publicação e se aplica apenas aos usuários. Para os administradores de sistema, é claro, permitimos que tudo seja publicado. Em triggerOptions, detalhamos as operações para as quais o gatilho será acionado.
E o mais importante, retorne {exitState = "CANCEL"}, e é por isso que o gatilho foi desenvolvido. Ele retornará a falha quando o usuário tentar compartilhar sua imagem no painel de controle.
Na arquitetura do FCO, qualquer objeto (disco, servidor, imagem, rede, adaptador de rede etc.) é representado como uma entidade de Recurso, que possui parâmetros comuns:
- Recurso uuid
- nome do recurso
- tipo de recurso
- UUID do proprietário do recurso
- status do recurso (ativo, inativo)
- metadados de recursos
- chaves de recurso
- UUID do produto ao qual o recurso pertence
- Recurso VDC
Isso é muito conveniente ao trabalhar na API, quando o trabalho com todos os recursos é realizado com o mesmo princípio. Os produtos são configurados pelo fornecedor e o cliente os solicita. Como nosso faturamento fica à margem, o cliente pode solicitar qualquer produto gratuitamente no painel. Será considerado posteriormente no faturamento. O produto pode ser - endereço IP por hora, um GB adicional de disco por hora ou apenas um servidor.
Você pode marcar determinados recursos com chaves para alterar a lógica de trabalhar com eles. Por exemplo, podemos marcar três nós físicos com a chave Weight e marcar alguns clientes com a mesma chave, destacando esses nós pessoalmente para esses clientes. Usamos esse mecanismo para clientes VIP que não gostam de vizinhos ao lado de suas VMs. A funcionalidade em si pode ser aplicada muito mais amplamente.
O modelo de licenciamento implica pagamento por cada núcleo de um processador de um nó físico. O custo também é afetado pelo número de tipos de cluster. Se você planeja usar juntos, por exemplo, KVM e VMware, o custo da licença aumentará.
O FCO é um produto completo, sua funcionalidade é muito rica; portanto, planejamos preparar vários artigos de uma só vez com uma descrição detalhada do funcionamento da parte da rede.
Tendo trabalhado com esta orquestra por vários anos, podemos marcá-la como muito adequada. Infelizmente, o produto não apresenta falhas:
- tivemos que otimizar o banco de dados, porque as consultas começaram a ficar mais lentas à medida que a quantidade de dados neles aumentava;
- após um acidente, devido a um bug, o mecanismo de recuperação não funcionou e tivemos que elevar as máquinas de clientes insatisfeitos com nosso próprio conjunto de scripts;
- o mecanismo de detecção de inacessibilidade do nó está conectado ao código e não pode ser personalizado. Ou seja, não podemos criar nossas próprias políticas para determinar a inacessibilidade de um nó.
- o registro nem sempre é detalhado. Às vezes, quando você precisa descer para um nível muito baixo para analisar um problema específico, o código-fonte de alguns componentes não é suficiente para entender os motivos;
TOTAL: no geral, a experiência do produto é boa. Estamos em constante contato com os desenvolvedores da orquestra. Os caras estão dispostos a cooperar construtivamente.
Apesar de sua simplicidade, o FCO possui ampla funcionalidade. Em artigos futuros, planejamos nos aprofundar nos seguintes tópicos:
- networking na FCO
- recuperação ao vivo e suporte ao protocolo FQP
- escrevendo plugins e widgets personalizados
- ligar serviços adicionais, como o Load Balancer e o Acronis
- backup
- mecanismo unificado para configurar e configurar nós
- processamento de metadados da máquina virtual
PS Escreva nos comentários se outros aspectos forem interessantes. Fique atento!