Le Kokiblog

Architecture multi-serveur, premier pas pour techniquement pérenniser son business

Posté le 13 Sep, 2023

Le passage d’une architecture mono à multi-serveurs s’accompagne de nouvelles contraintes essentiellement liées au partage des données entre les serveurs. Voici une liste assez exhaustive des questions à prendre en compte.

Où sont stockées les sessions utilisateurs ?

Dans un ordre décroissant orienté performance :

C’est Kokiris qui mettra en place le service de stockage de session partagé.

Comment dois-je accéder à MySQL ?

L’adresse localhost ne devra plus être utilisée, les chaînes de connexion php/python/autres devront pointer vers la VIP (adresse dédiée) que le support Kokiris vous communiquera à la livraison du serveur, exemple : 192.168.10.100.

C’est Vous qui devrez adapter vos chaînes de connexion php ou autre.

Comment est répartie la charge MySQL ?

Les serveurs MySQL sont en mode Master/Master, chacun se synchronisant sur l’autre.
Mais en termes d’accès, ils doivent être considérés comme Actif/Passif, les écritures ne se faisant qu’à un seul endroit.
La VIP ne pouvant s’activer que sur un seul serveur, la collision de clef est pratiquement impossible duplicate entry.
Vous pouvez bien entendu utiliser le serveur slave pour y effectuer des requêtes de lecture.
Les deux réplications sont monitorés par nos soins.

C’est Kokiris qui mettra en place la réplication et le monitoring

Comment est répartie la charge web ?

Par défaut, les requêtes clientes sont ventilées entre les serveurs de manière équitable : round robin. On peut altérer ce comportement en augmentant le poids d’un serveur, si par exemple ce dernier rencontre une charge excessive ou possède moins de ressources que l’autre.
On peut aussi ventiler les requêtes selon une stratégie active/passive, dans ce cas, un seul serveur recevra l’intégralité du trafic, le second restant en attente, ne devenant actif qu’en cas de non-réponse du premier.

C’est Kokiris qui configurera le load-balancer

Comment sont gérés les certificats SSL ?

Par défaut, en mode HTTP, un Ovh load-balancer pack1, peut porter au maximum 10 certificats, mais il n’implémente pas le HTTP/2

Dans ce cas, c’est Kokiris qui mettra en place les certificats

En mode TCP, architecture privilégiée pour des sites ambitieux, les front-end portent un reverse-proxy et dans ce cas, il n’y a pas de limitation sur le nombre de certificats utilisables ; le HTTP/2 est actif de fait et le proxy peut au besoin limiter le trafic en cas d’attaque.

Dans ce cas, c’est Vous qui mettrez en place les certificats.

Comment mon application va-t-elle gérer le SSL ?

L’application ne sait pas que le SSL est géré sur le load-balancer, elle verra du trafic arriver en HTTP alors qu’elle attend du HTTPS, elle risque alors de créer une boucle de redirection HTTP vers HTTPS.
La solution est la prise en charge par l’application de la gestion de l’entête HTTP X-Forwarded-Proto.

Comment sont partagées les données statiques ?

Elles peuvent être déployées et donc être disponible sur chacun des serveurs.
Elles peuvent être déployées sur le serveur maître pour être par la suite synchronisées vers le slave synchronisation-des-donnees.
Elles peuvent être stockées sur un équipement tiers : un Ovh nasha nfs, un stockage S3, etc.
Nous n’avons pas vraiment de recommandations, mais le déploiement sur chaque serveur ou sur système tiers est à privilégier, car le résultat est plus prédictible.

Comment sont partagées les données dynamiques, (le code) ?

Elles peuvent être déployées et donc disponible sur chacun des serveurs.
Elles peuvent être déployées sur le serveur maître pour être par la suite synchronisées vers le slave synchronisation-des-donnees.

Comment sont déployées les données statiques ?

Par FTP ou SFTP/SCP, méthode historique.
Par l’outil préféré du client.
Nous recommandons l’utilisation d’un outil de déploiement tel qu’Ansible, l’idéal restant un déploiement continu basé par exemple sur le Gitlab CI/CD.

Comment sont déployées les données dynamiques (le code) ?

Par le protocole historique qu’est le FTP ou bien, de manière plus sécurisé en SFTP/SCP (ssh).
Par l’outil préféré du client. Nous recommandons l’utilisation d’un outil de déploiement tel qu’Ansible, l’idéal restant un déploiement continu basé par exemple sur le Gitlab CI/CD.

Quelle url dois-je appeler ?

Durant le processus d’installation, nous vous donnerons l’adresse IP du load-balancer, celle-çi sera le point d’entrée vers vos applications.
Si vous utilisez Cloudflare, contactez-nous.

Puis-je accéder à mes serveurs slave ?

Nous bloquons par défaut l’accès au serveur slave, mais des exceptions peuvent être faites dans le cadre d’un déploiement ou bien pour un troubleshooting spécifique.

Quels outils de déploiement de code puis-je utiliser ?

Ansitrano
Ansible, exemple de playbook :

---
- hosts: webserver
 become: yes
 become_user: root
 vars:
   temp_repo_path: "/tmp_repo" # path to the temporary downloadfolder of the repo
 tasks:
 
   # Get the latest code from your GitHub code repository
   - name: Get latest Application Codebase
     git:
       repo: https://github.com/AnTheMaker/Pesto.git # place the HTTPS git URL of your codebase here
       version: main # replace this with the name of your "production" branch (in most cases "main" or "master")
       dest: "{{ temp_repo_path }}"
       single_branch: yes
       accept_hostkey: true
       depth: 1
 
     # if your git repository is private, you'll need to create a GitHub deploy key (https://docs.github.com/en/developers/overview/managing-deploy-keys#deploy-keys), upload the private key to your server and uncomment the following line:
     # key_file: ~/github_deploy_private_key.key
 
     register: code_upload # set a variable in Ansible if this task succeeds
 
#   do any additional tasks you may need to do. E.g. install composer packages: (uncomment/change as you like)
#   - name: Install Composer Packages
#     composer:
#       command: "install"
#       working_dir: "{{ temp_repo_path }}"
#     environment:
#       COMPOSER_NO_INTERACTION: "1"
#     when: code_upload.changed # only run this task when the code has changed
 
   - name: Replace live Codebase
     delegate_to: "{{ inventory_hostname }}"
     synchronize:
       src: "{{ temp_repo_path }}"
       dest: /var/www/
    ‘   recursive: yes
       delete: yes
     when: code_upload.changed # only run this task when the code has changed
 
   - name: Update Permissions
     file:
       path: /var/www/html
       state: directory
       recurse: yes
 
       # change the following two lines to the user of your webserver
       owner: www-data
       group: www-data

Auteur: Antonio M.