Explication des soucis Azure Storage du 29/12/2012 (South US Region)

Le 29 décembre 2012, Microsoft à eu un soucis avec le service de stockage d’Azure. Contrairement au bug du 29 février, ce soucis a été relativement limité et concernait uniquement une ‘petite’ partie d’Azure Storage de la région “South US”.

Comme lors du précédent incident significatif (voir mon post “Azure – le bug du 29 février expliqué dans le détail !”) Microsoft a choisi de communiquer sur le problème, d’expliquer le soucis, la cause et le remède appliqué.

L’article en détail est ici : http://blogs.msdn.com/b/windowsazure/archive/2013/01/16/details-of-the-december-28th-2012-windows-azure-storage-disruption-in-us-south.aspx

Pour ceux qui ne veulent que le résumé, les causes sont :

  1. Une erreur humaine qui a désactivé des mécanismes de protection lors d’une modification de la configuration d’un nœud de stockage.
  2. Le système de monitoring avait un bug qui a empêcher le déclenchement des alertes et l’escalade .
  3. Une migration du nœud de stockage concerné vers un nouveau nœud à été déclenché le 28/12 à 7:09PST. L’erreur de configuration a permit un formatage de certains disques lors de la création du nouveau nœud alors qu’ils auraient du être préservé.

Pour le détail des procédures de récupération, je vous conseille vivement de lire le billet d’origine qui est très détaillé.

Catégories:Windows Azure Tags:, ,

Team Foundation Service (ex tfspreview.com) et l’erreur TF30063

Je viens de me frotter à l’erreur TF30063 (“you are not authorized to access https://xxxx.visualstudio.com/defaultcollection.") remonté par Visual Studio (2010 et 2012) lorsque je tentai de me connecter à un TeamProject présent dans mon server TFS hosté dans azure (visualstudio.com).

Ce problème est apparu assez subitement et simultanément sur mon poste W8/VS2012 et W7/VS2010. Je n’ai pas identifié l’origine exacte du soucis.

Quoi qu’il en soit la cause du refus d’authentification à l’air lié à la présence d’un cookie d’authentification LiveID qui reste dans le cache.

La suppression des cookies au niveau d’Internet Explorer n’a rien donné, l’erreur se produisait toujours.  La déconnexion explicite de mon LiveID à partir de mon navigateur n’a pas mieux marché.

En fait, il faut bien se déconnecter de LiveId … mais à partir d’un navigateur qui tourne DANS VISUAL STUDIO !!! La marche à suivre est donc la suivante :

  • lancez votre VisualStudio (2010 ou 2012)
  • ouvrez un navigateur via le menu “View / Other window / Web Browser”
  • naviguez sur live.com et deconnectez vous.
  • naviguez sur VOTRESERVEUR.visualstudio.com (si par hasard vous êtes connecté automatiquement déconnectez vous explicitement de votre server TFS en cliquant sur votre login en haute à droit de la page web, puis “Sign out”).
  • reconnectez vous avec votre LiveID qui dispose des droits dans le serveur TFS.

Voilà, ca vous évitera de perdre de précieuses minutes de codage pour une simple histoire de gâteau. A la place, prenez une pause café … avec un cookie c’est délicieux.

Catégories:Visual Studio Tags:, ,

2013 …

Comme il se doit, c’est très sincèrement que je vous souhaite une très bonne et heureuse année 2013. Qu’elle soit porteuse de réussites personnelles et professionnelles.

Nicolas.

Catégories:Non classé

TrainEnPoche pour Windows 8 et Windows RT

QuidMind vient de publier la version Windows 8 de Train En Poche.

Nativement conçu pour le nouvel OS de Microsoft, Train En Poche est compatible Windows 8 (sur processeur Intel) et Windows RT (sur processeur ARM).

Donc , n’hésitez pas ! Que vous soyez possesseur d’une tablette Surface, d’un Netbook, d’un laptop ou d’une bête de guerre équipé de Windows 8 ….

Le téléchargement de Train en Poche est par là : http://apps.microsoft.com/windows/fr-FR/app/train-en-poche/193f5488-bcfb-401d-8bf9-108b93a47d6c

La version pour Windows Phone 7 est toujours disponible ici : http://www.windowsphone.com/fr-fr/store/app/train-en-poche/80111080-06ac-e011-a53c-78e7d1fa76f8

Windows 8 Release Preview disponible pour les abonnés MSDN !

Tout est dans le titre. Windows 8 Release Preview est disponible pour les abonnés MSDN.

Steven Sinosfky vient de l’annonce sur le blog Windows 8 : http://blogs.msdn.com/b/b8/archive/2012/05/31/delivering-the-windows-8-release-preview.aspx

A vos téléchargements.

Catégories:Non classé, Windows 8

La valse des espaces de stockage en ligne … lisez les petites lignes !

Depuis quelques semaines, les annonces se multiplient concernant les espaces de stockage en ligne. DropBox (le buzzer), SkyDrive (l’ancien) et le nouveau Google Drive.

Tout cela est beau, gratuit, simple à utiliser … mais qu’en ai t-il des règles de propriété des éléments( fichiers, photos, …) que vous stocker dans ces espaces ???

Rien n’est caché, tout est dans les CGU ou CGV … que quasiment personne ne lis.

Alors que je m’apprêtait à faire une synthèse de ces points (en complément d’un ancien travail d’analyse sur les CGU/CGV des hébergeurs de photos en ligne), CNET m’a devancé Sourire. Donc je vous livre ici une synthèse française et vous invite à lire le billet d’origine  http://news.cnet.com/8301-1023_3-57420551-93/who-owns-your-files-on-google-drive/ .

 

Il apparait donc que Dropbox & Skydrive protège votre propriété intellectuelle SANS s’octroyer de licence d’exploitation de vos documents.

  • Pour DropBox, la règle est simple : “Vous conservez l’entière propriété de vos effets. Nous ne revendiquons aucun droit de propriété de vos effets. Les présentes Conditions ne nous accordent aucun droit sur vos effets ou votre propriété intellectuelle”.

  • Pour Microsoft SkyDrive la règle est tout aussi simple : “nous ne revendiquons pas la propriété des documents que vous publiez ou fournissez sur le service. Vous restez seul propriétaire du contenu.”. Les attributions de licences sont lié aux droits d’accès que vous mettez sur vos documents (par défaut privé) : Cela équivaut à accorder une licence à tous ceux qui peuvent lire le document (mais vous êtes maitre de la situation).

 

  •  Google vous impose d’accorder  “une licence, dans le monde entier, d’utilisation, d’hébergement, de stockage, de reproduction, de modification, de création d’œuvres dérivées (des traductions, des adaptations ou d’autres modifications destinées à améliorer le fonctionnement de vos contenus par le biais de nos Services), de communication, de publication, de représentation publique, d’affichage ou de distribution public desdits contenus”.

Donc pour faire simple, le fait d’entreposer des documents sur les services Google équivaut à les autoriser à en faire quasiment ce qu’ils veulent et ce, même “si vous cessez d’utiliser [leur] Services ” quelque soit le service Google utilisé (Google Drive, Picasa, G+,…).

 

Conclusion : avant de poser des documents confidentiels, d’entreprises, des photos privées … LISEZ LES PETITES LIGNES et choisissez en connaissance de cause.

 

Personnellement, je ne met rien chez Google, et en plus le nouveau logiciel SkyDrive pour Windows est vraiment excellent Clignement d'œil

 

Source en français :

Catégories:Security Tags:, , , , ,

Azure : le bug du 29 février expliqué dans le détail !

L’équipe Windows Azure à publier un excellent article technique expliquant l’origine du bug du 29 février qui a perturbé le fonctionnement d’Azure pendant plus de 12 heures. Azure Storage et SQL Azure n’ont pas été impacté par ce soucis. ACS et le Service Bus ont été affecté indirectement par cet évènement.

http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx

Voici un résumé simplifié de l’explication technique fournit dans le billet :

L’origine du soucis est lié à un problème de date d’expiration de certificats utilisé pour sécuriser les échanges de données sensibles entre les machines virtuelles (VM) exécutant vos applications et le système de gestion des ressources des datacenter : les Fabric Controler (FC).

  • Le certificat est généré/regénérer lors du démarrage des VM (après une mise à jour, un changement de nombre d’instance, un re-création d’image, … ) ou dans certains cas particuliers), afin de permettre le dialoguer enter les logiciels agents du FC tournant dans la VM et le FC lui même. Ce certificat à une durée de vie de 1 an. La génération de la date de fin se fait a partir de la date du jour (à 00h00) et à laquelle on ajoute 1 à l’année en cours. ==> Les tentatives de génération des certificats ayant lieu le 29/02/2012 UST demandaient donc une date d’expiration le ‘29/02/2013 00:00’ ce qui est une date invalide –> La génération du certificat échouait. Ce bug à commencé à se produit le 28 février à 16h00 PST (29 février 00h00 UST).
  • Si, au bout de 25min, l’ agent du FC n’a pas reçut le certificat d’une VM il la considère comme problématique et déclenche la création d’une nouvelle VM de remplacement. Le phénomène se reproduit de nouveau car la création de certificat échoue à chaque fois.
  • Au bout de 3 tentatives d’affilée de re-création de VM qui échoue, le FC considère le serveur physique hébergeant les VM comme problématique et retire ce serveur du pool de serveurs disponibles en le marquant comme nécessitant une intervention humaine de maintenance (HI : Human Investigate).
  • Le FC va alors affecter d’autres serveurs disponibles dans le cluster (un ensemble d’environ 1000 machines) pour re-créer de nouvelles VM … sur lesquels le bug du certificat va se reproduire.
  • Au fur et à mesure, de plus en plus de serveurs physiques sont marqués “HI”. Le FC déclenche une sécurité qui bloque ces automatismes quand la quantité de serveur marqué HI atteint un seuil anormal. Cette sécurité à empêcher la mise hors service de l’ensemble des serveurs des cluster mais à aussi stoppé les processus de mise à jours en cours; ce qui eu pour conséquence de laisser parfois des applications dans des états instables ou dégradées.
  • Le déclenchement de cette sécurité par le FC a entrainé l’alerte des opérateurs de surveillance des DataCenter pour signifier un problème insoluble par les automatismes et nécessitant une intervention humaine urgente (17h15 PST).
  • En parallèle, une mise à jour des logiciels internes du datacenter (FC et ses logiciels agents) se déroulait. Cette mise à jour déclenchait la régénération des certificats d’échanges entre les VM et les agents du FC, ce qui à eu pour conséquence de déclencher le bug dans des VM qui fonctionnait correctement, accentuant ainsi l’effet du bug en forçant la réinitialisation de VM saine. Ceci explique pourquoi des clients n’ayant demandé aucune mise à jour de leurs applications durant cette période ce sont quand même vu impacté par le bug. Les cluster non concerné par cette mise à jour interne ont été moins impacté par le bug. L’augmentation anormale du nombre de cluster en cours de mise à jour avec un seuil HI atteint a entrainé l’alerte des équipes de développement du FC et des ses agents (18h38 PST).
  • A ce moment là pour éviter une aggravation de la situation par des clients voulant re-déployer des mise à jour ou forcer des redémarrages pour résoudre les soucis constaté, le service de Management (utilisé par le portail d’administration) a été arrêté pour maintenir un statu-quo (18h55 PST). Il s’agit de la première fois que ce seuil d’intervention à été atteint.
  • Les équipes de développement ont codé un correctif, qui fut testé dans un premier cluster de test à 01h50 PST le 29/02, ainsi que sur un cluster de production d’application interne à Microsoft.
  • Après une validation sur un cluster de production, la diffusion générale du correctif à été lancé sur tous les clusters problématiques. A 5h23 PST, Microsoft annonce la restauration du service de management.

 

  • 7 clusters venaient juste de commencer leur mise à jour (soit environ 7000 serveurs physiques) lors du déclenchement du bug, ce qui a laissé les couches logicielles Azure des VM et des serveurs dans des niveaux versions différentes et incompatibles entre elles. Ces 7 clusters ont donc été traités différemment : retour vers la version précédentes MAIS avec le bug du 29/02 corrigé. Habituellement cette procédure de mise à jour est progressive et prend plusieurs heures pour respecter les disponibilités des applications, mais dans ce cas exceptionnel, une mise à mise à jour simultanée de tous les serveurs a été forcées.
  • Malheureusement une mauvaise version de couche réseau a été déployé ce qui a empêché le réseau virtuel reliant les VM de se configurer, privant ainsi toutes les VM concernées de connectivité (02h47 PST). Etant donné que les processeurs utilisé dans Azure ont 8 cœurs : potentiellement jusqu’à 56000 VM de type Small ont pu être impacté par ce 2e soucis (8 cœurs * 7 clusters * 1000 serveurs).
  • Ces 7 clusters hébergeait majoritairement les fonctionnalités d’Access Control et du Service Bus, ce qui explique pourquoi ces fonctionnalités ont aussi été impacté par le bug ‘grâce’ à un effet cascade.
  • Un correctif du correctif a été déployés sur ces 7 clusters, et à 08h00 PST la quasi totalité des serveurs était de nouveau fonctionnel.
  • Un certain nombre de serveurs de ces 7 cluster étaient dans des états instables et/ou corrompus et ont du être restaurés manuellement.
  • le 1er Mars à 02h15 PST l’ensemble des services était de nouveaux fonctionnels

Le post de blog d’origine décrit ensuite les conséquences de cet incident, et le plan d’actions que l’équipe Azure va mettre en place.

Suivre

Recevez les nouvelles publications par mail.