Archives de catégorie : Services cloud

Patching out of band, cas concrêt

C’est quand on traite des sujets qui n’arrivent jamais que ça tombe. J’avais publié voilà quelques jours une série de billets sur le Patch Management d’une infrastructure de type cloud privé. Certaines personnes m’ont demandé pourquoi devait-on prévoir un processus pour les patchs out of band, … La réponse est tombée ces jours-ci : Microsoft Security Advisory 3108638.

L’alerte est d’importance car ça touche l’Hyperviseur. En lisant plus précisément le bulletin de sécurité, on découvre que la « faille » ne se trouve pas dans Hyper-V mais dans le processeur lui-même. Conséquence, c’est toutes les versions d’Hyper-V qui sont affectées :

  • Windows 2008
  • Windows 2008 R2
  • Windows 2012
  • Windows 2012 R2
  • Windows 8.1
  • Windows 10

C’est disponible dans Windows Update, donc pour action immédiate. Vu que c’est une problématique indépendante du logiciel, tous les Hyperviseurs sont donc affectés. Une recherche rapide sur Google Bing vous donnera les liens pour les autres hyperviseurs du marché :

Remarque : Il ne faut pas voir de mauvais esprit anti-VMWARE de ma part mais Google / bing n’a pas été mon ami pour trouver l’information chez eux sans accès à la Knowledge Base.

Alors convaincu qu’il est important d’avoir un process de patch management out of band dans votre infrastructure Cloud privé? Maintenant, vous avez deux choix :

  • Choix n°1 : Tester le déploiement en urgence à l’arrache sans concertation avec vos locataires avec un résultat attendu.

clip_image001

clip_image002

Alors, prêt à patcher?

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – Bonus : Les urgences

Jusqu’à maintenant, on a parlé de patching organisé. Cependant, on aura certainement un jour à traiter une urgence, avec un RSI qui nous impose le patching de notre infrastructure dans des délais beaucoup plus court que les cycles de maintenance que nous pouvons proposer. Que ce soit dans le contexte d’un cloud privé ou hybride, il faudra impliquer nos locataires. Il y a de grandes chances que le problématique rencontrée par l’hébergeur impacte aussi le locataire (cas Heartbleed). Il devra aussi prendre ses responsabilités. Si son application a bien été pensée pour la scalabilité et la résilience, alors cela devrait bien se passer. Netflix en a fait l’expérience, c’est un enseignement à méditer : Lessons Netflix Learned from the AWS Outage.

Le problème, c’est comment y faire face quand ça nous tombe dessus. Réagir implique d’organiser un cycle de maintenance dans l’urgence, donc communiquer auprès de nos locataires pour les informer des impacts sur leurs workloads. Le risque avec les cycles de maintenance exceptionnels, c’est que c’est une organisation lourde, organisée dans l’urgence, donc un fort risque d’avoir des problèmes. A côté de cela, on a déjà des cycles de maintenance en place. Donc, de mon point de vue les stratégies sont les suivantes :

  • Tenir jusqu’au prochain cycle de maintenance. Ce qui implique que les cycles de maintenances sont rapprochés et qu’on peut tenir jusqu’au prochain, genre chaque week-end. Ça peut permettre de patcher une partie de l’infrastructure en cumulant patching Microsoft et urgence au sein de la même plage de maintenance. Avec nos runbooks qui se ressemblent beaucoup, c’est juste une histoire d’intégration.
  • Improviser. Généralement, ça ressemble à du freestyle sans filet, on connait tous les résultats.
  • Appeler la terre entière pour demander à redémarrer la plateforme, ce qui va détruire nos SLA à 0 et ruiner la confiance de nos locataires

Ma préférence va à la première stratégie. Plus votre infrastructure est importante plus il devient difficile d’organiser des actions dans l’urgence. Les dépendances deviennent de plus en plus nombreuses. En ayant des cycles de maintenance courts, il est plus simple d’inscrire des actions urgentes dans ces cycles de maintenance plutôt que d’introduire des cycles de maintenance exceptionnels qu’il est complexe d’organiser sous contrainte de temps. C’est une solution envisageable uniquement si on est capable de mettre en place des mesures de mitigation pour parer aux risques encourus jusqu’à ce que l’infrastructure soit totalement patchée.

Etre en situation d’urgence sans préparation, c’est le mur assuré. Le problème, c’est qu’il faut bien apprendre. Pour cette raison, l’organisation de cycles de maintenance dans l’urgence ne doit pas être rejetée. Cela peut effectivement générer des problèmes mais on a beaucoup à apprendre de ces incidents si on en sort avec :

  • Un REX, ce qu’on en a appris, ce qu’il faut corriger
  • Un plan d’action pour prendre en compte les corrections
  • Des processus éprouvés et partagés

Après, il faut valider que nos corrections techniques / processus vont dans le bon sens. Pour cela rien de vaut de se remettre en situation de risque. Je ne dis pas qu’il faut planter tout son Cloud privé mais créer une situation de risque contrôlée

clip_image002

C’est là qu’un environnement de Prototypage un tant soit peu représentatif prend tout son intérêt!. Pour nous, c’est encore un sujet en cours de réflexion pour lequel on espère poser les bases prochainement.

L’idée générale serait d’organiser des campagnes de « Stress test » pour tester aussi bien l’infrastructure, que les processus et les équipes. Ce type de campagne devrait être organisé au moins deux fois par an. Plus, c’est qu’on a eu beaucoup trop d’urgences dans l’année écoulée. C’est possible mais mettre en place un environnement contrôlé prend du temps. Moins, c’est prendre le risque d’oublier ce qu’on veut qualifier. Quelques conseils pour organiser ces Stress tests :

  • Disposer d’un environnement de prototypage représentatif est l’idéal mais ce n’est pas toujours possible. Il faudra certainement isoler une partie de l’environnement de production
  • Procéder par itérations. On ne peut pas tout tester en un seul cycle annuel
  • Se fixer des objectifs réalistes

Pour conclure, la conception et la mise en place du Patch Management d’un cloud privé prend du temps, beaucoup de temps. Dans notre approche, nous avons tenu à observer quelques règles :

  1. Si le design ressemble à l’étoile de la mort, c’est pas bon
  2. Plus on complexifie les processus, plus on va jongler avec des briques
  3. Une brique qui tombe ça fait mal
  4. Toujours garder en mémoire les trois premiers points

Voilà pour le Patch Management d’une infrastructure cloud privé basée sur les produits System Center. Pour les locataires, c’est une autre histoire qui peut se résumer ainsi : Pets or Cattle. Nos locataires doivent t-ils être au petits soin pour leurs machines virtuelles ou les traiter comme du bétail? Ce sera un autre sujet de discussion.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°5 : Les cycles de maintenance

C’est bien d’automatiser au maximum, encore faut-il planifier ces opérations. Doit-on planifier toutes ces opérations selon le même cycle de maintenance « long » (option big-bang au risque de se transformer en big-badaboum) ou des cycles « courts » (option « blind-test » pour la découverte des bugs / comportements non prévu)? La réponse est bien plus compliquée. Déjà, tous les types de Patching ne s’inscrivent pas dans le même cycle de maintenance. Raisonnons donc en fonction des différents domaines :

  • Mise à niveau Pilotes / Logiciels bas niveau des Hyper-V : Pour maintenir la stabilité de la plateforme et le support des éditeurs, on est obligé de suivre un rythme soutenu. Certes, on n’est pas obligé de suivre au jour le jour et de s’imposer des cycles courts mais on doit quand même suivre. On aura besoin d’un à deux cycles de maintenance par an. A mon sens, difficile de faire plus car il faudra du temps pour valider que les changements opérés produisent bien les effets escomptés et qu’on n’observe pas de régression pouvant affecter nos SLA et par extension les SLA de nos locataires.
  • Patch Management Microsoft : On est tous d’accord pour suivre le rythme mensuel imposé par Microsoft. C’est sportif mais pas impossible. En fonction de la taille de l’infrastructure, on devra découper en plusieurs phases. Par exemple, patcher un certain nombre de châssis par semaine sur un cycle d’un mois. A mon sens, c’est une approche à privilégier car avec Windows 10 et Windows Server 2016, la notion de « Ring » va changer les choses. Devra t’on passer sur le modèle Long-Term Branch? C’est une bonne question, pas encore assez de recul pour juger. Par contre le choix du mode d’installation Nano devrait nous faciliter grandement la tâche pour réduire drastiquement le nombre de correctifs à installer et le nombre de redémarrages nécessaires.
  • Patch Management « Out of band » : Là, c’est la criticité qui impose le cycle. La première option serait de travailler dans le mode urgence. Pas évident à organiser et le résultat risque d’être approximatif. On peut aussi prévoir de pré-réserver des créneaux pour réaliser ce type d’opération et les utiliser ou non. C’est l’option que je préfère. On évite l’organisation dans l’urgence et on inscrit cela dans un cycle régulier, plus facile à maîtriser. Après, on peut prévoir d’intégrer ce type de patching dans le cycle du Patch Management Microsoft. C’est envisageable si on a bien prévu un cycle de maintenance court. On profite du créneau horaire du premier pour intégrer le second.
  • Patch Management de la Fabric : Avec les solutions Cloud Privé / Hybride de Microsoft, c’est facile, les équipes System Center fournissent des Update Rollup tous les trimestres. Autant on n’a pas de problème ou presque à appliquer les correctifs Microsoft & Out of Band sur notre Fabric, autant les updates UR sont trop spécifiques et nécessitent trop de tests. Pour cette raison, choix a été fait de ne pas suivre le rythme de publication de Microsoft. Il a été décidé de sauter un UR sur deux sauf si l’UR en question nous corrige des problèmes nous impactant ou apportant des fonctionnalités requises par nos locataires. En plus chaque UR apporte son lot de nouvelles fonctionnalités à mettre en place / qualifier, …

clip_image001[4]

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°4 : Patch Management de la Fabric

Mon préféré. Le premier qui déploie des UR de System Center en automatique, il prend aussi le chemin du mur mais avec un Jetpack dans le dos. Pour bien comprendre le problème, faut découvrir ce qui se cache dans les Updates Rollup de la gamme System Center. Tous les trimestres, Microsoft livre une nouvelle fournée. A ce jour, le dernier disponible est l’UR8 : KB3096378 : Update Rollup 8 for System Center 2012 R2.

Les KB System Center, c’est aussi digeste que l’encyclopédie. Pour Rappel, la gamme System Center ça couvre :

  • App Controller (Un truc qui a dû servir une fois)
  • Data Protection Manager (on n’y échappe pas au saucissonneur de baies de disque)
  • Operations Manager (SCOM pour les intimes)
  • Orchestrator
  • Service Management Automation
  • Service Manager (SCSM mais SM pour les intimes, …)
  • Service Reporting (Le petit dernier de la génération 2012R2)
  • Virtual Machine Manager
  • Service Provider Foundation
  • Windows Azure Pack
  • Windows Azure Pack WebSites

C’est bon ou on en rajoute ? Subtilité supplémentaire, d’un point de vue support Microsoft indique que tous ces composants doivent nécessairement être au même niveau pour être supportés. Donc pas la peine d’envisager un déploiement progressif. Dans notre contexte, App Controller et Service Reporting n’étant pas déployés, c’est déjà cela de gagné. Maintenant essayons de voir l’étendue des problèmes qu’on va rencontrer :

  • Les agents  : Certains produits tel que DPM, SCOM et SCVMM reposent sur des agents installés qu’il faut aussi mettre à niveau (SIC). Qui dit installation implique redémarrage, c’est par exemple le cas de SCVMM.
  • Les dépendances entre les produits : Qui dit nouvelle version de Management Pack SCOM dit importation de celui-ci dans SCSM ainsi que dans son Data WareHouse.
  • Les actions pré/post installation : Y a quelques produits ici et là qui ont besoin d’actions pré-post installation en PowerShell. Le genre de d’opérations qu’on ne pourra pas automatiser en plus, …
  • L’ordre d’installation : SCSM est un excellent exemple puisque c’est :
  1. Data WareHouse Server
  2. Primary management Server
  3. Secondary Management Servers
  4. All analyst consoles
  5. Self-Service Portal

Je suis presque sûr que tout le monde aurait commencé par le Primary Server SCSM. Perdu, …

Pour toutes ces raisons, on s’est contenté d’un processus de mise à niveau qui est encore manuel / semi-automatique. L’opération étant très chronophage, on n’arrive pas encore à suivre le rythme imposé par Microsoft avec une fournée d’ Update Rollup par trimestre. Conséquence, on s’est limité à appliquer un Update Rollup sur deux, sauf si la stabilité de la plateforme nous impose d’aller plus vite. Ce choix n’est pas sens conséquence. Actuellement, nous sommes en cours de migration UR5 vers UR7, on est donc en retard. A première vue, c’est simple, il suffit de suivre les KB. Sauf que les KB ont été écrites pour upgrader depuis la version précédente, pas celle d’avant. Dans l’UR6, il y a des Management Pack SCOM qui ont été mis à jour, pas dans UR7. Encore faut-il relire la KB de l’UR6 pour le découvrir. Les Updates Rollup sont cumulatifs, pas les KB de déploiement associées. Jusqu’ici c’était simple. Bientôt, notre « machin », devra évoluer / muter et intégrer d’autres composants tel que :

  • Service Provider Foundation
  • Service Management Automation
  • Service Reporting
  • Windows Azure Pack
  • Windows Azure Pack WebSites

A ce moment on pourra dire que notre « machin » va muter en super étoile de la mort. Pour rappel, voilà à quoi ressemble une infrastructure Windows Azure Pack un tant soit peu disponible :

clip_image001

Et encore, je ne suis pas tout à fait d’accord avec le schéma ci-dessus. Pour moi le portail d’administration de Windows Azure Pack est nécessairement en haute disponibilité avec deux instances. Lorsqu’on va introduire Windows Azure Pack (yumi!!), on va devoir révolutionner nos méthodes. Windows Azure Pack repose sur des Web services opérant en « State-less » avec un Load Balancer devant. Notre processus devra intégrer ces Load Balancers dans le processus de Patching pour activer / désactiver les instances de Web Services publiés. Juste pour vous donner une idée, allez relire un billet publié cette année sur DirectAccess : Monitoring DirectAccess with Kemp. C’est exactement la même problématique mais appliqué à six ou sept Web Services accessibles via un Load Balancer mutualisé. Ça promet d’être très fun.

Si jamais on arrive à intégrer tout cela, on pourra s’attaquer au patching d’une infrastructure WebSites de Windows Azure Pack répartie entre plusieurs châssis répartis eux même entre deux datacenters. Si vous avez un trou de mémoire, y j’ai écrit quelques billets sur le sujet : Architecture Windows Azure Pack WebSites–Introduction. Comme une image vaut mille mots, je pense que là vous avez compris l’étendue du problème, encore des Web services et des Load-Balancers :

clip_image003

Ce qui nous sauve avec l’architecture WebSites, c’est qu’elle a été conçue pour supporter la défaillance d’une ou plusieurs instances de chaque rôle (il y a juste une exception). Il faut juste pas tenter de mettre à niveau toutes les instances d’un même rôle en même temps, sinon c’est big badaboum comme disait Leeloo.

Alors, toujours SCCM/Windows Update en mode, je déploie comme un goret ? C’est là qu’on commence à apprécier le moteur d’orchestration des mises à jour de Microsoft Cloud Platform System. Pour l’instant, impossible pour nous de le concurrencer. Respect, c’est un super boulot. En fait, il gère tous les aspects du Patch Management que nous avons abordés jusqu’à maintenant mais en mieux.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°3 : Patch Management "Out of band"

De quoi parle-t-on ? Ben des correctifs qui ne sont pas dans Windows Update, pas disponibles nativement dans SCCM. Selon les organisations, organiser le déploiement de correctifs out-of band dans SCCM, c’est un processus qui peut s’avérer long. Le problème, c’est que bien souvent, les correctifs out-of band, quand on en a besoin, c’est pour la veille. Faudra donc développer un processus automatisé pour déployer ces correctifs quand on en a besoin, donc ASAP. Si vos processus internes permettent de publier ces correctifs dans SCCM rapidement, c’est parfait. Dans notre contexte, il nous faut un processus de déploiement « alternatif » en attendant que les correctifs soient disponibles dans SCCM.

Qu’est-ce qu’on entend par correctifs « Out of band» ? C’est par exemple ceux que le support Microsoft vous recommande d’installer uniquement si vous rencontrez le problème. Dans notre contexte, la liste était déjà très fournie :

Là encore, le couple Orchestrator / PowerShell fait des miracles ou presque. Ce processus est nécessaire aussi bien pour les Clusters Hyper-V que pour nos locataires. On a tous les mêmes problèmes. La tentation est grande de développer un processus commun mais ça irait à l’encontre d’une règle sacrée : l’indépendance entre le fournisseur de l’infrastructure et ses locataires. Chacun doit pouvoir déployer ses propres correctifs sur son périmètre. C’est encore un processus en cours de développement. Dans notre approche, on a retenu de proposer deux ensembles de Runbooks :

  • Le premier à destination de l’équipe en charge des clusters Hyper-V
  • Le second plus « générique » à destination de tous les locataires

Comme le déploiement de correctifs « out-of band » a été requis par l’hébergeur, on a donc commencé par lui. Pour faire simple, disons qu’il disposera des Runbooks suivants (actuellement en développement) :

  • Mise à disposition de correctifs au sein de son périmètre (clusters Hyper-V par exemple)
  • Installation des correctifs mis à disposition sans redémarrage
  • Installation des correctifs mis à disposition avec redémarrage
  • Vérification bonne installation des correctifs mis à disposition

C’est assez simple à réaliser, tout ce qu’on avait besoin, c’était un repository central (File Share) pour déposer les correctifs à déployer. Bref, ça ne casse pas trois pattes à un canard. Maintenant, la même chose mais pour les locataires. La ça pose plusieurs problèmes :

  • L’indépendance entre l’infrastructure et le contenu hébergé
  • Les contextes d’exécution qui sont nécessairement distincts
  • L’impossibilité de répondre à tous à tous les besoins de nos locataires
  • Offrir le choix de faire simple

Bref, toutes ces raisons qui font que c’est nécessairement une prise de tête. Voyons comment on compte traiter le sujet en reprenant les points un par un :

  • L’indépendance entre l’infrastructure et le contenu hébergé : La pas le choix, il faut trancher. On ne réutilisera pas les même Runbooks. Par contre, rien ne nous interdit d’en faire des copies et de permettre à nos locataires d’accéder à la console Orchestrator Web Access pour les exécuter. En plus, en plaçant les Runbooks dans des Folders distincts, on peut limiter les populations qui peuvent y accéder, bon point pour l’indépendance.
  • Les contextes d’exécution qui sont nécessairement distincts : Par défaut, tous les Runbooks Orchestrator utilisent le même contexte d’exécution, celui accordé au compte de service Orchestrator. Pas évident que nos locataires autorisent des accès extérieurs non maîtrisés. Par contre, il est possible d’exécuter un Runbook Orchestrator sous un autre contexte. C’est une option de l’activité « Invoke Runbook ». On a juste à référencer les contexte d’exécution sous la forme de variables. Bien entendu, pour le mot de passe, la variable ne sera pas stockée en clair.

clip_image002

Remarque : Au passage, il est aussi possible de limiter l’accès aux variables en utilisant le même mécanisme de Folders et de permissions, comme pour les Runbooks. De cette manière un locataire ne peut pas utiliser les contextes d’exécution des autres.

  • L’impossibilité de répondre à tous les besoins :  Installer des correctifs pour Hyper-V et pour SQL Server, ça n’a rien à voir. Chaque produit a ses propres spécificités. On ne veut pas développer d’usine à gaz. La logique nous a amené à proposer notre approche à nos locataires mais uniquement sous une forme « générique ». Charge à eux de l’implémenter tel que ou de l’adapter en fonction de leurs besoins.
  • Offrir le choix de faire simple : Jusque-là, on ne peut pas dire que j’ai fait simple. Certains de nos locataires pourraient penser que cela ressemble à une usine à gaz, surtout pour des périmètres applicatifs très limités en terme de nombre de machines virtuelles. Pour cette raison, notre « Machin Patching out-of band » n’est jamais imposé aux locataires, juste proposé. S’il estime qu’il est plus agile en patchant ses machines virtuelles manuellement, c’est son problème, ses SLA et son périmètre de sécurité dont il est responsable. Les Runbooks génériques ne font qu’exécuter les scripts présents au sein des machines virtuelles. On peut donc utiliser les même processus en exécutant directement les scripts PowerShell. Ça reste simple pour nos locataires.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°2 : Patch Management Microsoft

C’est la partie la plus simple. C’est pour cela qu’on commence par elle généralement. Un SCCM, un WSUS, SCVMM et la fonctionnalité Cluster Aware Update? Aller un peu de PowerShell au-dessus et c’est bon ? On va commencer par SCCM. Je suis pour et contre. Pour car il permet de facilement déployer les correctifs et de nous faire un reporting. Par contre dans un contexte Cluster, faudra l’interfacer avec le Cluster Aware Update de nos clusters. SCVMM pourrait être un bon candidat mais, il ne prend en charge que les mises à jour en relation avec Hyper-V. C’est donc trop limité.

Coté processus, j’étais encore partagé entre le Cluster Aware Updating et le Scripting PowerShell. Avec un peu de recul aujourd’hui, le Scripting PowerShell / Orchestrator me semble la solution la plus efficace. Le patch Management des clusters Hyper-V, c’est simple tant :

  • Qu’on dispose d’au moins un nœud de réserve pour réaliser
  • Qu’on est capable d’organiser la maintenance des nœuds de cluster

Organiser un redémarrage organisé d’un cluster avec SCCM, ce n’est pas si simple. Le seul moyen que j’ai trouvé, c’est de patcher plusieurs clusters en même temps, par vagues tel qu’illustré ci-dessous.

clip_image001

Cela revient donc à faire des collections organisées en « Waves » contenant uniquement des nœuds de clusters qui ne dépendent pas du même cluster. La planification avec SCCM, ce n’est pas simple. Or, les plages de maintenance dont on dispose ne sont pas extensibles. On a besoin d’orchestrer tout cela de façon plus rigoureuse avec une meilleure gestion des erreurs. Conclusion, Orchestrator + PowerShell = Rules the patch.

C’est maintenant qu’on rentre dans le dur. On a un processus déjà éprouvé. On va bâtir dessus et l’enrichir un peu avec quelques tricks. Le premier d’entre eux, c’est la mise à disposition des correctifs. Là, SCCM est un excellent candidat pour déployer les correctifs de manière ciblée. C’est tout ce que je lui demande. Pour l’installation et le redémarrage, on va reprendre la main. Ci-dessous une vue Macro de notre Runbook. On commence à le connaitre, focalisons-nous sur sa spécificité avec la gestion des erreurs. Le fait que les correctifs ne s’installent pas sur un nœud n’est pas critique. Attention, nous parlons des correctifs mensuels de sécurité, pas des correctifs « Out of band » qui eux font l’objet d’un traitement particulier. A la fin, c’est SCCM qui nous dira si tout s’est bien passé, si tous les nœuds au sein d’un cluster ont été correctement mis à jour.

clip_image002

Normalement, si on a bien industrialisé l’installation et la gestion de nos clusters Hyper-V, si une KB ne s’installe pas, le problème a de grandes chances d’être généralisé. Ce n’est pas critique pour nos Clusters Hyper-V. Par contre, il faudra investiguer sur les problèmes rencontrés afin de comprendre et éventuellement adapter le processus.

C’est notre mode de fonctionnement pour le patching de clusters Windows Server 2012 R2. Avec l’arrivée de Windows Server 2016 et son mode d’installation Nano, il faudra certainement revoir notre approche. La stratégie Long-Term Branch de Windows 10 / Windows Server 2016 devra être évaluée.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Patch Management – Réflexions – n°1 : Mise à niveau Pilotes / Logiciels bas niveau des Hyper-V

On est au niveau matériel / logiciels bas niveau. Même si Microsoft est devenu beaucoup plus souple pour les clusters et le stockage, on n’est toujours pas fan d’avoir des adaptateurs HBA ou des interfaces réseau différentes dans nos clusters (beurk). Certaines mises à jour peuvent nous permettre d’activer certaines fonctionnalités qui vont nous être très utiles, ou tout simplement améliorer la stabilité de la plateforme. Y a pas à dire toutes les fonctionnalités qui permettent de décharger les CPU des tâches réseau, c’est obligatoire dès qu’on arrive au 10Gb sur les interfaces réseau. Alors avec le Teaming de cartes 10Gb, c’est plus obligatoire mais essentiel.

Pour ce périmètre, les fournisseurs nous livrent des outils qui nous autorisent la mise à niveau de tous ces composants. C’est plutôt bien fait mais, c’est conçu pour faire de l’unitaire. Quand on a plus d’une centaine d’hôtes Hyper-V faudra passer par la case industrialisation. Les outils proposés par les fournisseurs (HP, Cisco, …) sont prévus pour gérer aussi bien la mise à niveau des Firmware que des pilotes bas niveau (interface réseau, …). Le problème, c’est que ce n’est pas nécessairement prévu pour être industrialisé. Il faut un peu de travail. Dans notre cas, nous avions besoin de pouvoir mettre à niveau des châssis entiers avec un impact minimum sur les workloads de nos locataires. Objectif transparence vis-à-vis de nos locataires.

Ci-dessous la vue macro de notre système de Patching. C’est de L’Orchestrator / PowerShell pure et dur. Rentrons un peu dans le détail. Premier point, on travaille au niveau Châssis (Nous avons des blades). Dans notre infrastructure, le châssis c’est notre domaine de panne. Chaque Châssis héberge un certain nombre de clusters.

clip_image001

Ce choix est le fruit d’une longue réflexion qui sera certainement détaillée dans un futur billet. Donc, notre Runbook va traiter tous les clusters d’un même châssis et pour en extraire la liste des tous les nœuds. C’est là qu’intervient l’activité « Parallelize ». Le propre d’Orchestrator, c’est de paralléliser. Le problème, c’est que si on traite tous les nœuds d’un cluster en même temps, ça ne va pas le faire. Pour cette raison, le code PowerShell dans cette activité va s’assurer de traiter un certain nombre de nœuds en parallèle mais pas plus. Le niveau de parallélisation va dépendue uniquement des ressources à disposition pour réaliser les Live Migration des workloads. Pour cette raison, notre règle est de toujours avoir un nœud de libre dans chaque cluster : la réserve. C’est une règle de notre Capacity Planning. Après s’il y a plus d’un nœud de disponible, on peut traiter plus de nœuds du même cluster en même temps.

L’activité « Enter-Maintenance Mode » va juste demander à SCVMM de mettre en maintenance notre nœud de cluster et automatiquement basculer les workloads vers d’autres nœuds au sein du même cluster. L’algorithme de rating de SCVMM étant plutôt bien fait, on lui fait confiance.

Maintenant, on est prêt à patcher en lançant les outils de notre fournisseur matériel préféré (HP, Dell, Cisco, …). A la sortie du paching de la Blade, on collecte les journaux. Si tout s’est bien déroulé, le nœud est réintégré au cluster, sort du mode maintenance et se retrouve éligible pour héberger de nouveau des workloads.

On apprend ici quelques règles de l’industrialisation :

  • Le 100% de réussite, ça n’existe pas. Il y a toujours des erreurs
  • On ne peut pas traiter toutes les erreurs de manière industrielle

Ce n’est pas le type de patching que l’on développe en premier car aux débuts, notre infrastructure est de taille modeste. Au fur et à mesure que l’infrastructure va croitre, on va intégrer du matériel qui utilisera des versions de firmware différentes. C’est là qu’on aura besoin d’un processus industriel pour conserver une certaine homogénéité. Après, il faut relativiser quelques points :

  • Doit-on mettre à jour régulièrement ? Personnellement, tant qu’on en a pas besoin et que la mise à niveau n’apporte pas de fonctionnalité / correction qui me soit utile à moi ou mes locataires, je peux m’en passer.
  • Doit-on patcher ou simplement réinstaller notre cluster ? Avec le Storage Migration, c’est facile de libérer tout un cluster pour permettre sa réinstallation. Avec Windows Server 2012 R2 Core et maintenant Windows Server 2016 dans son installation Nano, faut vraiment se poser cette question.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Réflexions autour du Patch Management

Ca fait quelques temps que je collabore avec Cédric BRAVO sur un projet cloud privé. Monter l’infrastructure, s’est relevé très intéressant. Ça m’a permis d’approfondir des sujets que je n’avais pas l’habitude de travailler tel que l’architecture Hyper-V et SCVMM ou les subtilités du réseau en environnement virtualisés. Maintenant le nombre de cartes réseau nécessaires dans un Châssis Blade, c’est bon pour moi, merci Cédric BRAVO.

La partie matériel est maintenant terminée, on a développé quelques services cloud assez intéressants, je ne vais pas m’étendre dessus. Ce qui nous occupe aujourd’hui, c’est l’intégration de notre « Machin » dans un système d’information complexe. Vu de l’extérieur, notre « Machin », ça ressemble un peu à ça :

clip_image001

L’étoile de la mort. Vu de l’extérieur, ça fait peur. Dans notre cas, il y a de quoi vu que c’est un assemblage technique d’une telle complexité qu’il est inenvisageable de la maitriser le bout en bout pour une seule personne. A deux, c’est déjà plus accessible, et encore que, …

A ma gauche, une infrastructure cloud privé toute neuve avec des architectes rompus à toutes les technologies embarquées (avec tout ce qu’on a dans nos têtes normal qu’on passe plus par les portes, même les doubles portes). A ma droite un système d’information existant utilisant pas forcément les mêmes briques technologies et surtout des processus d’exploitation bien en place. Douze rounds de boxe plus tard, avec de bosses et plaies, une conclusion s’impose. Le principal défi d’un cloud privé / hybride, ce n’est pas la technologie mais bien la transformation des processus opérationnels. Pour faire une analogie, c’est un peu comme faire rentrer un rond dans un carré. Un vrai problème d’ingénieur!

clip_image003

Note : Ce billet ne représente que l’état d’une réflexion qui a été menée pour développer le Patch Management pour l’infrastructure cloud privé d’un client donné. Cela ne reflète pas exactement ce qui est en place pour plusieurs raisons. Premièrement, c’est encore un sujet en cours. Deuxièmement, des concessions ont été nécessaires. Confronter la théorie aux dures réalités a été très enrichissant / épuisant. Il faut beaucoup d’imagination pour faire rentrer un rond dans un carré.

Dans cette série de billets, je vais partager quelques éléments (pas tous) sur lesquels on a passé beaucoup de temps : le Patch Management ou plus précisément les Patchs Management. Disons le tout de suite, rentrer dans les processus existant, c’est souvent « old school » avec un ensemble de processus manuels enchainés par des tickets de changements, bref tout sauf agile. Même si c’est bien industrialisé, cela ne correspond pas aux contraintes imposées par notre infrastructure. Autant vous dire que lorsqu’on a plus d’une centaine d’hôte Hyper-V à patcher ça va pas le faire, il faut un processus plus proche de l’horlogerie suisse que de tenter de mettre un rond dans un carré. Le Patch Management d’un cloud privé n’est pas une mince affaire car cela couvre plusieurs aspects :

Alors, le premier qui me dit je « prends SCCM et je clique un peu partout », il sort en passant par le mur (en béton armé) et va aller consulter ce billet : Zero-Downtime Patch & Update Orchestration on the Microsoft Cloud Platform System qui a été mon point de départ pour bien comprendre la chose. Le concept du Zero-Downtime Patch & Update Orchestration de CPS me fait rêver. Trêve de rêveries, rentrons dans le dur du sujet et voyons pourquoi ce n’est pas une sinécure.

clip_image005

Prêt pour quelques prises de tête?

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Windows Azure Pack Web Sites, problème de Front-End qui démarre pas

Ca faisait quelques temps que j’avais pas jeté un œil sur ma maquette Windows Azure Pack. En me connectant ce matin, je découvre que mon rôle Font-End est en cours d’installation. C’est ballot. Vu que sur ma maquette, les rôles de l’infrastructure Web Sites ne sont pas configurés en haute disponibilité, sans Font-End, y a plus rien de publié sur Internet. C’est un sujet que j’avais déjà rencontré par le passé. J’avais posé la question sur le forum Technet : Windows Azure Pack WebSites front-end role stuck in starting. A l’époque, j’étais encore en UR6. Ca faisait quelques temps que l’UR7 était en place, j’avais pas rencontré le problème depuis. J’avais donc clos le sujet.

clip_image001

 

Sur le rôle contrôleur, la console Windows Azure WebSites nous indique que le rôle Front-End est en cours de démarrage et que pendant celui-ci, l’installation d’un composant a échoué.

clip_image002

 

Allons faire un tour sur le serveur concerné, plus précisément dans le journal WebFarmFramework/Operational.

clip_image003

 

C’est un problème avec le Certificate Synchronization Service. Plus précisément, impossible d’installer le service. Ce qu’il faut comprendre c’est que dans une architecture WebSites, le contrôleur s’assure régulièrement que tous les composants sont à niveau. Pour cela, il les réinstalle. Ça peut paraitre étonnant mais à grande échelle (nombreux serveurs dans l’infrastructure), c’est un choix d’architecture gagnant. On ne se pose pas la question de savoir ce qui manque, en réinstallant tout, on est assuré que tous les instances du même rôle sont bien installés avec les mêmes versions des composants.

clip_image004

 

Après quelques heures de recherche, je n’ai pas trouvé la cause initiale du problème. En attendant, j’ai quand même trouvé :

  • Une correction
  • Deux contournements

La correction consiste à désinstaller le rôle Font-End puis de demander sa réinstallation sur le même serveur. Pour une raison que j’ignore encore, le service « Certificate Synchronization Service » se réinstalle correctement. Par contre, de ce que j’ai pu observer, cela ne fonctionne pas à tous les coups.

Le premier contournement consiste à disposer d’au moins deux instances pour le rôle Font-End. Ça ne corrige pas le problème mais si au moins une des deux instances est opérationnelle, le service est opérationnel du point de vue des locataires. Cela donne le temps de tenter la correction.

Le second contournement est issu de quelques expériences avec ma plateforme. Après plusieurs redémarrages de l’infrastructure WebSites, j’ai remarqué que le problème ne semblait pas survenir lorsqu’on s’assure que le rôle Font-end démarre en dernier.

Au final, toutes les instances de mes rôles de mon infrastructure WebSites sont de nouveau opérationnels.

clip_image005

­

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Architecture Windows Azure Pack WebSites – Etape n°4 : Mise en place du rôle Publisher

La liste des rôles a été longue, il n’en reste plus qu’un. Ça veut pas dire pour autant que c’est déjà la fin de la séance de torture, bien au contraire. Allons y. Last but not least, le rôle Publisher. Tout comme pour le rôle Front-end, il est exposé sur Internet, à ce titre, il méritait une zone réseau dédiée sur ma maquette. La bonne pratique est bien entendu de ne pas exposer ce rôle directement sur Internet mais d’utiliser des solutions de type reverse-Proxy pour l’exposer.

clip_image001

 

Pour rappel, c’est grâce à ce rôle que nos futurs locataires vont pouvoir venir déposer le futur contenu de leurs sites web. D’un point de vue sécurité, le contenu de tous les sites Web de nos locataires ne sont pas directement exposés sur Internet. Avant de rentrer dans la configuration du rôle, quelques subtilités. Mes instances du rôle Web-Publisher seront accessible depuis Internet via le nom webpublisher.windowsazurepack.fr mais aussi via les alias (CNAME) suivants :

clip_image002

 

Note : Depuis L’UR7, L’URL de publication de WebDeploy a été modifiée poursite.scm.domain.com.  J’ai donc ajouté l’URL supplémentaire mais pas supprimé l’ancienne.

 

Donc au final, mes instances du rôle Web-Publisher seront accessibles sous trois noms :

C’est nécessaire pour supporter les multiples protocoles d’accès. Vu que ce rôle est visible depuis Internet, il est logique qu’on sécurise les communications. Nous avons donc besoin d’un certificat qui réponde au nom Webpublisher.Windowsazurepack.fr mais aussi aux deux autres noms. Le certificat a été délivré par une autorité de certification publique. Pour vérification, l’attribut DNSNameList contient bien les noms indiqués :

Get-ChildItem Cert:\localMachine\My | Where {$_.Subjectname -eq « cn=webpublisher.windowsazurepack.fr »} | Select Subject, DNSNameList

clip_image003

 

Note : Attention à bien avoir demandé un certificat pour lequel nous pourrons bien exporter la clé privée. Le certificat devant être mis en place sur toutes les instances du rôle Web-Publisher ainsi que mis à disposition de Windows Azure Pack.

 

Nous en avons fini avec les prérequis, passons à la configuration de notre serveur. Il y a un peu moins de travail que pour les autres :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • UAC : Désactivé
  • Compte WAP\FT-WAP-WEB01 membre du groupe local administrators
  • Le certificat SAN importé dans le magasin personnel de l’ordinateur
  • Quelques règles de pare-feu entrantes :
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole Web Farm Framework Agent (TCP 8173)
    • Protocole FTP
    • Protocole WebDeploy TCP 443/TCP 8172

Comme pour les autres rôles, nous allons réaliser le déploiement depuis la console Windows Azure pack Web Sites et demander le déploiement de notre première instance du rôle Publisher.

clip_image004

 

Le processus commence par installer l’ensemble des composants nécessaires à son bon fonctionnement du rôle Web-Publisher. Comme pour les rôles précédents, la liste des composants à installer est mise à disposition par le contrôleur ainsi que le contenu.

clip_image005

 

Note : Le processus d’installation va automatiquement redémarrer le serveur pour finaliser l’installation.

On a achevé la mise en place de tous les rôles de l’infrastructure Web Sites, on peut donc passer à l’intégration avec Windows Azure Pack?

clip_image006

 

La séance est presque terminée. C’était le dernier rôle. Normalement, tous devrait répondre présent.

Get-WebSitesServer | Select Name, Role, Status, PlateformVersion | Format-Table -AutoSize

clip_image007

 

On peut facilement s’en assurer avec le Best Practice Analyzer dédié à l’architecture Web Sites. Commencez par installer le Microsoft Baseline Configuration Analyzer 2.0 sur le contrôleur de l’architecture Web Sites ainsi que le package correspondant à l’architecture Web Sites. Dans l’illustration ci-dessous, on constate deux points :

  • Je n’ai qu’une seule instance du rôle contrôleur. C’est effectivement critique car sans elle, y a plus de pilote dans l’avion. C’est assez simple d’ajouter une instance secondaire pour ce rôles.
  • Je n’ai pas nécessairement de multiples instances pour les autres rôles. j’ai donc des domaines de panne dans mon infrastructure.

clip_image008

 

Nous en avons fini avec la mise en place de l’infrastructure Web Sites. Il est temps de la connecter à notre infrastructure Windows Azure Pack. Ce sera pour le prochain billet.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)