J'ai 23 serveurs Web - je dois effacer tous les serveurs - sans perte de service sur les sites hébergés sur eux

D'accord, c'est donc un défi et j'ai du mal à le planifier, principalement en raison du manque d'expérience. Cependant, c'est devenu une tâche dans mon travail et je le fais principalement en solo avec une main supplémentaire.

Je suis à l'aise avec Linux et tous ces serveurs sont Debian ou CentOS. Certains sont des VPS, des hôtes partagés et d'autres des VM de cloud. Je suis nouveau dans l'entreprise et je n'ai eu le temps qu'au cours des derniers mois de faire le point sur les problèmes en suspens. Ils exécutent tous plesk ou cpanel.

J'ai trouvé que ces serveurs n'étaient jamais configurés, juste achetés et des sites jetés dessus avec une administration très basique au cours des deux dernières années (nettoyage de l'espace disque et tâches de gestion de domaine / hébergement principalement). Aucun iptable n'a été installé et aucune mesure de sécurité n'a été prise. Ces serveurs sont donc criblés. Je pense que la meilleure solution ici est de recommencer à zéro et de consolider notre hébergement sur moins de serveurs, car ils venaient d'acheter de nouveaux serveurs partagés à volonté. Je pense que nous pouvons soutenir l'ensemble de notre clientèle sur environ 1/4 de notre cluster.

Mon problème est que je ne sais pas comment planifier ce déménagement. Cela nécessitera BEAUCOUP de sites mobiles et de modifications DNS. Je pense qu'il serait sage de demander conseil à tous les sorciers qui traitent ce genre de choses régulièrement ou au moins ont l'expérience pour me diriger dans la bonne direction.

Boue

— Boue
source

"J'ai du mal à le planifier principalement en raison d'un manque d'expérience." Vous devez absolument vous procurer une copie de The practice of system and network administration (aka le livre Limoncelli). Il contient probablement des guides étape par étape pour presque toutes les tâches auxquelles vous êtes susceptible de faire face en tant qu'administrateur système

— Journeyman Geek

Et je ne voudrais pas insulter le point, mais si vous pouvez l'éviter, cpanel est assez notoirement peu sûr. Si vous le pouvez, gérez les choses de la manière «appropriée». Bien sûr, tout dépend de vos besoins.

— Journeyman Geek

Merci beaucoup pour votre aide, votre solution ci-dessous m'a donné un bon cadre de travail. Je suis inexpérimenté mais je ne suis pas un noob. Je pense que je peux y faire face et le temps est de mon côté heureusement. Je vais prendre une copie de ce livre - cela ressemble au nouvel ajout parfait à ma bibliothèque de bureau. (Ça pousse si vite: | Je n'ai jamais pensé!)

— Mud

Je viens de terminer le dernier module d'une majeure en cyberforensic et gestion de la sécurité de l'information. C'est le livre que j'aurais aimé connaître plus tôt. Voilà, Mandia et Prosise's Incident Response and Cyber Forensics et Eoughan Casey's Cybercrime and Digital Evidence sont ce que j'ai recommandé à mes camarades de classe comme raison essentielle. C'est un livre génial , qui est susceptible de me suivre pour mon prochain travail, et peut-être celui après ça.

— Journeyman Geek

Les panneaux d'administration sont hors sujet . Même la présence d'un panneau d'administration sur un système, car ils prennent le contrôle des systèmes de manière étrange et non standard, ce qui rend difficile, voire impossible, pour les administrateurs système réels de gérer les serveurs normalement , et ont tendance à indiquer des questions de faible qualité de utilisateurs avec une connaissance insuffisante de ce site.

— HopelessN00b

Il n'y a pas de solution simple à cela - ce sera probablement une route longue et ennuyeuse pour faire bouger tout. Je commencerais par quelques choses, mais le livre que j'ai recommandé dans les commentaires contient probablement quelques détails. Je vois ici quatre étapes principales: l'inventaire, le redéploiement, les tests et l'acceptation.

Qu'est-ce que j'héberge en ce moment

Si vous ne l'avez pas déjà fait, faites un inventaire complet de ce que vous avez et de ce que vous utilisez maintenant. Identifiez quelles sont les ressources essentielles et ce qui ne fait que rester là. Cette question sur SF peut être un bon début, mais naturellement, vous devrez l'ajuster pour un environnement debianisque - peut - être comme ça . C'est l' étape la plus critique .

Les serveurs «Web» ne sont pas tous les mêmes - vérifiez si vous exécutez un processus qui exécute son propre serveur Web (comme Django) ou s'il s'agit d'un serveur Web autonome comme Apache.

réévaluer la configuration actuelle pour les meilleures pratiques

Utilisez-vous des versions EOLed de votre système d'exploitation et d'autres logiciels? Pouvez-vous migrer? À quels problèmes feriez-vous face? Y a-t-il des risques de sécurité connus? Puis-je tout normaliser en une seule version de tous mes logiciels? Puis-je automatiser mes processus de déploiement et dans quelle mesure (regarder marionnette et chef).

créer un ensemble de tests pour chaque serveur

Faites une liste de ce qui doit fonctionner et comment vous allez le tester

décider vers quoi vous vous dirigez

De cette façon, vous pouvez choisir le meilleur processus P2V ou V2V pour vos besoins.

décider quoi consolider

Vous pouvez choisir d'exécuter plusieurs ensembles de services qui étaient auparavant séparés sur un même serveur. Vous pouvez également choisir d'exécuter des machines virtuelles. L'exécution de machines virtuelles très spécifiques à une tâche (vous pouvez en redémarrer une sans affecter d'autres choses) et le regroupement de tâches similaires (vous avez donc moins de systèmes logiques à entretenir) présentent des avantages.

configurer un environnement de test isolé

De cette façon, vous pouvez configurer et tester un déplacement du système sans qu'il ne gêne la production. Vous pourrez probablement le faire sur un seul serveur exécutant des machines virtuelles.

avoir une zone de transit pour les systèmes testés

Déplacez les machines virtuelles vers la zone de transit et testez-les une dernière fois

Utilisez les fenêtres de maintenance pour passer aux nouveaux systèmes.

Définissez un dns ttl court pour les systèmes qui ont été migrés avec succès et modifiez le nom de domaine et d'autres paramètres pertinents au cours d'une fenêtre de maintenance. Testez à nouveau. Gardez un œil sur les erreurs une fois le nouveau serveur déployé

Ne détruisez pas les anciennes installations de serveur avant d'avoir vérifié que la nouvelle fonctionne.

Couvrez-vous. Si quelque chose ne va pas, à court terme, vous pouvez toujours revenir à l'ancien serveur.

— Journeyman Geek
source

Merci beaucoup Journeyman Geek bien que je vous considère vraiment comme un Artisan: D

— Mud

+ beaucoup, si je le pouvais, pour tout cela. La seule chose que j'ajouterais est que, car cela prendra un certain temps, obtenez l'adhésion de la direction à une période de stabilité pendant que vous planifiez, testez et exécutez le déménagement. Pendant cette période de stabilité, aucun nouveau serveur Web ne peut être créé et aucun changement que vous n'approuvez personnellement et n'implémentez ne peut être apporté à un serveur existant. Sinon, vous essayez de copier soigneusement et professionnellement une cible en mouvement fou et stupide. Pensez également à la façon dont vous contrôlerez les modifications sur les serveurs après avoir effectué le déménagement, ou vous devrez tout recommencer assez tôt.

— MadHatter

Bon point MadHatter, j'ai une bonne ligne de communication avec les supérieurs, ils comprennent que la sécurité passe avant tout par les données de nos clients et que ce processus est inévitable et qu'il ne peut être interrompu que si longtemps.

— Mud