Para fornecer o serviço IaaS (Data Center Virtual), utilizamos um orquestrador comercial (FCO). Essa solução possui uma arquitetura bastante única, que a distingue das conhecidas Openstack e CloudStack.
Como hipervisores para nós compute, suportamos KVM, VmWare, Xen, Virtuozzo6/7, bem como contêineres do mesmo Virtuozzo. Os armazenamentos suportados incluem local, NFS, Ceph e Virtuozzo Storage.
O FCO suporta a criação de múltiplos clusters e seu gerenciamento a partir de uma única interface. Ou seja, é possível gerenciar um cluster Virtuozzo e um cluster KVM + Ceph alternando entre eles com um clique.
Essencialmente, o FCO é uma solução abrangente para provedores de nuvem, que além da orquestração inclui faturamento, com todas as configurações, plugins de pagamento, faturas, notificações, revendedores, tarifas e muito mais. No entanto, a parte de faturamento não consegue cobrir todas as nuances russas, por isso optamos por não utilizá-la em favor de outra solução.
A flexível estrutura de distribuição de direitos sobre todos os recursos da nuvem é muito gratificante: imagens, discos, produtos, servidores, firewalls - tudo isso pode ser compartilhado e atribuídos direitos entre usuários, até mesmo entre usuários de diferentes clientes. Cada cliente pode criar diversos data centers independentes em sua nuvem e gerenciá-los a partir de um único painel.
Arquitetonicamente, o FCO é composto por várias partes, cada uma com seu próprio código independente e, algumas, com seu próprio banco de dados.
Skyline – interface administrativa e do 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 a lógica de negócios e os clusters.
XVPManager – gerenciamento dos elementos do cluster: nós, armazenamento, rede e máquinas virtuais.
XVPAgent – agente instalado nos nós para interagir com o XVPManager
Pretendemos incluir uma descrição detalhada da arquitetura de cada componente em uma série de artigos, se, é claro, o assunto gerar interesse.
A principal vantagem do FCO decorre de sua 'caixinha'. Você tem à sua disposição simplicidade e minimalismo. Para o nó de gerenciamento, é alocada uma única máquina virtual com Ubuntu, na qual todos os pacotes necessários são instalados. Todas as configurações são colocadas em arquivos de configuração no formato variável-valor:
# 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 nos templates e, em seguida, o gerador é iniciado.
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Como pode ser visto, a interface consiste em widgets, cujo gerenciamento é acessível ao usuário. Ele pode facilmente adicionar/remover widgets da página, formando assim o dashboard desejado.
Apesar de sua natureza fechada, o FCO é um sistema altamente personalizável. Ele possui inúmeras configurações e pontos de entrada para alterar o fluxo de trabalho:
- Suporta plugins personalizados; por exemplo, você pode escrever seu próprio método de cobrança ou um recurso externo para fornecer ao usuário.
- Suporta gatilhos personalizados para eventos específicos, como adicionar a primeira máquina virtual ao cliente no momento da sua criação.
- Suporta widgets personalizados na interface, como embutir vídeos do YouTube diretamente na interface do usuário.
Toda a personalização é feita na linguagem FDL, que é baseada em Lua. Se você conhece Lua, não terá 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 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 register será chamada pelo núcleo do FCO. Ela retornará o nome da função que deve ser chamada. O parâmetro 'p' desta função armazena o contexto da chamada e, na primeira chamada, ele estará vazio (nil). Isso nos permitirá registrar nosso gatilho. Em triggerType, indicamos que o gatilho é chamado ANTES da operação de publicação e se aplica apenas aos usuários. Para administradores do sistema, é claro, permitimos a publicação de tudo. Em triggerOptions, detalhamos as operações para as quais o gatilho será ativado.
E o mais importante – return {exitState = 'CANCEL'}, que é para o que o gatilho foi desenvolvido. Ele retornará uma 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 Resource, 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 do recurso
- chaves do recurso
- UUID do produto ao qual o recurso pertence
- VDC do recurso
Isso é muito conveniente ao trabalhar com API, onde todas as operações com recursos podem ser feitas de maneira uniforme. Os produtos são configurados pelo provedor, enquanto os clientes fazem os pedidos. Como a cobrança está separada, os clientes podem solicitar livremente qualquer produto através do painel. Ele será contabilizado posteriormente na cobrança. O produto pode ser – um endereço IP por hora, um GB adicional de disco por hora ou simplesmente um servidor.
As chaves podem ser usadas para marcar recursos específicos para alterar a lógica de operação com eles. Por exemplo, podemos marcar três nós físicos com a chave Weight e marcar alguns clientes com esta mesma chave, destacando assim esses nós para estes clientes específicos. Esse mecanismo é utilizado para clientes VIP que preferem não ter vizinhos ao lado de suas VMs. A funcionalidade em si pode ser aplicada de forma muito mais ampla.
O modelo de licenciamento implica pagamento por cada núcleo do processador do nó físico. O custo também é afetado pela quantidade de tipos de clusters. Se for planejado usar junto, por exemplo, KVM e VMware, o custo da licença aumentará.
FCO é um produto completo, com uma funcionalidade muito rica, por isso planejamos preparar vários artigos com uma descrição detalhada do funcionamento da parte de rede.
Após trabalhar com este orquestrador por alguns anos, podemos considerá-lo muito competente. Infelizmente, o produto não está isento de falhas:
- tivemos que otimizar o banco de dados, pois as consultas começaram a desacelerar com o aumento da quantidade de dados;
- após um incidente devido a um bug, o mecanismo de recuperação não funcionou, e tivemos que restaurar as máquinas dos infelizes clientes com um conjunto de scripts próprios;
- o mecanismo de detecção de inatividade de nó está embutido no código e não pode ser personalizado. Ou seja, não podemos criar nossas próprias políticas de definição de inatividade de nó.
- O registro nem sempre é detalhado. Às vezes, quando é necessário descer a um nível muito baixo para entender um problema específico, falta o código-fonte de alguns componentes para compreender as causas;
TOTAL: No geral, as impressões sobre o produto são boas. Estamos em contato constante com os desenvolvedores do orquestrador. Os caras estão abertos à colaboração construtiva.
Apesar da sua simplicidade, o FCO possui ampla funcionalidade. Em futuros artigos, planejamos aprofundar os seguintes temas:
- organização da rede no FCO
- garantia de recuperação ao vivo e protocolo FQP
- escrita de plugins e widgets personalizados
- integração de serviços adicionais, como Load Balancer e Acronis
- backup
- mecanismo unificado de configuração e ajuste de nós
- processamento de metadados de máquinas virtuais
P.S. Comente se outros aspectos forem de seu interesse. Fique ligado!
Fonte: habr.com
