Sebastien.warin.fr

En partenariat avec

Le WygDay est une journée organisée par Wygwam et Microsoft, complètement consacré à la veille technologique. De nombreux experts de chez Wygwam et Microsoft vous présenteront un aperçu des technologies émergentes et témoigneront de leurs expériences. C’est l’occasion d’échanger directement avec eux !

Nous aborderons cette année, différents axes : Développement Visual Studio 2010, Architecture/Industrialisation, SharePoint 2010, Office 2010, Exchange 2010, Cloud Computing, Cartographie, Bing Maps, Recherche et Innovation. Pour plus d’informations sur les sessions : http://wygday.wygwam.com/Sessions.aspx

Venez nous retrouvez en vous inscrivant sur notre site WygDay 2010.

Rendez-vous le 8 juin 2010 à EuraTechnologies
165 avenue de Bretagne 59000 Lille
Métro Canteleu (Direction St Philibert – Ligne 2)
Parking gratuit et sécurisé

Pour ma part retrouvez-moi en plénière le matin à 9h, et l’après-midi pour une session sur la Stratégie et le développement Cloud à 13h30 et à 14h45 pour présenter le xBrainLab.

A demain

Toujours dans le cadre de notre migration, nous avons dû migrer des serveurs virtuels de VM Ware ESX vers Hyper-V. J’ai creusé plusieurs pistes avec ce que l’on peut trouver sur Google à ce sujet, et voici la solution que j’ai retenu pour réaliser cette tache.

Etape 1 : préparer la VM

Il faut commencer par désinstaller les VM Additions sur la machine virtuelle pendant qu’elle tourne encore sur ESX. En effet, il vous sera impossible de le faire par la suite; il vous faudra alors les supprimer à la main en suivant la KB de VM Ware ce qui est un peu moins amusant !

Ensuite, il faut supprimer vos “snapshots” (appelé Checkpoints sous Hyper-V). Via le “Virtual Infrastructure Client” (client lourd de gestion du serveur ESX), cela est relativement facile en cliquant-droit sur les VMs en question, vous pourrez accéder aux snapshots de la VM et les supprimer facilement (boutons Delete / Delete All).

En effet, la création de snapshots engendre la création à la volé d’un disque de différenciation permettant d’écrire toutes modifications sur le disque dans un fichier séparé (une sorte de disque de différentiation) dans le but de pouvoir revenir à l’instant où a été créée la snapshot. Ces snapshots engendrent donc le “splittage” du disque virtuel dans différents fichiers (dont les .delta) incompatible pour réaliser notre conversion. Le fait de supprimer ces snapshots permettra de “merger” (fusionner) votre disque virtuel en un seul fichier, le *.vmdk.

Etape 2 : récupérer l’image de la VM

Une fois notre machine virtuelle préparée (plus de VM Additions et disques virtuels “propres”), il faut récupérer le disque dur virtuel de votre VM (le .vmdk). Etant donné que vous avez accès à votre serveur ESX en SSH (serveur linux), nous pouvons utiliser SCP pour parcourir notre serveur ESX et récupérer l’image.

Dans ce but, il existe l’outil Win-SCP que j’utilise habituellement mais le taux de transfert (sur un lien Ethernet Gigabits) n’’a pas excédé 3Mo/s fort limitant pour des VMs qui pèsent entre 20 et 60Go.

En cherchant un peu, j’ai mis la main sur un outil gratuit de Veeam nommé “FastSCP” qui, comme son nom l’indique, est beaucoup plus rapide (jusqu’à 6 fois plus rapide que les autres).

Promesses tenues, j’ai pu récupérer mes images à une vitesse moyenne de 20Mo/s.

Etape 3 : convertir l’image VMWare (vmdk) vers le format Hyper-V (vhd)

Une fois notre disque virtuel récupéré sur notre poste Windows, j’ai utilisé l’excellent utilitaire WinImage en version 8 permettant très facilement de convertir un disque dur virtuel WM Ware (vmdk) en une image Hyper-V (vhd).

Etape 4 : remonter la VM sur Hyper-V

Une fois notre disque virtuel converti en VHD, j’ai remonté une nouvelle machine virtuelle Hyper-V (en utilisant System Center Virtual Machine Manager pour ma part) en spécifiant notre disque virtuel VHD fraichement converti. SCVMM s’est occupé de déployer les VM Additions d’Hyper-V automatiquement, et la VM a pu redémarrer sans aucun souci sur un hyperviseur Hyper-V.

Migration de VM Ware ESX vers Hyper-V réussie, merci à Fast-SCP, WinImage et SCVMM pour le boulot

Je me suis retrouvé il y a quelques semaines à refaire l’infrastructure IT chez Wygwam en migrant d’un environnement Virtual Server / VM Ware ESX / Windows 2003 vers un environnement full Microsoft avec Windows 2008 R2 / Hyper-V, SCVMM, SCDPM, & Co…

En supprimant proprement des contrôleurs de domaine (via dcpromo) une erreur m’en empêche  m’indiquant que des rôles FSMO ont été supprimés et n’existent plus :

Ownership of the following FSMO role is set to a server which is deleted or does not exist.
Operations which require contacting a FSMO operation master will fail until this condition is corrected.
FSMO Role: CN=Infrastructure,DC=DomainDnsZones,DC=wygwam,DC=com
FSMO Server DN: CN=NTDS Settings\0ADEL:18a67e84-64fc-4be4-97cc-e28dd0100576,CN=WYGSERVER\0ADEL:6cc8b949-b186-4120-9f6b-085c8c84806b,CN=Servers,CN=Premier-Site-par-defaut,CN=Sites,CN=Configuration,DC=wygwam,DC=com

J’ai donc sur ce pas vérifié dans la console MMC d’Active Directory, les “Operations Master” de notre domaine. Mais rien d’anormal, le ou les serveurs pour les différents rôles sont correctement configurés.

Pour creuser un peu plus loin, vous pouvez aussi vérifier voir redéfinir les bons serveurs avec l’utilitaire “NTDSUtil” (en mode “fsmo maintenance”) en suivant notamment la KB255504. Là aussi, dans mon cas, rien d’anormal, tous les rôles FSMO sont correctement configurés vers les bons serveurs comme me le confirme un “netdom query fsmo” :

En relisant l’erreur, ce qui m’a le plus perturbé, c’est le nom du serveur qui pose problème : “WYGSERVER\0ADEL:6cc8b949-b186-4120-9f6b-085c8c84806b”. WYGSERVER étant chez nous un ancien contrôleur de domaine qui nous a “lâché” il y a déjà plusieurs mois/années. Nous avions pourtant à cette époque correctement migré tous les rôles Active Directory, et supprimé complètement les objets AD et DNS vers ce serveur.

En relisant aussi ce message d’erreur, autre interrogation concernant le rôle FSMO qui pose problème : “CN=Infrastructure,DC=DomainDnsZones,DC=wygwam,DC=com”. Visiblement bien que supprimé ce rôle était toujours sous l’appartenance de l’ancien contrôleur “WYGSERVER” et je ne savais où le vérifier (par rapport aux différentes MMC pour la gestion d’Active Directory).

J’ai donc sorti l’artillerie lourde avec “ADSIEdit” pour fouiller ce qu’il y a vraiment dans notre Active Directory. Je n’ai pas tout de suite trouvé car cet objet ne se trouve pas dans les “Naming Context” connus par défaut. Il faut spécifier le “Distinguished  Name”, dans notre cas “DC=DomainDnsZones,DC=wygwam,DC=com” :

Il devient alors possible d’accéder à notre objet “Infrastruture” qui semble être à la source du problème :

En éditant les propriétés de cet objet, j’ai pu constater que l’attribut “fsmoRoleOwner” défini pointé vers notre ancien contrôleur de domaine d’où la présence du “0ADEL:xxxx” dû fait que ce contrôleur n’existait plus :

J’ai donc pu correctement redéfinir cet attribut en sous la forme : “CN=NTDS Settings,CN=<SERVER_NAME>,CN=Servers,CN=<SITE_NAME>, CN=Sites,CN=Configuration,DC=wygwam,DC=com” (en remplaçant respectivement SERVER_NAME et SITE_NAME par le nom de votre serveur et le nom de votre site AD) :

Il a fallut faire de même avec le rôle “ForestDnsZones” en éditant la valeur de l’attribut “fsmoRoleOwner” sur l’objet “Infrastructure” du schéma “CN=ForestDnsZones,DC=wygwam,DC=com”.

Une fois ces rôles correctement configurés, le retrait de contrôleur de domaine dans notre organisation ne vous posera plus de problème

Il y a un peu près un an j’écrivais sur mon blog trois articles sur l’extensibilité de Visual Studio 2008 :

• Part 1 : Comment étendre Microsoft Visual Studio

• Part 2 : créez vos fenêtres d’outils avec CreateToolWindow2 !

• Part 3 : Quelques interactions avec Visual Studio

Quelques jours après je poursuivez sur une introduction à MEF : Managed Extensibility Framework.

Le rapport ? Et bien mélangez les deux et vous aurez le nouveau modèle d’extensibilité de Visual Studio 2010 En ajoutant aussi que le nouvel éditeur de code en WPF (où l’on appréciera grandement le Zoom-In/Out lors de présentation), nous apporte des tas de possibilité en matière d’extension.

Jugez par vous même! Aurait-on pu avoir ce genre de comportement dans les versions antérieures ?

Un petit “add-in” qui remplace les chaines de caractères “wygwam” et “microsoft” par leurs logos respectifs ! Oui je sais cet add-in est inutile mais il montre bien les possibilités apportés “je fais ce que je veux où je veux…. Et en WPF”

Un petit article de présentation arrivera prochainement, en attendant retour en mode préparation des TechDays

Microsoft vient de publier la nouvelle version du SDK pour Windows Azure, version 1.1 de Février 2010 que vous pouvez retrouver sur :

• Windows Azure Software Development Kit (February 2010)
• Windows Azure SDK & Tools for Microsoft Visual Studio (February 2010)

Hormis la correction de quelques bugs de la version 1.0 (Novembre 2009) notamment avec le StorageClient ou l’API Diagnostics (prochainement abordé dans le Coach Azure MSDN), cette nouvelle version apporte deux nouveautés non-négligeable :

• Le “OS Version Support”
• Un nouveau service des Azure Storage : le Azure Drive

OS Version Support

Le “OS Version Support” est un attribut (nommé “osVersion”) que l’on va placer sur notre ServiceConfiguration.cscfg (fichier de configuration de notre service Azure) pour définir quelle est la version de l’OS qui va exécuter notre application, on appelle cela le ‘”Guest OS”.

Pourquoi ? Tout simplement pour éviter les problèmes de changement/mise à jour des machines virtuelles qui exécutent mon application.

Ainsi une application écrite avec la version 1.0 du SDK pourra choisir de s’exécuter sur la version Windows Azure Guest OS 1.0 (Release 200912-01) ou sur la Windows Azure Guest OS 1.1 (Release 201001-01). Par contre une application écrite avec la version 1.1 du SDK Azure tournera forcement sur la Windows Azure Guest OS 1.1 (Release 201001-01).

On a donc le choix entre le Windows Azure Guest OS 1.1 défini par la clé WA-GUEST-OS-1.1_201001-01 et l’ancien Windows Azure Guest OS 1.0 défini par la clé WA-GUEST-OS-1.0_200912-01. Ainsi, bien que Microsoft continura d’e faire évoluer les Guest OS, mon application pourra continuer de fonctionner dans la version pour laquelle elle a était écrite sans problème d’upgrade.

Par exemple pour que mon service fonctionne sur la version 1.1, le début de mon fichier de configuration ressemblera à cela :

1
2
3

<ServiceConfiguration serviceName="CloudService1" osVersion="WA-GUEST-OS-1.1_201001-01" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="WebRole1">
	....

Azure Drive

Annoncé en Novembre 2009 lors de la PDC09, le service Azure Drive (anciennement XDrive) permet de “monter” le service des Azure Blobs comme une partition NTFS (ex: X:\) sur le service Compute de Windows Azure. Si ces notions ne vous sont pas familières je vous invite à parcourir notre coach Azure sur la MSDN ainsi que notre Azure Roadshow. Ce service n’est disponible que dans un rôle (web ou worker) Windows Azure en version 1.1 (voir OS Version ci-dessus).

Derrière cela se cache en fait le service des Azure Blobs qui va stocker un disque dur virtuel VHD. Ce VHD utilise le Azure Blob Page Blob introduit en Novembre 2009 et non le classique Block Blob. Vous retrouverez sur notre Azure Roadshow à la slide 67 les différences majeures entre les Blocks et Pages blob.

Le VHD doit être partitionné en NTFS et vous avez ensuite la possibilité de pouvoir uploader/downloader vos propres VHD en utilisant le service des Blobs. Comme l’indique la slide 67 de notre Azure Roadshow, votre VHD ne pourra excéder 1 To (limite d’un Page Blob). De plus chaque VM peut monter jusqu’à 16 “Drives”.

Côté “prix”, vous payerez l’utilisation du service des Azure Storage à savoir $0.15 par GB et $0.01 toutes les 10000 transactions dans le forfait “Consumption” (voir le détail ici).

On pourrait alors se demander comment connaitre le nombre de transaction effectué lorsque j’accède au contenu de mon VHD stocké dans un PageBlob ? C’est pourra cela qu’on utilise un ”local-cache” grâce aux “Local Storage” du service de Compute de Windows Azure.

Vous définissez ainsi un LocaStorage à utiliser sur votre VM (voir le Coach MSDN pour mieux comprendre le LocalStorage – en résumé c’est un espace de stockage NTFS local à la VM qui est réinitialisé à chaque démarrage de la VM) par les lignes :

1
2
3
4
5

<LocalResources>
      <LocalStorage name="MyAzureDriveCache" 
                    cleanOnRoleRecycle="false" 
                    sizeInMB="220000" />
</LocalResources>

Votre LocalStorage pourra être accessible sur la lettre Z:\ dans votre VM Azure.  La taille du LocalStorage dépend de la taille de votre VM. Sur une Small instance on dispose de 250Gb, sur une Extra large instance on a 2Tb (voir le détail ici).

Il faudra ensuitre initialiser votre LocalStorage pour qu’il remplisse son role de “cache” pour les Drives par la ligne :

1
2

CloudDrive.InitializeCache(localCache.RootPath, 
              localCache.MaximumSizeInMegabytes);

Et pour finir vous pourrez monter votre “drive” sur votre LocalStorage par le code :

1
2
3

CloudDrive drive1 =  
    new CloudDrive(new Uri(“http://account.blob.core.windows.net/container/Blob1”), credentials);
drive1.Mount(200000, DriveMountOptions.None);

En clair, ce service va nous permettre de manipuler nos dossiers/fichiers comme nous le faisions On-Premise sur nos Windows Server sans devoir réécrire nos applications existantes. Derrière cela tout repose sur les PageBlob nous garantissant une disponibilité de 99,99% et failover automatique.

Plus d’informations :

• Le blog de la Team Azure
• Le livre blanc sur le service Windows Azure Drive