À un certain moment, une tâche est apparue: transférer un projet de production existant et actif dans un cluster de serveurs. Parce que le projet a été développé sur la base de 1C-Bitrix, il a été décidé de construire un cluster utilisant "1C-Bitrix: environnement Web". Le but de cet événement est de pouvoir supporter de lourdes charges avec l'afflux de visiteurs du site, ainsi que la capacité d'évoluer horizontalement plus rapidement à l'avenir.
En fait, si nous allons sur le site Web du fournisseur, nous verrons que:
«1C-Bitrix: environnement Web» - Linux est utilisé pour une installation rapide et facile de tous les logiciels nécessaires au fonctionnement des produits et solutions 1C-Bitrix sur les plates-formes Linux CentOS 6 (i386, x86_64) et CentOS 7 (x86_64). Il est nécessaire d'installer sur un CentOS «propre», sans serveur Web déjà installé.
La structure de «1C-Bitrix: environnement Web» - Linux comprend: mysql-server, httpd, php, nginx, nodejs push-server, memcached, stunnel, catdoc, xpdf, munin, nagios, sphinx.
En fait, ce progiciel contient une LAMPE configurée, un panneau de commande de serveur de console, ainsi que des progiciels supplémentaires nécessaires au fonctionnement de certains modules 1C-Bitrix. Tous les logiciels sont configurés en tenant compte des fonctionnalités de 1C-Bitrix, à savoir:
- extensions nécessaires installées (gd, zip, socket, mbstring)
- prise en charge des balises courtes activée
- les valeurs nécessaires sont définies pour les paramètres memory_limit, max_input_vars, mode sans échec, opcache.validate_timestamps, opcache.revalidate_freq, mbstring.func_overload, default_charset, display_errors, etc.
- définir le même fuseau horaire pour la base de données, php et sur le serveur lui-même
- et autres
Cela permet dans la plupart des cas de ne pas s'engager dans la configuration et le réglage du serveur.
Donc, nous avions 2 serveurs d'applications (appelons-les app01 et app01), 2 serveurs db (db01, db02), 1 serveur pour la mise en cache (cache01, vous comprenez), plus précisément, l'idée était d'implémenter la structure du cluster de manière similaire. Dans le cadre de ce plan, 5 serveurs ont été reçus, avec les dernières versions de centos7 installées sur eux (malheureusement, debian, ubuntu, fedora, rhel, etc. ne conviennent pas), sauf pour os, rien d'autre n'a été installé sur les serveurs.
Parce que Si nous assemblons un cluster, il est nécessaire de déterminer lequel des serveurs sera le principal. En raison des particularités de l'équilibrage des demandes vers l'application, l'un des serveurs sur lesquels httpd fonctionnera contiendra également nginx. Il acceptera également toutes les demandes entrantes, puis redirigera la demande vers l'un des nœuds Web disponibles. Nous avons choisi le serveur principal app01.
Les travaux se sont poursuivis selon le plan suivant:
1. Installez bitrixenv
L'installation n'implique pas une connaissance ou une administration surnaturelle de Linux. Nous allons sur chaque serveur via ssh et exécutons les commandes suivantes:
cd ~ wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh chmod +x bitrix-env.sh ./bitrix-env.sh
Bitrixenv doit être installé sur tous les serveurs dont l'utilisation est prévue dans le cluster. Même si le serveur ne fonctionne que comme une instance memcached, bitrixenv est nécessaire, car vous permet de gérer l'intégralité du cluster à partir du serveur principal.
2. Configurer bitrixenv
Parce que Si nous utilisons tout ce zoo comme un cluster, nous pouvons configurer les serveurs via le menu environnement sur app01. Pour ce faire, accédez au serveur via ssh et exécutez le fichier /root/menu.sh. Au premier démarrage, vous devez définir un mot de passe pour l'utilisateur bitrix (une opération similaire doit être effectuée sur tous les serveurs sur lesquels le site doit être lancé):
En fait, c'est l'utilisateur sous lequel l'application fonctionnera. Après cela, nous voyons un écran proposant de créer un pool de serveurs:
Ici, nous devons sélectionner le premier élément de menu. Dans le processus de création de l'environnement, il demandera le nom du serveur actuel, puis nous spécifierons app01:
Une fois le pool créé, nous revenons au premier écran de l'environnement, mais cette fois il y a beaucoup plus de points disponibles:
En général, l'environnement est prêt et vous pouvez l'utiliser. Si nous n'avons pas besoin d'un cluster, nous pourrions terminer ici, mais nous irons plus loin.
Nous devons maintenant ajouter tous les serveurs disponibles au pool créé. Pour ce faire, utilisez le premier élément de menu et voyez les options suivantes:
Encore une fois, sélectionnez le premier élément de menu et spécifiez l'ip du nouveau serveur, son nom dans le cluster (le même app02, db01, db02, cache01) et le mot de passe racine du serveur connecté. Ainsi, nous ajoutons chaque serveur disponible un par un. Une fois que tous les serveurs sont enregistrés dans le cluster, nous devrions obtenir quelque chose comme cette liste sur l'écran principal de l'environnement:
La définition des rôles de serveur pour l'instant est reportée à l'étape suivante.
3. Transfert de projet
Parce que Étant donné que notre application s'exécute initialement sur un seul serveur, le module de mise à l'échelle et de gestion de cluster est désactivé, la base de données n'est pas répliquée. Le transfert lui-même n'a rien de surnaturel - il a compressé les dossiers bitrix et upload, supprimé le vidage de la base de données.
Une fois les archives et les vidages prêts, accédez à app01 et tirez le code du projet via git dans le dossier par défaut du site dans bitrixenv - / home / bitrix / www, téléchargez les archives et le vidage de la base de données à l'aide de wget ou curl, décompressez les archives et téléchargez Vider dans la base de données sur app01, transférer les entrées cron.
Si votre application utilise un logiciel supplémentaire, il est temps de l'installer et de le configurer. Dans notre cas, supervisord et RabbitMQ ont été installés et configurés, comme l'application a fonctionné en utilisant des files d'attente.
Il y a une petite mais importante nuance. Lors du transfert d'un site vers un cluster, il est nécessaire que les modules de mise à l'échelle et de cluster soient désactivés sur le site et que les serveurs de pool ne soient pas impliqués dans l'environnement du cluster vers lequel le transfert est prévu. Les serveurs de cluster doivent être inclus dans l'opération uniquement après le déplacement et le déploiement du site sur le serveur principal. Sinon, le site ne pourra pas déterminer correctement les serveurs de cluster.
4. Activation du mode cluster
Après que l'application a été portée sur app01 et que nous avons vérifié l'exactitude de son travail, il est temps de faire la chose la plus intéressante: la mise à l'échelle. Vous devez d'abord installer les modules de balance et de cluster dans le panneau d'administration 1C-Bitrix. Pendant l'installation, rien de spécial ne doit être fait, tout le travail continue.
Une fois les modules installés, accédez à la connexion ssh avec le serveur principal, c'est app01, et ouvrez le menu bitrixenv (lies /root/menu.sh ici). Avant de poursuivre la configuration, vous devez découvrir un point important - bitrixenv utilise le concept de «rôle serveur». Peu importe le nom du serveur dans le pool, car chaque serveur contient tous les logiciels inclus dans le package bitrixenv, nous pouvons toujours lui attribuer un ou plusieurs rôles, et nous pouvons les en retirer ou les échanger contre d'autres. Les rôles principaux sont mgmt (équilibreur, c'est-à-dire nginx), web (c'est-à-dire httpd / apache), mysql_master et mysql_slave (instance DB, l'esclave apparaît lorsque nous commençons à faire la réplication), memcached (serveur avec memcached). L'image générale est maintenant claire et nous avons décidé de commencer avec un serveur memcached. Pour ce faire, allez au paragraphe
4. Configure memcahed servers > 1. Configure memcached service
et nous voyons une demande pour le nom du serveur qui servira de serveur memcached. Nous avons déjà un serveur cache01 préparé pour cela, nous examinons donc la liste des serveurs disponibles. Si cache01 est sur la liste, il n'y a aucun problème d'installation et nous pouvons donner au serveur le rôle sélectionné.
Nous entrons le nom cache01, nous voyons que la tâche de définition du rôle est mise en file d'attente. Nous attendons la fin des travaux d'arrière-plan et nous voyons un serveur prêt à travailler avec le rôle dont nous avons besoin.
Il est temps d'ajouter un deuxième serveur d'applications. Pour ce faire, suivez le chemin
8. Manage web nodes in the pool > 1. Create web role on server,
où nous devons spécifier le nom du serveur et la méthode de synchronisation entre le nœud principal et le nouveau nœud Web. Sur la base de la documentation bitrixenv et des tests préliminaires, il a suffi à notre projet de choisir la première option (copier le projet et configurer les configs de nœuds en une seule étape). Une fois le travail en arrière-plan terminé, nous devrions voir quelque chose comme ça dans le menu principal:
Notez que dans la colonne Rôles en face du serveur app02, le rôle Web est indiqué.
Reste à gérer la base de données, sa configuration prend le plus de temps. Tout d'abord, je vais expliquer brièvement comment les rôles mysql sont distribués dans le contexte de bitrixenv. Par défaut, la version principale de la base de données se trouve sur le serveur principal du cluster. Dans notre cas, il était nécessaire de transférer la base de données vers un serveur distinct et d'ajouter un autre serveur avec une version esclave de la base de données. Dans bitrixenv, vous ne pouvez pas simplement prendre et transférer le maître d'un serveur à un autre)
La séquence est la suivante:
- Nous donnons le rôle de mysql_slave au serveur vers lequel nous prévoyons de transférer la base de données
- Sur le serveur cible, nous changeons le rôle de mysql_slave en rôle de mysql_master (automatiquement, l'ancien mysql_master passe en mode mysql_slave)
- Supprimez le rôle mysql_slave sur le serveur d'origine, l'ancien maître
- ...
- PROFIT !!!
Nous avons suivi cette logique de cette manière:
Je suis allé à
3. Configure MySQL servers > 4. Create MySQL slave
Nous avons indiqué le serveur auquel nous voulons donner le rôle mysql_slave - db01. Nous attendons l'achèvement des travaux de fond et nous voyons le résultat suivant:
Ok, maintenant nous allons
3. Configure MySQL servers > 5. Change MySQL master
Spécifiez app01 et attendez. En conséquence, vous devriez voir quelque chose comme ceci:
Lentement et inévitablement, nous avons abordé l'installation du dernier rôle - mysql_slave. Pour cela, il est nécessaire de répéter les étapes par lesquelles nous définissons un tel rôle pour db01, mais spécifiez déjà db02.
Enfin, tous les serveurs sont connectés et configurés.
5. Performances de réglage
Une fois le cluster prêt, certaines fonctionnalités de la configuration de l'application permettent une optimisation supplémentaire:
- Nous pompons le travail avec des sessions. Décrit en détail ici . En bref - changer de stockage de session dans memcached.
- Supprimez les fichiers /bitrix/php_interface/after_connect_d7.php et /bitrix/php_interface/after_connect.php, car leurs commandes interrompent le pipeline de cluster (si bitrixenv n'est pas utilisé, il vaut mieux les laisser).
- Nous augmentons la quantité de mémoire allouée par memcached et définissons le pourcentage d'utilisation des serveurs avec le rôle memcached à 100%.
- Désactiver les modules php: apcu, ldap
- Désactivez les modules de bus «Compression» et «Web analytics» (si possible).
- Pensez à utiliser un cache local. Plus de détails sont décrits ici . Dans notre cas, il n'y a pas eu d'augmentation, mais l'idée est intéressante. La solution a quelques fonctionnalités:
- Le nombre d'instances memcached doit être égal au nombre de nœuds Web.
- Pour retourner le cache composite par nginx, directement à partir du memcached local, vous devez creuser dans la configuration nginx, cela ne fonctionne pas hors de la boîte.
- Déplacez l'exécution de tous les agents vers cron.
Conclusions
Dans le cadre de cet article, nous avons examiné la séquence d'étapes requises pour configurer un cluster de serveurs basé sur bitrixenv, ainsi que certains pièges possibles. Sur la base des résultats du travail avec bitrixenv et du cluster, nous pouvons mettre en évidence les avantages et les inconvénients de cette approche:
Bitrixenv
- Temps d'installation
L'installation et la configuration de base prennent moins de 30 minutes. Il n'est pas nécessaire de configurer les éléments LAMP (à la fois l'intégration de ces services entre eux et pour le bon travail des projets sur 1C-Bitrix). - Services pour accélérer le site
Services installés et configurés qui vous permettent d'organiser une mise en cache plus rapide via memcached plutôt que des fichiers, de rechercher en utilisant le moteur sphinx et la fonctionnalité des appels vidéo et des chats sur le portail d'entreprise (module push & pull nginx). De plus, nginx dans l'environnement est configuré de telle manière que lorsque vous activez les options correspondantes sur le site et dans le menu bitrixenv, le cache est envoyé en utilisant nginx directement à partir de memcached (en contournant httpd et php) - Regroupement
La possibilité d'activer la réplication de la base de données, sans choisir les paramètres MySQL. Connexion d'un nombre arbitraire de nœuds Web qui seront automatiquement synchronisés entre eux et de nœuds memcached. Gestion de l'équilibrage de charge sur les nœuds web et memcached à la fois depuis le menu bitrixenv et via le panneau d'administration du projet sur 1C-Bitrix. De plus, leur ajouter de nouveaux serveurs et rôles ne provoque pas un projet simple (sauf peut-être pour les rôles de serveurs de base de données)
Contre bitrixenv
- L'équilibreur est toujours avec le nœud Web principal
Parce que nous avions déjà notre propre équilibreur, nous étions confrontés au fait qu'il était impossible d'abandonner l'équilibreur intégré à bitrixenv. Il est impossible notamment placez-le séparément du nœud Web principal. - Beaucoup de logiciels supplémentaires pour certains rôles
Parce que Étant donné que chaque serveur du pool contient la version complète de l'environnement, il s'avère que les nœuds db sont httpd, memcached, sphinx, même s'ils ne sont pas utilisés. De même, vous pouvez trouver MySQL sur un serveur qui ne s'occupe que de la mise en cache, mais dans ce cas, MySQL peut être arrêté dans le menu de l'environnement ou le panneau d'administration du site. - Php fonctionne en mode apache2handler
Il n'y a aucun moyen d'activer php en toute sécurité en mode fcgi, sans parler du mode nginx + php-fpm. De plus, cela ne fonctionnera pas pour changer la version php, sans danser avec un tambourin.
Sources:
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