dokuro Posté(e) le 28 décembre 2014 Signaler Share Posté(e) le 28 décembre 2014 Premièrement, un petit schema. Merci a Michael BIDEAU pour son talent graphique Les points forts de l'infra Cette infrastructure permet une haute disponibilite, par la redondance de tous les services, mais aussi une évolutivité importante grâce à la virtualisation. La mise en place de cette solution n'est donc pas des plus simple. Cependant, elle permet d'évoluer, en termes de visites / charge d'une façilité par la séparation initiale de tous les services. Les points faibles (oui il y en as, malheureusement) Vu le niveau technique de cette infra, et surtout due à la séparation des services, il est indispensable d'avoir un code propre et étudié pour fonctionner sur cette infra. Listes des serveurs virtuels, avec les applicatifs qui vont tourner dessus : Les routeurs Ils gèrent le routage entre les différentes classe IPs de l'infra structure, avec notemment les possibilites d'extension sur deux sites physiques. Liste des services : Postfix pour l'envoi de mails système Rsync, pour assurer le backup du service KeepAlived Pour assurer la redondance de la route par defaut pour les IPs internes Quagga, pour assurer un routage BGP entre plusieurs sites / prestataires réseau Bind - Afin d'assurer une résolution de nom pour les domaines hébergés OpenSSH Les load Balanceurs Ils assurent la répartition de la charge pour les différents services qui le nécessitent. Pour rappel : Le WEB Statique Le WEB Dynamique Le SQL Lecture La réception des mails Les protocoles de lecture de mails (POP(s) / IMAP(s)) Liste des services : Postfix pour l'envoi de mails système Rsync, pour assurer le backup du service KeepAlived Pour assurer la redondance et le load balancing OpenSSH Serveur WEB Dynamique Ces deux serveurs seront utilisé simultanément, afin de répartir la charge sur les deux. L'arrêt d'un des serveurs entraine une exclusion de celui-ci du pool WEB. Liste des services : Apache avec le module PHP pour interpreter le code source Eventuellement un accelerateur PHP, eaccelerator, APC ... Postfix pour l'envoi de mails via PHP & mails système Rsync, pour assurer le backup du service Un client NFS, pour acceder aux données OpenSSH Serveur Web Statique Ces serveurs seront eux aussi utilisés de manière simultanée. A l'inverse de leurs homologues dit dynamiques, ils ne serviront que du contenu statique. Liste des services : Nginx ou Lighttpd, avec possiblement une surcouche de cache via un proxy squid Postfix pour l'envoi de mails système Rsync, pour assurer le backup du service Un client NFS, pour acceder aux données OpenSSH Serveurs SQL Afin d'éviter des problèmes de duplication de clef primaire, il est nécéssaire d'écrire les données SQL sur un seul serveur, le serveur maitre. De ce fait, nous aurons un service SQL écriture en simple tolérance à la panne. Par ailleurs, afin d'éxploiter au maximum la puissance de calcul disponible, il est intéressant de répartir les lectures sur les n serveurs SQL. Les lectures SQL seront donc sur load balancées. Liste des services : MySQL Postfix pour l'envoi de mails système Rsync, pour assurer le backup du service KeepAlived pour assurer la redondance du service "écriture" OpenSSH Serveur de mails entrant Vu que les mails sont aussi importants que le service WEB, ils sont eux aussi redondés. Liste des services : Postfix Courier pour les couches IMAP / POP Rsync, pour assurer le backup du service OpenSSH Bind - Afin d'assurer une résolution de nom pour les domaines hébergés MySQL - Afin de gérer les boites mails et les alias en BDD Les serveurs de backup Et oui, il faut bien sauvegarder les données. Le principe est simple, le serveur de backup sur un serveur hôte sauvegarde les serveurs qui sont sur le second serveur hôte. Liste des services : Postfix pour l'envoi de mails système Rsync, pour assurer le backup du service / pour backuper OpenSSH Un démon NFS pour permettre la copie de DUMPS SQL / tar des sites si besoin Les machines de monitoring / graphs Afin d'assurer un suivi strict et régulier de l'infra, il est vital de la monitorer, pour déceller les défaillance d'une node, et intéréssant de grapher les serveurs et leurs ressources. Le serveur primaire assure donc le monitoring via Nagios, et le serveur secondaire assure le monitoring de backup et les graphs (via Cacti). Liste des services : Postfix pour l'envoi de mails système Rsync, pour assurer le backup du service / pour backuper OpenSSH Nagios Cacti KeepAlived Les Filers (Dynamique / statique / mails) Nous allons maintenant voir la couche données avec nos trois serveurs de fichiers. Pour chacun des couples de filer, les technologies utilisées seront très similaires. Liste des services : Postfix pour l'envoi de mails système Rsync, pour assurer le backup du service / pour backuper OpenSSH Un démon NFS Une surcouche de données DRBD pour assurer la réplication sur le second filer KeepAlived pour assurer la tolérence a la panne Réseau Afin de dissocier (encore) les trafics réseau, j'utilise des vlans. Ainsi, dans cette version théorique, chaque type de trafic interne (NFS WEB ou mail / SQL / Backup) sera associé a un vlan distinct, chacun dans sa classe IP. Cela aura pour effet de permettre une évolutivité réseau importante. En effet, même si je rajoute des hôtes, et que mon hébergeur ne peut me fournir des IPs dans la même classe, je peux gérer les accé aux ressources par classe IP interne. Nous aurons donc comme IPs : Publique : Une /29 associé afin de fournir des IPs à chacune des machines le nécessitant. (sera doublé lors de la mise en place de la redondance intersite) Trafic routé par nos deux routeurs Une /29 ou 2 /30 pour les interconnexion BGP avec notre hébergeur(sera doublé lors de la mise en place de la redondance intersite) Une /29 ou /30 pour assurer la redondace inter site (qui ne sera pas mise en place dans un premier temps Privé : Une /24 pour les connexions SSH Une /24 pour le service WEB statique Une /24 pour le service WEB dynamique Une /24 pour le NFS Web Une /24 pour le NFS Mail Une /24 pour le NFS pour les Dumps (export régulier de dumps sur les serveurs de backup) Une /24 pour le SQL Une /24 pour le backup Pour rappel, voici le nombre d'IP dans chacune des tailles de classes IP /30 : 4 IPs , 2 utilisables /29 : 8 IPs , 6 utilisables /28 : 16 IPs , 14 utilisables /27 : 32 IPs , 30 utilisables /26 : 64 IPs , 62 utilisables /25 : 128 IPs, 126 utilisables /24 : 256 IPs, 254 utilisables Comme vous le voyez, j'assure une énorme évolitivité dans mon plan d'adressage privé Ou puis-je trouver et faire entretenir une telle infra structure? Cette infra, ou toute autre infra structure plus adaptée à vos besoin peut être mise en place par moi même (je suis en cours de re-création d'entreprise), ou par WDMEDIA. SIVIT, depuis peu racheté par NERIM, mon ancien employeur, m'ayant banni de leur salon IRC, ne mérite plus, selon moi, que je leur fasse de la publicité. D'autant plus qu'il y a eu un turn-over très important dans l'équipe hébergement, ayant a mon sens fait baissé leur qualité. Leur réseau est aussi, pour le moment, très instable, j'ai pu constater des latences de 800 ms entre le serveur hébergeant ce site et le routeur. Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.