Para fornecer serviços IaaS (Virtual Data Center), nós usamos um orquestrador comercial (FCO). Esta solução possui uma arquitetura bastante única, que a distingue do Openstack e CloudStack, conhecidos do público em geral.
KVM, VmWare, Xen, Virtuozzo6/7, bem como contêineres do mesmo Virtuozzo são suportados como hipervisores de nós de computação. As opções de armazenamento suportadas incluem armazenamento local, NFS, Ceph e Virtuozzo.
O FCO oferece suporte à criação e gerenciamento de vários clusters a partir de uma única interface. Ou seja, você pode gerenciar um cluster Virtuozzo e um cluster KVM + Ceph alternando entre eles com um clique do mouse.
Em sua essência, o FCO é uma solução abrangente para provedores de nuvem, que, além da orquestração, também inclui faturamento, com todas as configurações, plugins de pagamento, faturas, notificações, revendedores, tarifas e assim por diante. No entanto, a parte de cobrança não é capaz de cobrir todas as nuances russas, por isso abandonamos seu uso em favor de outra solução.
Estou muito satisfeito com o sistema flexível de distribuição de direitos para todos os recursos da nuvem: imagens, discos, produtos, servidores, firewalls - tudo isso pode ser “compartilhado” e concedido 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.
Linha do horizonte – interface de administração e usuário
Jade – lógica de negócios, faturamento, gerenciamento de tarefas
Tigerlily – coordenador de serviços, 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.
Agente XVPA – um agente instalado nos nós para interagir com o XVPManager
Planejamos incluir uma história detalhada sobre a arquitetura de cada componente em uma série de artigos, se, é claro, o tema despertar interesse.
A principal vantagem do FCO decorre da sua natureza “em caixa”. Simplicidade e minimalismo estão ao seu serviço. Para o nó de controle, é alocada uma máquina virtual no Ubuntu, na qual estão instalados todos os pacotes necessários. Todas as configurações são colocadas em arquivos de configuração na forma de um 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 é inicialmente editada em templates, depois o gerador é iniciado
#build-config que irá gerar um arquivo vars e comandar os serviços para relerem a configuração. A interface do usuário é agradável e pode ser facilmente marcada.
Como você pode ver, a interface consiste em widgets que podem ser controlados pelo usuário. Ele pode facilmente adicionar/remover widgets da página, criando assim o painel de que precisa.
Apesar da sua natureza fechada, 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:
- Plug-ins 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
- Gatilhos personalizados para determinados eventos são suportados, por exemplo, adicionar a primeira máquina virtual a um cliente quando ele é criado
- Widgets personalizados na interface são suportados, por exemplo, incorporando um vídeo do YouTube diretamente na interface do usuário.
Toda customização é escrita em FDL, que é baseado em Lua. Se você conhece Lua, não haverá problemas com FDL.
Aqui está um exemplo de um dos gatilhos mais simples que usamos. Este gatilho não permite que os usuários compartilhem suas próprias imagens com outros clientes. Fazemos isso para evitar que um usuário crie 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. Ele retornará o nome da função a ser chamada. O parâmetro “p” desta função armazena o contexto da chamada, e na primeira vez que for chamada estará vazio (nil). O que nos permitirá registrar nosso gatilho. Em triggerType indicamos que o gatilho é invocado ANTES da operação de publicação e afeta apenas os usuários. Claro, permitimos que os administradores do sistema publiquem tudo. Em triggerOptions detalhamos as operações para as quais o gatilho será acionado.
E o principal é return {exitState = “CANCEL”}, por isso o gatilho foi desenvolvido. Retornará falha quando o usuário tentar compartilhar sua imagem no painel de controle.
Na arquitetura FCO, qualquer objeto (disco, servidor, imagem, rede, adaptador de rede, etc.) é representado como uma entidade Recurso, que possui parâmetros comuns:
- UUID do recurso
- nome do recurso
- tipo de recurso
- UUID do proprietário do recurso
- status do recurso (ativo, inativo)
- metadados de recursos
- chaves de recursos
- UUID do produto que possui o recurso
- recurso VDC
Isso é muito conveniente quando se trabalha com uma API, quando todos os recursos funcionam de acordo com o mesmo princípio. Os produtos são configurados pelo fornecedor e encomendados pelo cliente. Como nosso faturamento é lateral, o cliente pode solicitar livremente qualquer produto do painel. Será calculado posteriormente no faturamento. O produto pode ser um endereço IP por hora, um GB adicional de disco por hora ou apenas um servidor.
As chaves podem ser usadas para marcar determinados recursos para alterar a lógica de trabalhar com eles. Por exemplo, podemos marcar três nós físicos com a chave Peso e marcar alguns clientes com a mesma chave, alocando assim esses nós pessoalmente a esses clientes. Usamos esse mecanismo para clientes VIP que não gostam de vizinhos próximos às suas VMs. A funcionalidade em si pode ser usada de forma muito mais ampla.
O modelo de licenciamento envolve o pagamento por cada núcleo de processador de um nó físico. O custo também é afetado pelo número de tipos de cluster. Se você planeja usar KVM e VMware juntos, por exemplo, o custo da licença aumentará.
O FCO é um produto completo, sua funcionalidade é muito rica, por isso pretendemos preparar vários artigos ao mesmo tempo com uma descrição detalhada do funcionamento da parte de rede.
Tendo trabalhado com este orquestrador durante vários anos, podemos considerá-lo muito adequado. 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 nelas aumentava;
- após um acidente, o mecanismo de recuperação não funcionou devido a um bug e tivemos que recuperar os carros de clientes infelizes usando nosso próprio conjunto de scripts;
- O mecanismo para detectar a indisponibilidade do nó está embutido no código e não pode ser personalizado. Ou seja, não podemos criar nossas próprias políticas para determinar a indisponibilidade de um nó.
- o registro nem sempre é detalhado. Às vezes, quando você precisa descer a um nível muito baixo para entender um problema específico, você não tem código-fonte suficiente para alguns componentes entenderem o porquê;
TOTAL: Em geral, as impressões do produto são boas. Estamos em contato constante com os desenvolvedores do orquestrador. Os caras estão dispostos a uma cooperação construtiva.
Apesar de sua simplicidade, o FCO possui ampla funcionalidade. Em artigos futuros pretendemos nos aprofundar nos seguintes tópicos:
- networking na FCO
- fornecendo recuperação ao vivo e protocolo FQP
- escrevendo seus próprios plugins e widgets
- conectando serviços adicionais, como Load Balancer e Acronis
- cópia de segurança
- mecanismo unificado para configurar e configurar nós
- processando metadados de máquinas virtuais
ZY Escreva nos comentários se você estiver interessado em outros aspectos. Fique atento!
Fonte: habr.com