Esta é a segunda blogue de uma série 2-blog sobre a escalabilidade da plataforma DCHQ usando Weave como a camada de rede subjacente. O primeiro blog cobriu a implantação de 10.000 contentores em 10 Weave Clusters, cada um com 3 Cloud Servers sobre Rackspace com 4GB de memória e 2 CPUs.
Neste blog, vamos abordar a implantação de 2.000 contentores - mas em vez de usar 10 clusters com 3 servidores nuvem cada, estaremos usando um único cluster Weave com 30 servidores em nuvem . DCHQ não só automatiza a implantação eo gerenciamento de aplicativos, mas também automatiza a infra-estrutura de aprovisionamento e auto-scaling em 13 diferentes nuvens e plataformas de virtualização. Leia mais sobre este teste escalabilidade neste blog.
fundo
Enquanto a portabilidade de aplicativos (ou seja, ser capaz de executar o mesmo aplicativo em qualquer máquina Linux) ainda é o driver principal para a adoção de Linux Containers, mais vantagens chave é ser capaz de optimizar a utilização do servidor para que você possa usar todos os bits de computação. Claro que, para ambientes a montante, como PROD, você ainda pode querer dedicar mais do que suficiente CPU e memória para sua carga de trabalho -, mas em ambientes / Teste dev, que normalmente representam a maioria do consumo de recursos de computação em uma organização, otimizando a utilização do servidor pode levar a economias de custo significativas.
Isso tudo soa bem no papel - mas DevOps engenheiros e operadores de infra-estrutura ainda lutam com as seguintes perguntas:
- Como posso servidores de grupos em diferentes nuvens em agrupamentos que mapeiam para grupos empresariais, as equipes de desenvolvimento, ou projetos de aplicação?
- Como faço para monitorar esses aglomerados e obter insights sobre o consumo de recursos por diferentes grupos ou usuários?
- Como faço para configurar a rede entre os servidores em um cluster para que os recipientes em vários hosts podem se comunicar uns com os outros?
- Como faço para definir minha própria política de posicionamento baseado em capacidade para que eu possa usar todos os bits de computação em um cluster?
- Como posso automaticamente dimensionar o cluster para atender às demandas dos desenvolvedores para novas implantações de aplicativos baseados em contentores?
DCHQ, disponível em hospedados e on-premise versões, aborda todos esses desafios e oferece as mais avançadas políticas de provisionamento de infra-estrutura, auto-escala, agrupamento e de colocação para os operadores de infra-estrutura ou engenheiros DevOps.
- Um usuário pode registrar qualquer máquina Linux rodando em qualquer lugar, executando um script gerado automaticamente para instalar o agente DCHQ, juntamente com Docker ea camada de rede definida por software (opcional). Esta tarefa pode ser automatizada por meio de programação usando a nossa API de REST para criar "Servidores Docker" ( https://dchq.readme.io/docs/dockerservers )
- Alternativamente, DCHQ integra com 13 provedores de nuvem, permitindo aos usuários girar automaticamente a infra-estrutura virtual em vSphere, OpenStack, CloudStack, Amazon Elastic Cloud Computing, o Google Compute Engine, Rackspace, DigitalOcean, SoftLayer, Microsoft Azure, e muitos outros.
Construir O modelo de aplicativo para o cluster Nginx
Uma vez conectado para DCHQ (seja o DCHQ.io hospedado ou versão on-premise), um usuário pode navegar para App & Machine e clique sobre o + botão para criar um novo Docker Compose modelo.
Nós criamos um simples Cluster Nginx por causa deste teste escalabilidade. Você vai notar que o CLUSTER_SIZE parâmetro permite especificar o número de recipientes para lançar (com as mesmas dependências de aplicativos).
O mem_min parâmetro permite specifcy a quantidade mínima de memória que deseja alocar para o recipiente.
O anfitrião parâmetro permite que você especifique o host que você gostaria de usar para implementações de contêineres. Dessa forma, você pode garantir a alta disponibilidade para seus clusters de servidor de aplicativos em diferentes hospedeiros (ou regiões) e você pode cumprir com as regras de afinidade para garantir que o banco de dados é executado em um host separado, por exemplo. Estes são os valores suportados para o parâmetro host:
- host1, host2, host3 , etc. - seleciona uma série aleatoriamente dentro de um centro de dados (ou cluster) para implementações de contêiner
- <IP endereço 1, endereço IP 2, etc.> - permite que um usuário para especificar os endereços IP real para usar para implementações de contêiner
- <Hostname 1, Host 2, etc.> - permite que um usuário para especificar os nomes de host reais a ser usado para implantações de contentores
- Wildcards (por exemplo, "db- *", ou "app-srv- *") - para especificar os wildcards para uso dentro de um nome de host
Provisionamento de infra-estrutura subjacente On Any Nuvem
Depois que um aplicativo é salvo, um usuário pode registrar um provedor de nuvem para automatizar o provisionamento e auto-scaling de clusters em 13 pontos finais nuvem diferentes, incluindo vSphere, OpenStack, CloudStack, a Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, HP Pública nuvem, IBM SoftLayer, o Google Compute Engine, e muitos outros.
Primeiro, um usuário pode registrar um provedor de nuvem para Rackspace (por exemplo), navegando para provedores de nuvem e, em seguida, clicar no botão + para selecionar Rackspace. A API Key Rackspace precisa ser fornecido - que pode ser obtida a partir da seção Configurações de Conta.
Um usuário pode, então, criar um cluster com uma política de escala automática para girar automaticamente novas Cloud Servers. Isso pode ser feito ao navegar para Clusters de página e, em seguida, clicando no + botão. Você pode selecionar uma política de posicionamento por capacidade e, em seguida, Tecer como a camada de rede, a fim de facilitar a comunicação cross-recipiente seguro, protegido por senha em vários hosts dentro de um cluster. Neste caso, nós também definida uma política de escala de auto que vai rodar até servidores em nuvem neste agrupamento, até o limite máximo definido (neste caso 30 servidores em nuvem). Direitos granulares estão disponíveis para se certificar de que este cluster só pode ser usado pelos usuários 10 que estamos usando neste teste (user1@dchq.io, user2@dchq.io, ..., user10@dchq.io). Por último, os direitos podem ser definidos ao nível modelo (ou modelo de aplicativo) - para garantir que somente os aplicativos intitulada pode ser implantado para este cluster compartilhado. Neste caso, o cluster foi aberto a "todos os Blueprints".
Um usuário pode agora fornecer um número de Cloud Servers no cluster recém-criado, quer através do fluxo de trabalho baseado UI ou pela definição de um modelo de máquina de composição baseada em YAML simples que pode ser solicitada a partir da Biblioteca de autoatendimento.
Fluxo de trabalho baseado em UI - Um usuário pode solicitar Servidores Rackspace Nuvem navegando para Máquinas e depois clicar no + botão para selecionar Rackspace . Uma vez que o provedor de nuvem é selecionado, o usuário pode selecionar a região, tamanho e imagem necessários. Portas são abertas por padrão em servidores Rackspace Cloud acomodar alguns dos requisitos de porta (por exemplo, 32.000-59.000 para Docker, 6783 para Weave, e 5672 para RabbitMQ). Um cluster é selecionado e o número de Cloud Servers pode ser especificado.
Template Compose máquina baseada em YAML - Um usuário pode criar primeiro um modelo de máquina de compor para Rackspace navegando para Máquinas e selecionando Máquina Compose .
Os parâmetros suportados para o modelo de máquina Compose estão resumidos abaixo:
- Descrição : Descrição do modelo / template
- instanceType : Nuvem valor específico provedor (por exemplo general1-4)
- região : Nuvem valor específico provedor (por exemplo IAD)
- Imagem : Obrigatório - totalmente qualificado imagem ID / nome (por exemplo IAD / 5ed162cc-b4eb-4371-b24a-a0ae73376c73 ou vSphere VM Template nome)
- nome de usuário : Opcional - apenas para VM Template vSphere nome de usuário
- password : Opcional - apenas para VM Template vSphere senha criptografada. Você pode criptografar a senha utilizando o endpoint https://www.dchq.io/#/encrypt
- rede : Opcional - Nuvem valor específico provedor (por exemplo padrão)
- SecurityGroup : Nuvem valor específico provedor (por exemplo dchq-security-grupo)
- keyPair : Nuvem valor específico provedor (chave por exemplo, privados)
- OpenPorts : Opcional - valores de porta separados por vírgulas
- contar : Nº total de VM, o padrão é 1.
Uma vez que o modelo de máquina Compose é salvo, um usuário pode solicitar esta máquina do Self-Service Biblioteca . Um usuário pode clicar em Personalizar e, em seguida, selecionar o provedor de nuvem e Cluster para usar para provisionar esses servidores Rackspace nuvem.
Implantando O Cluster Nginx programaticamente Usando de DCHQ API REST do
Uma vez que os Cloud Servers são provisionados, um usuário pode implantar o cluster Nginx programaticamente usando de DCHQ API REST do. Para simplificar o uso da API do, um usuário precisará selecionar o cluster criado anteriormente como o cluster padrão. Isso pode ser feito ao navegar para o meu perfil , e em seguida, selecionando o cluster padrão necessário.
Uma vez que o cluster padrão é selecionado, em seguida, um usuário pode simplesmente executar o script a seguir onda que invoca a API "implantar" ( https://dchq.readme.io/docs/deployid ).
Nesse script onda simples, temos o seguinte:
- Um loop for, de 1 a 20
- Com cada iteração estamos implementando o aplicativo Nginx agrupados usando o cluster padrão atribuído a user1@dchq.io~~V
- user1% 40dchq.io é usado para user1@dchq.io onde símbolo @ é substituído pelo hexadecimal% 40
- @ Entre a senha e de acolhimento não é substituído por hex
- <id> refere-se ao Nginx ID aplicativo cluster. Isto pode ser recuperado por navegando até a Biblioteca > Personalizar para o cluster Nginx. A identificação deve ser no URL
- sleep 22 é usado entre cada iteração
- Depois de executar esse script, 200 contêineres Nginx teria sido implantado por user1@dchq.io - 20 iterações implantação de um cluster Nginx de 10 recipientes cada.
Em seguida, repetiu o mesmo processo para os outros usuários (user2@dchq.io, user3@dchq.io, ..., user10@dchq.io~~number=plural) - todos implantando no mesmo cluster compartilhado.
Você pode experimentar este script onda si mesmo. Você pode instalar DCHQ On-Premise ( http://dchq.co/dchq-on-premise.html ) ou inscrever-se em DCHQ.io Hospedado PaaS ( http://dchq.io ).
Acompanhamento A CPU, memória & S Utilização / do cluster, Servidores & Containers executando
DCHQ permite aos usuários monitorar a CPU, memória, disco e I / O dos clusters, anfitriões e recipientes.
- Para monitorar clusters, você pode simplesmente navegar para Clusters
- Para monitorar anfitriões, você pode simplesmente navegar para Máquinas
- Para monitorar recipientes, você pode simplesmente navegar para viver Apps
Nós rastreamos o desempenho dos anfitriões e clusters antes e depois lançamos os 2.000 contêineres.
Depois de girar até 2.000 recipientes, nós capturamos imagens dos gráficos de desempenho para o cluster. Você pode ver isso a utilização de memória agregados entre os servidores 30 nuvem no cluster estava em 81% .
Você pode ver que a maior utilização de memória nos servidores 30 nuvem no cluster estava em 84% .
Quando perfurados para baixo em um dos 30 hosts no cluster e viu mais detalhes como o # de contentores em execução no host em particular, o número de imagens puxado e, claro, a CPU / memória Utilização / Disco. Neste caso, a utilização de memória dessa máquina em particular foi de 83% .
Aqui está uma visão de todos os 200 clusters de Nginx em execução (em que cada grupo tinha 10 recipientes).
Conclusão
Orquestrar implantações de aplicativos baseados em Docker ainda é um desafio para os engenheiros muitas DevOps e operadores de infra-estrutura como eles muitas vezes lutam para gerenciar pools de servidores em várias equipes de desenvolvimento, onde os controles de acesso, monitoramento de rede, colocação por capacidade, auto-dimensionar as políticas e quota são aspectos fundamentais que precisam ser configurados.
DCHQ, disponível em hospedados e on-premise versões, aborda todos esses desafios e oferece as mais avançadas políticas de provisionamento de infra-estrutura, auto-escala, agrupamento e de colocação para os operadores de infra-estrutura ou engenheiros DevOps.
Para além das infra-estruturas de aprovisionamento e de clustering capacidades avançadas, DCHQ simplifica a conteinerização de aplicações empresariais através de um quadro composição aplicação antecipada que se estende Docker Compor com cross-imagem ligações ambiente variáveis, script bash plug-ins extensíveis que podem ser chamados no momento do pedido ou pós-disposição, e clustering aplicativo para alta disponibilidade em vários hosts ou regiões com suporte para auto escala.
para ter acesso aos modelos multi-camada de aplicativo Java out-of-box juntamente com a funcionalidade Application Lifecycle Management como monitoramento, atualizações de contentores, a escala in / out de entrega e contínua.
No comments:
Post a Comment