Archives de catégorie : Cloud

Azure Scheduled Maintenance

Azure Scheduled Maintenance est une nouvelle approche de la gestion de la maintenance des infrastructures Azure. Celle-ci a été introduite progressivement mais ce n’est qu’en cette fin d’année 2017 que l’on peut constater l’arrivée de cette fonctionnalité dans les régions North Europe & West Europe.

Pour rappel, la fonctionnalité doit permettre aux clients Azure :

  • D’être notifié des périodes de maintenances pour le service Azure Virtual machines.
  • De pouvoir influer sur les périodes de maintenance proposées en les anticipant

 

Dans le portail Azure, cela se présente comme illustré ci-dessous avec la mention « Scheduled maintenance will start soon ».

clip_image002

 

Si on regarde plus en détail, nous n’avons que peu d’information. C’est normal car pour cette machine virtuelle, Azure ne nous annonce que la période de maintenance planifiée, pas encore la période de « pré-maintenance ».

clip_image004

 

Donc à ce stade, cliquer sur le bouton Redeploy ne permettra pas d’anticiper la maintenance. Par contre, quand on regarde une machine virtuelle dont la planification de maintenance est un peu plus avancée, l’interface est un peu différente :

clip_image006

 

Nous sommes informés que la future possibilité d’anticiper la phase de maintenance. C’est important car une fois entrée en phase de Scheduled Maintenance, le processus est 100% automatisé, nous ne pourrons plus intervenir.

clip_image008

 

Lorsque la fenêtre de pré-maintenance sera ouverte, nous recevons un mail comme celui-ci, tout du moins, un par souscription Azure dans laquelle nous avons des machines virtuelles.

clip_image009

 

A noter que la même information est disponible maintenant dans le Azure Service Health dans la rubrique « Planned Maintenance ».

clip_image011

 

Lorsqu’on regarde l’onglet « Affected ressources », on a une vue synthétique. Dans l’illustration ci-dessous, j’ai deux machines virtuelles pour lesquelles je peux dès maintenant anticiper la période de maintenance proposée par Azure

clip_image013

 

Maintenant qu’on est dans la fenêtre de pré-maintenance, on peut lancer l’opération avec le bouton « Start Maintenance ».

clip_image015

 

L’opération va consister tout simplement en un « Redeploy ». La machine virtuelle va donc s’arrêter, quitter l’hôte Hyper-V et être redéployé sur un autre hôte Hyper-V qui lui a déjà été mis à niveau par Microsoft.

clip_image016

 

Avantage d’anticiper la maintenance, c’est nous qui contrôlons la durée de l’indisponibilité. Ce n’est plus le cas au terme de la période de pré-maintenance.

Pour avoir une vue d’ensemble, le plus simple reste de personnaliser la vue « Virtual machines » pour inclure les colonnes suivantes :

  • Maintenance – Auto-Scheduled Window
  • Maintenance – Proactive Windows

clip_image018

 

Après, on peut aussi jouer en PowerShell :

get-azurermvm -status | select Name, MaintenanceRedeployStatus -ExpandProperty MaintenanceRedeployStatus | select Name, IsCustomerInitiatedMaintenanceAllowed, PreMaintenanceWindowStartTime, PreMaintenanceWindowEndTime, MaintenanceWindowStartTime, MaintenanceWindowEndTime | Out-GridView

clip_image020

 

Les informations sont identiques. Ce qui est bien, c’est qu’on n’est pas obligé d’interroger chaque machine virtuelle pour collecter l’information.

clip_image022

Bonus

Le Bonus, c’est d’être informé de ces opérations dès que possible. Comme dans Azure, il y a une fonctionnalité pour tout, en creusant dans Azure Service Health, vous découvrirez la possibilité de créer une alerte sur ce sujet. La seule critique, c’est que l’alerte est liée à un groupe de ressources. Il faudra donc autant d’alertes que de groupes de ressources contenant des machines virtuelles.

clip_image024

 

Pour conclure, un peu de lecture sur le sujet :

 

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

Valet Key avec Azure Function App

Dans le billet « Azure Functions – Introduction au ServerLess en PowerShell« , on a posé les bases. Cette fois, passons à un usage concret avec le pattern Cloud Valet Key. C’est un des principes fondamentaux dans le cloud.

Introduction

Lorsqu’on regarde le fonctionnement des services de stockage Azure, on constate que la finesse / granularité d’affectation des permissions est binaire. Pour un Storage Account, on dispose de deux clés : Primaire et secondaire (les Access Keys). Le problème, c’est le niveau de privilège que ces clés octroient :

clip_image001

 

Heureusement, toute plateforme cloud qui se respecte est capable de nous proposer la capacité à générer des permissions beaucoup plus fines. Faut juste orchestrer la chose :

  • Etape n°1 : une application cliente soumets une demande d’accès auprès d’un maître des clés (notre Valet Key)
  • Etape n°2 : Le valet Key valide l’identité de l’appelant (authentification) et détermine si celui-ci est éligible à une telle demande (autorisation)
  • Etape n°3 : Le valet Key génère une clé d’accès pour le demandeur en appliquant des contraintes (niveau de permission, limitation dans le temps, limitation sur la source IP, …)
  • Etape n°4 : La clé générée est utilisée par le demandeur pour accéder à sa ressource

 

clip_image002

 

Voilà pour les fondamentaux du pattern. Au passage, je vous conseille la lecture des autres Cloud Design Patterns. Pour ce billet, nous allons mettre en place ce mécanisme pour générer des clés d’accès à un Storage Account, plus particulièrement un ensemble de tables.

Shared Access Signature versus Stored Access Policy

Premier sujet, comment générer des clés d’accès. Voilà un sujet que j’avais déjà abordé dans le billet « Shared Access Signature with stored Access Policy« . Avec le SAS ou les Stored Access Policies, on est capable d’assigner les permissions fines avec même la possibilité d’imposer des restrictions (restriction dans le temps, des services de stockage sollicités, voire même du contenu accédé). Bref, on a le choix. Après, il faut retenir quelques points :

  • On ne peut pas révoquer une Shared Access Signature (SAS), il faut renouveler les clés primaires & secondaires, donc révoquer toutes les SAS simultanément
  • Révoquer une Stored Access Policy implique de révoquer toutes les clés SAS liées à une policy.
  • Un Storage Account ne peut avoir que cinq Stored Access Policies
  • Shared Access Signature et Shared Access Policy peuvent s’appliquer par type d’usage (Table, Blog, Queue, File, …)
  • Une Shared Access Signature peut s’appliquer à un ensemble (toutes les tables) alors qu’une Stored Access Policy ne s’appliquera qu’à une seule table

 

Pour ce billet, nous allons mettre en place notre Key Valet en utilisant une Shared Access Signature. C’est un choix de ma part car j’ai besoin de générer des clés pour toutes les tables contenues dans un Storage Account et non pas pour chaque table. C’est ce que nous rappelle le portail.

clip_image003

 

Choix entre Consumption Plan versus App Service Plan

C’est un des avantages des Function App, la capacité à provisionner automatiquement l’infrastructure à la demande. Sur le papier, c’est bien. En plus cela rend notre API gratuite. Le défaut, c’est que si c’est gratuit, c’est tout sauf performant. Pour rappel un App service Plan Free repose sur des cœurs CPU non dédiés et avec uniquement 1Go de mémoire vive. Pour ces raisons, je provisionne notre Function App en utilisant un App Service Plan existant avec un SKU Standard 1, le minimum vital à mon sens pour partir en production (et encore).

clip_image004

 

Au passage, je vais réutiliser le Storage Account créé pour l’occasion pour notre Valet Key.

 

Besoin d’une identité ?

Dans mon billet « Azure Functions – Introduction au ServerLess en PowerShell » mon Azure Function j’avais précisé la démarche pour permettre à mon Azure Function de disposer d’une identité lui permettant de manipuler des ressources dans Azure. Depuis ce billet, la notion de Managed Identity Service est apparue. Cela simplifie grandement la mise en œuvre.

Question : Ais-je besoin d’une identité (et donc d’un Service Principal) pour accéder à Azure ? Beaucoup vont répondre oui en pensant qu’il faut nécessairement s’authentifier auprès d’Azure pour ensuite demander l’accès aux clés de stockage avec la commande PowerShell Get-AzureRmStorageAccountKey. D’un point de vue technique, c’est vrai, on peut extraire l’information mais combien cela coute-t-il en termes de performance ? Dans le contexte de notre démonstration sur le Key Valet, nous allons volontairement nous en passer, c’est un sujet sur lequel nous reviendrons ultérieurement.

Choix du langage ?

On ne va pas faire de mystère, je vais pas sortir un C# du chapeau (je laisse cela aux experts). Le but de ce billet, c’est de démontrer qu’on peut écrire des API en PowerShell, dont acte, …

clip_image005

 

A ce jour, le support de PowerShell est expérimental (je confirme). Au moment de l’écriture de ce billet, c’est la version 4.0 qui est proposée dans Function App. C’est un point à prendre en considération dans le développement de vos scripts (amère expérience, …). A ce jour seul trois types de déclencheurs sont disponibles pour Azure Function en PowerShell :

  • Le déclencheur HTTP
  • Le déclencheur sur planification
  • Le déclencheur sur injection d’un message dans une Azure Queue d’un Storage Account

 

Le but de ce billet étant d’écrire une API en PowerShell, c’est donc le choix HTTPTrigger qui a été retenu.

Authentification auprès du Key Valet

Mon API sera accessible publiquement via une URL. Si tout le monde peut demander des clés d’accès pour mes Azure Table, ça pose un sérieux problème. C’est pour cela que Function App propose trois niveaux d’authentification :

  • Function : Secret d’accès propre à chaque Azure Function
  • Anonymous
  • Admin : Secret d’accès partagé par toutes les Azure Function hébergées dans une même instance Function App.

clip_image006

 

Dans mon contexte, j’ai retenu le niveau « Function ». Au final, L’URL de mon API est la suivante. Après, on peut aussi exploiter les fonctionnalités natives d’Azure Web App (Azure Active Directory, Google, Microsoft Live, …) mais aussi Azure API Management Gateway.

clip_image007

 

Pour ceux qui ont suivi, notre API est prête pour son premier appel.

 

Premier appel

Avec notre choix HttpTrigger, nous avons automatiquement un premier exemple de code PowerShell pour notre API. Cela se passe de commentaire, c’est un Hello World.

clip_image008

 

Ce qui est bien, c’est que cela permet de poser les bases de l’appel à notre API. API développée en PowerShell, appel en PowerShell, logique :

$HttpRequestUrl= « « 

$parameters = @{name=’SimplebyDesign’}

$json = $parameters |ConvertTo-Json

Invoke-RestMethod -Uri $HttpRequestUrl -Method POST -ContentType ‘application/json’ -Body $json

clip_image009

 

Passons au PowerShell qui tache

En fait, il ne tache pas tant que cela. On commence par récupérer deux variables dans les Application Settings. Celles-ci nous permettent de construire un contexte d’accès à notre Storage Account (commande New-AzureStorageContext). De là, il n’y a plus qu’à générer une clé SAS (commande New-AzureStorageAccountSASToken). Dans le contexte de mon besoin, mon Key valet doit me générer des clés permettant :

  • L’accès à un seul service dans le Storage Account : Table
  • La permission obtenue doit être limitée au stricte nécessaire pour lire les données dans les Azure Table
  • La permission doit être limitée dans le temps
  • L’utilisation du protocole HTTPS doit être obligatoire

 

$StorageAccountName = $env:StorageAccountName

$key = $env:StorageKey

$startdate = Get-date

Try

{

$StorageContext = New-AzureStorageContext -StorageAccountName $StorageAccountName -StorageAccountKey $key

[DateTime]$ExpirityTime = (Get-Date).AddMinutes(15)

$sastoken = New-AzureStorageAccountSASToken -Service Table -ResourceType Service,Container,Object -Permission « rl » -Context $StorageContext -Protocol HttpsOnly -ExpiryTime $ExpirityTime

[System.IO.File]::WriteAllText($res,$sastoken)

« Generated $([math]::round((New-TimeSpan -Start $startdate -End (get-date)).TotalSeconds,2)) TotalSeconds »

}

Catch

{

Out-File -Encoding Ascii -FilePath $res -inputObject « INTERNALERROR »

}

 

Petit point d’attention : Pour ceux qui se posent la question pourquoi c’est si compliqué pour retourner le résultat avec la commande : « [System.IO.File]::WriteAllText($res,$sastoken) « . Un Simple Out-File fait la même chose. Oui et non. En PowerShell 4.0 a cette fâcheuse manie d’ajouter un retour à la ligne, ce qui fausse le résultat retourné à l’appelant. Dans PowerShell 5.0, on a bien un paramètre « -NoNewline ». Problème, c’est du PowerShell 4.0

clip_image010

 

Le goudron et les plumes ?

Mon API est prête. Elle a même déjà délivré sa première clé. Certains ont déjà compris que l’Access Key à mon Storage Account est référencé en clair dans les Applications settings et sont déjà parti chercher le goudron et les plumes.

clip_image011

 

Oui, il aurait été possible de ne pas coder l’information en clair dans les Application Settings et d’utiliser un Key Vault. Avec un Service Principal on aurait pu s’authentifier auprès d’Azure et accéder aux Access Keys. C’est ce dernier point qui m’a posé problème. Lorsque j’ai mis en place mon API pour une application que je développe, j’ai été surpris par le temps de réponse moyen : 20 secondes en pleine charge. WTF !!!!!!!!!!!

Heureusement, pour comprendre, j’avais réalisé l’intégration de mon Azure Function App avec Application Insights histoire d’avoir de la télémétrie : Data Driven Decision. Aussi étrange que cela puisse paraître, lorsqu’on consomme directement l’Access Key au lieu de l’extraire, on obtient une performance bien différente comme illustré ci-dessous :

clip_image012

 

Sur la même ligne temporelle on peut constater le niveau de réponse moyen avant et après optimisation. Sur un appel individuel on passe de quatre secondes à une seconde. Mon application est fortement consommatrice de l’API. Il y a donc beaucoup d’accès concurrentiels et mon choix de n’avoir qu’une seule instance de l’App Service Plan en SKU S1 n’aide pas à la performance. Pourtant, une fois la mise à niveau réalisée, la performance de l’API est restée constante : Autour d’une seconde.

Une amélioration serait d’utiliser Managed Identity Service pour ensuite accéder à un Key Vault. Je rentre pas dans le détail, d’autres ont exploré le sujet : « Enabling and using Managed Service Identity to access an Azure Key Vault with Azure PowerShell Functions« . A première vue, cela ne dégraderait pas trop les performances.

Consommons notre Valet Key

Nous avons notre Valet Key, ne nous manque plus qu’une application qui le consomme. Je suis allé au plus simple. L’appel à l’API n’a pas changé. La clé SAS nous est retournée, pour être consommée afin de générer un contexte d’accès au stockage. De là, il n’y a plus qu’à accéder à une table dans le Storage Account :

$HttpRequestUrl= « « 

$token = Invoke-RestMethod -Uri $HttpRequestUrl -Method POST -ContentType ‘application/json’

$newcontext = New-AzureStorageContext -StorageAccountName « tpserverlessstorage » -SasToken $token

Get-AzureStorageTable -Name TestTable -Context $newcontext

clip_image013

 

Voilà un exemple concret d’utilisation des Azure Function App. Après, on peut grandement l’améliorer (méthode d’authentification, différenciation des niveaux d’accès, exposition avec Azure API Management Gateway, utilisation du Key Vault, …)

 

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

Le Cloud est un perpétuel recommencement

Le Cloud, c’est une infrastructure et des services en perpétuelle évolution. Dans Azure, historiquement dans les machines virtuelles, on avait la Série A. Avec le temps Microsoft a étoffé son service IaaS en proposant de nouvelles configurations. Avec l’arrivée de la série D, on avait 60% de performances en plus. A cette époque, l’étude comparative de Cloud Spector démontrait l’intérêt de réaliser des migrations technique (qui en plus apportaient un gain financier). Avec DV2, la promesse de Microsoft est de 35% de performance en plus pour un prix inférieur de 5%. Cloud Spector a mis à jour son étude, comparant la série DV1 avec la nouvelle offre DV2.

Bref, ce que nous avons mis en production devra nécessairement être réévalué. Certes, on bénéficie de la baisse continue des prix. A chaque fois qu’un des grands acteurs du Cloud baisse les prix, les autres s’alignent ou surenchérissent. C’est en réévaluant nos besoins par rapport aux nouvelles capacités de la plateforme qu’on peut réaliser les meilleures optimisations techniques et financières. Avec la Série Av2, l’histoire recommence.

Prochainement, c’est notre approche de la haute disponibilité que nous allons devoir remettre en cause. Historiquement, le seul moyen que nous avions de garantir la disponibilité d’une machine virtuelle (et donc un SLA de la part de Microsoft) passait par les Availability Set qui permettait de répartir deux ou plusieurs instances de notre machine virtuelle dans des domaines de panne et des domaines de maintenance distincts. Grand merci à l’article de Samir Farhat sur le sujet. Avec cette nouvelle fonctionnalité, la haute disponibilité dans Azure deviendra beaucoup plus abordable. Certes, je ne pense pas que cela concerne tous les workloads et qu’il faudra par exemple continuer à utiliser des Availability Sets pour un cluster SQL en Always-On. Comme l’indique Samir Farhat, beaucoup de clients ont refusé de migrer certains workloads à cause des contraintes financières de la haute disponibilité dans Azure.

Plus généralement, dans le Cloud, la notion d’état stable n’est qu’une notion temporaire entre deux cycles d’optimisations techniques & financières.

clip_image001

Notre problème, ce sera de savoir comment évaluer les opportunités techniques et financières qui se présentent à nous. Si on regarde une plateforme comme Microsoft Azure, en 2015, c’est plus de 500 nouveaux services ou évolutions de services mis à disposition des clients. Evaluer toutes les possibilités d’évolution qui se présentent à nous n’a pas de sens :

  • Une évaluation individuelle pour chaque application ne fera que complexifier chaque application
  • Une évaluation individuelle augmentera le nombre de service distincts à gérer et ne va pas aller dans le sens de la gouvernance

Nous n’allons donc pas évaluer toutes les possibilités mais retenir un ensemble de fonctionnalités qui peuvent être généralisées pour un ensemble de workloads. Plus nos workloads pourront partager de services et fonctionnalités en commun, il deviendra simple de profiter des effets d’échelle aussi bien du point de vue de la performance que des prix. Conclusion, le Cloud, ce n’est pas qu’une transformation technique, c’est aussi une transformation de la manière dont nous allons organiser ceux-ci ainsi que l’organisation pour les gérer. C’est une nouvelle approche de l’infogérance qui se dessine.

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

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)