Em um determinado momento, uma tarefa apareceu - transferir um projeto existente e trabalhando ativamente no processo de produção para trabalhar em um cluster de servidores. Porque Como o projeto foi desenvolvido com base no 1C-Bitrix, foi decidido construir um cluster usando o "1C-Bitrix: Web environment". O objetivo deste evento é poder suportar cargas pesadas com o fluxo de visitantes do site, bem como a capacidade de escalar horizontalmente mais rapidamente no futuro.
Na verdade, se formos ao site do fornecedor, veremos que:
“1C-Bitrix: ambiente da Web” - o Linux é usado para instalação rápida e fácil de todo o software necessário para a operação dos produtos e soluções 1C-Bitrix nas plataformas Linux CentOS 6 (i386, x86_64) e CentOS 7 (x86_64). É necessário instalar em um CentOS "limpo", sem um servidor web já instalado.
A estrutura do “1C-Bitrix: ambiente da Web” - Linux inclui: servidor mysql, httpd, php, nginx, nodejs push-server, memcached, stunnel, catdoc, xpdf, munin, nagios, sphinx.
De fato, este pacote de software contém um LAMP configurado, um painel de controle do servidor do console, além de pacotes adicionais necessários para a operação de alguns módulos 1C-Bitrix. Todo o software é configurado levando em consideração os recursos do 1C-Bitrix, a saber:
- extensões necessárias instaladas (gd, zip, socket, mbstring)
- suporte a tags curtas ativado
- os valores necessários são definidos para os parâmetros memory_limit, max_input_vars, modo de segurança, opcache.validate_timestamps, opcache.revalidate_freq, mbstring.func_overload, default_charset, display_errors, etc.
- defina o mesmo fuso horário para o banco de dados, php e no próprio servidor
- e outros
Isso permite, na maioria dos casos, não se envolver na configuração e no ajuste do servidor.
Portanto, tínhamos 2 servidores de aplicativos (vamos chamá-los de app01 e app01), 2 servidores de banco de dados (db01, db02), 1 servidor para cache (cache01, você entende), mais precisamente, a ideia era implementar a estrutura do cluster de maneira semelhante. Sob esse plano, foram recebidos 5 servidores, com as versões mais recentes do centos7 instaladas neles (infelizmente, debian, ubuntu, fedora, rhel etc. não são adequados), exceto pelo sistema operacional, nada mais foi instalado nos servidores.
Porque Se montarmos um cluster, é necessário determinar qual dos servidores será o principal. Devido às peculiaridades dos pedidos de balanceamento para o aplicativo, um dos servidores em que o httpd funcionará também conterá o nginx. Ele também aceitará todas as solicitações recebidas e, em seguida, redirecionará a solicitação para um dos nós da web disponíveis. Escolhemos o servidor principal app01.
Outros trabalhos foram realizados de acordo com o seguinte plano:
1. Instale o bitrixenv
A instalação não implica conhecimento ou administração sobrenatural do linux. Vamos a cada servidor via ssh e executamos os seguintes comandos:
cd ~ wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh chmod +x bitrix-env.sh ./bitrix-env.sh
O Bitrixenv deve ser instalado em todos os servidores planejados para serem usados no cluster. Mesmo que o servidor funcione apenas como uma instância em cache, o bitrixenv é necessário, porque permite gerenciar todo o cluster a partir do servidor principal.
2. Configure o bitrixenv
Porque Se usarmos todo esse zoológico como um cluster, podemos configurar os servidores através do menu de ambiente no app01. Para fazer isso, acesse o servidor via ssh e execute o arquivo /root/menu.sh. No primeiro início, você precisa definir uma senha para o usuário do bitrix (uma operação semelhante deve ser executada em todos os servidores em que o site está programado para ser iniciado):
Na verdade, este é o usuário sob quem o aplicativo funcionará. Depois disso, vemos uma tela oferecendo para criar um pool de servidores:
Aqui, precisamos selecionar o primeiro item do menu. No processo de criação do ambiente, ele solicitará o nome do servidor atual e especificaremos app01:
Após a criação do pool, retornamos à primeira tela do ambiente, mas desta vez há muito mais pontos disponíveis:
Em geral, o ambiente está pronto e você pode usá-lo. Se não precisarmos de um cluster, poderemos terminar aqui, mas iremos além.
Agora precisamos adicionar todos os servidores disponíveis ao pool criado. Para fazer isso, use o primeiro item de menu e veja as seguintes opções:
Novamente, selecione o primeiro item de menu e especifique o ip do novo servidor, seu nome no cluster (o mesmo app02, db01, db02, cache01) e a senha raiz do servidor conectado. Assim, adicionamos cada servidor disponível, um por um. Depois que todos os servidores estiverem registrados no cluster, devemos obter algo parecido com esta lista na tela principal do ambiente:
A definição de funções de servidor por enquanto é adiada para a próxima etapa.
3. Transferência de projeto
Porque Como nosso aplicativo é executado inicialmente em um único servidor, o módulo de dimensionamento e gerenciamento de cluster está desativado, o banco de dados não é replicado. A transferência em si não é nada sobrenatural - empacotou o bitrix e as pastas de upload, removeu o despejo do banco de dados.
Depois que os arquivos e despejos estiverem prontos, vá para app01 e puxe o código do projeto através do git para a pasta padrão do site em bitrixenv - / home / bitrix / www, faça o download dos arquivos e despejo do banco de dados com wget ou curl, descompacte os arquivos e faça o upload Despejar no banco de dados em app01, transferir entradas cron.
Se seu aplicativo usa software adicional, é hora de instalá-lo e configurá-lo. No nosso caso, o supervisord e o RabbitMQ foram instalados e configurados, como o aplicativo funcionou usando filas.
Há uma pequena mas importante nuance. Ao transferir um site para um cluster, é necessário que os módulos de escala e cluster estejam desativados no site e os servidores do conjunto não estejam envolvidos no ambiente do cluster para o qual a transferência está planejada. Os servidores de cluster devem ser incluídos na operação somente depois que o site for movido e implantado no servidor principal. Caso contrário, o site não poderá determinar corretamente os servidores de cluster.
4. Ativando o Modo de Cluster
Depois que o aplicativo foi portado para app01 e verificamos a exatidão de seu trabalho, é hora de fazer a coisa mais interessante - dimensionamento. Primeiro, você precisa instalar os módulos de balança e cluster no painel de administração do 1C-Bitrix. Durante a instalação, nada de especial precisa ser feito, todo o trabalho continua.
Depois que os módulos estiverem instalados, acesse a conexão ssh com o servidor principal, e este é app01, e abra o menu bitrixenv (encontra-se em / root / menu.sh aqui). Antes de prosseguir com a configuração adicional, você precisa descobrir um ponto importante - o bitrixenv usa o conceito de "função de servidor". Realmente não importa como o servidor é chamado no pool, porque Como cada servidor contém todo o software incluído no pacote bitrixenv, sempre podemos atribuir uma ou mais funções a ele e podemos removê-las ou trocá-las por outras. As principais funções são mgmt (balanceador, ou seja, nginx), web (ou seja, httpd / apache), mysql_master e mysql_slave (instância do DB, escravo aparece quando começamos a replicação), memcached (servidor com memcached). A imagem geral agora está clara e decidimos começar com um servidor em cache. Para fazer isso, vá para o parágrafo
4. Configure memcahed servers > 1. Configure memcached service
e vemos uma solicitação para o nome do servidor que atuará como o servidor em cache do memcached. Já temos um servidor cache01 preparado para isso, então analisamos a lista de servidores disponíveis. Se cache01 estiver na lista, não haverá problemas de instalação e podemos atribuir ao servidor a função selecionada.
Nós inserimos o nome cache01, vemos que a tarefa para definir a função está na fila. Estamos aguardando a conclusão do trabalho em segundo plano e vemos um servidor pronto para trabalhar com a função de que precisamos.
É hora de adicionar um segundo servidor de aplicativos. Para fazer isso, siga o caminho
8. Manage web nodes in the pool > 1. Create web role on server,
onde precisamos especificar o nome do servidor e o método de sincronização entre o principal e o novo nó da web. Com base na documentação do bitrixenv e nos testes preliminares, foi suficiente para o nosso projeto escolher a primeira opção (copiar o projeto e definir as configurações do nó em uma etapa). Depois que o trabalho em segundo plano terminar, veremos algo assim no menu principal:
Observe que na coluna Funções, em frente ao servidor app02, a função da Web é indicada.
Resta lidar com o banco de dados, sua configuração leva mais tempo. Primeiro, explicarei brevemente como as funções do mysql são distribuídas no contexto do bitrixenv. Por padrão, a versão principal do banco de dados está no servidor principal do cluster. No nosso caso, foi necessário transferir o banco de dados para um servidor separado e adicionar outro servidor com uma versão escrava do banco de dados. No bitrixenv, você não pode simplesmente levar e transferir o mestre de um servidor para outro)
A sequência é a seguinte:
- Atribuímos o papel de mysql_slave ao servidor para o qual planejamos transferir o banco de dados
- No servidor de destino, alteramos o papel do mysql_slave para o papel do mysql_master (automaticamente, o antigo mysql_master entra no modo mysql_slave)
- Exclua a função mysql_slave no servidor original, o antigo mestre
- ...
- LUCRO !!!
Seguimos essa lógica dessa maneira:
Fui para
3. Configure MySQL servers > 4. Create MySQL slave
Indicamos o servidor ao qual queremos atribuir a função mysql_slave - db01. Estamos aguardando a conclusão do trabalho em segundo plano e vemos o seguinte resultado:
Ok, agora vamos para
3. Configure MySQL servers > 5. Change MySQL master
Especifique app01 e aguarde. Como resultado, você deve ver algo assim:
Lenta e inevitavelmente, abordamos a instalação da última função - mysql_slave. Para isso, é necessário repetir as etapas pelas quais definimos essa função para o db01, mas especifique o db02 já.
Por fim, todos os servidores estão conectados e configurados.
5. Desempenho de ajuste
Depois que o cluster estiver pronto, existem alguns recursos na configuração do aplicativo que permitem otimização adicional:
- Trabalhamos com sessões. Descrito em detalhes aqui . Em resumo, alterne o armazenamento da sessão no memcached.
- Exclua os arquivos /bitrix/php_interface/after_connect_d7.php e /bitrix/php_interface/after_connect.php, porque comandos deles interrompem o pipeline do cluster (se o bitrixenv não for usado, é melhor deixá-los).
- Aumentamos a quantidade de memória alocada pelo memcached e configuramos a porcentagem de uso de servidores com a função memcached para 100%.
- Desativar módulos php: apcu, ldap
- Desative os módulos de barramento "Compactação" e "Análise da Web" (se possível).
- Considere usar um cache local. Mais detalhes são descritos aqui . No nosso caso, não houve aumento, mas a ideia é interessante. A solução possui alguns recursos:
- O número de instâncias armazenadas em cache deve ser igual ao número de nós da web.
- Para retornar o cache composto pelo nginx, diretamente do memcached local, você precisa cavar na configuração do nginx, pois ele não funciona imediatamente.
- Mova a execução de todos os agentes para cron.
Conclusões
Na estrutura deste artigo, examinamos a sequência de etapas necessárias para configurar um cluster de servidores com base no bitrixenv, bem como algumas possíveis armadilhas. Com base nos resultados do trabalho com o bitrixenv e no cluster, podemos destacar os prós e contras dessa abordagem:
Pros bitrixenv
- Tempo de instalação
A instalação e a configuração básica levam menos de 30 minutos. Não há necessidade de configurar elementos LAMP (tanto a integração desses serviços entre si, como para o trabalho correto dos projetos no 1C-Bitrix). - Serviços para acelerar o site
Serviços instalados e configurados que permitem organizar o armazenamento em cache mais rápido via cache de memcached em vez de arquivos, pesquisar usando o mecanismo sphinx e a funcionalidade de videochamadas e chats no portal corporativo (módulo nginx push & pull). Além disso, o nginx no ambiente é configurado de forma que, quando você ativa as opções correspondentes no site e no menu bitrixenv, o cache é enviado usando o nginx diretamente do memcached (ignorando httpd e php) - Agrupamento
A capacidade de ativar a replicação de banco de dados, sem escolher as configurações do MySQL. Conectando um número arbitrário de nós da web que serão sincronizados automaticamente entre si e nós armazenados em cache. Gerenciamento do balanceamento de carga nos nós da Web e do memcached, no menu bitrixenv e no painel de administração do projeto no 1C-Bitrix. Além disso, adicionar novos servidores e funções a eles não causa um projeto simples (exceto talvez as funções de servidores de banco de dados)
Contras bitrixenv
- O balanceador está sempre com o nó da web principal
Porque já tínhamos nosso próprio balanceador, fomos confrontados com o fato de que é impossível abandonar o balanceador incorporado no bitrixenv. É impossível incluindo coloque-o separadamente do nó da web principal. - Muito software extra para algumas funções
Porque Como cada servidor no pool contém a versão completa do ambiente, os nós db são httpd, memcached, sphinx, mesmo que não sejam usados. Da mesma forma, você pode encontrar o MySQL em um servidor que lida apenas com armazenamento em cache, mas, neste caso, o MySQL pode ser parado no menu do ambiente ou no painel de administração do site. - Php funciona no modo apache2handler
Não há como habilitar o php com segurança no modo fcgi, sem mencionar o modo nginx + php-fpm. Além disso, não funcionará para alterar a versão php, sem dançar com um pandeiro.
Fontes:
www.1c-bitrix.ru/products/env
dev.1c-bitrix.ru/community/blogs/rns/hidden-features-of-work-with-sessions.php
dev.1c-bitrix.ru/community/blogs/rns/the-use-of-local-caches-in-the-cluster.php
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&INDEX=Y
dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=37&INDEX=Y