Először is egyszerűen, sőt nemcsak fel, hanem le is, a kompatibilitás miatt ugyanis (az Azure is Hyper-V-vel működik), tényleg relatíve könnyű. Másodszor a feltöltés és így a felköltözés ingyenes, a letöltés már nem. Harmadszor, a feltöltéssel még nem ért véget a feladat, ahhoz hogy virtuális gépként használni is tudjuk a vhd fájlt, importálni kell, esetleg sysprep-eltként megjelölni (és így többször is felhasználni) és egyebek. Negyedszer, a lehetőségek bővülnek, ha 1 év múlva olvasod ezt, akkor még több, még jobb módszereink lesznek.

De nézzük sorban, én most öt lehetséges szkenáriót szedtem össze, képeket/ábrákat nem, ám rengeteg linket, hiszen korábban, szinten mindegyikről írtam már, tipikusan képes beszámolót (és persze mások is :D).

1. Azure Powershell

Talán a legegyszerűbb módszer, le kell tölteni a legfrissebb változatot, bekonfigurálni, azaz hozzákötni az előfizetésünkhoz, és mehet a feltöltés az Azure tároló fiókunkba, azon belül is a VHDS nevű konténerbe (ez alapértelmezés szerint létrejön a tároló létrehozásakor). A feltöltésre szánt virtuális lemezz(ekk)el (tehát ez nem egy VM) szemben támasztott két fontos kritériumot, azaz 1.; csak fix lemez lehet, 2.; egyelőre csak .vhd, automatikusan korrigálja. Fontos infó még, hogy (szintén egyelőre) csak a Gen1-es gépeket tölthetjük fel az Azure-ba, de ez általános elv, és nem ehhez a módszerhez köthető.

Itt kell megjegyeznem, hogy a Powershell csak Windows-okon műxik, de van cross-platform parancssori eszköz is Linux-ra, Mac-ra (Azure Cross-Platform Command-Line Interface), itt találjuk.

2. 3rd party programok

Számos külső, az Azure Storage fiókunkat is kezelő programmal is megtehetjük ugyanazt mint a PowerShell-lel, tipikusan annyi különbséggel, hogy van hozzá színes-szagos GUI-s felület, de a módszer ugyanaz. A linken lévő listából nem feltétlenül tudja mindegyik a vhd feltöltést (ezek ugye tipikusan “csak” Explorer jellegű alkalmazások), illetve van ezek között olyan, amely a fix/vhd konvertálást is megoldja, de van olyan is, amelyik nem. Ezt nekünk kell kideríteni és manuálisan megoldani, ha nem alkalmas erre a szoftver. Tessék kedvencet választani (nekem is van, a CloudXplorer), és használni, bár ezek a cuccok imho a fejlesztőknek segítenek többet, nem nekünk.

3. ASR

Legnagyobb örömünkre egy ideje a Microsoft lehetővé tette a helyi környezetben megszokott és remekül működő aszinkron Hyper-V Replica használatát, az Azure felé is. Ez az Azure Site Recovery (ASR) amely kicsit több is, mint egy sima Replica, ugyanis amellett, hogy egy disaster recovery megoldás a felhőben, még számos szervezési/irányítási (orchestrating, ez a jó szó) feladatot is elláthat pl. a telephelyeink közötti replikációt tekintve. Különböző forrás-cél variációk léteznek, nézzünk egyelőre négyet:

1. Hyper-V-to-Hyper-V replikáció irányítás és failover támogatás két telephelyünk között System Center VMM-mel. Elsőként ez debütált, és ez a változat még nem a felhőbe replikál, hanem “csak” onnan szervezi és írányitja a két telephelyünk közötti Hyper-V / SCVMM replikációt.
2. vSphere-to-vSphere replikáció irányítás és failover támogatás két telephelyünk között, jól látjuk, valóban lehetséges a VMware szerverek között is használni ugyanarra, mint az első pontot :)
3. Hyper-V-to-Azure replikáció és failover támogatás a helyi hálózatunk és az Azure között, amelyhez nem kell System Center, és a felhő ilyenkor a disaster recovery telephelyünk, azaz ugyanúgy replikálhatunk  virtuális gépeket, mintha két szomszédos HYper-V hostról lenne szó.
4. Hyper-V-to-Azure replikáció és failover támogatás System Center VMM-mel, ami azért komplexebb és hatékonyabb, mint egy szóló Hyper-V-vel, de az elv ugyanaz, mint az előbbi esetben, ugyanúgy a felhő ilyenkor a disaster recovery telephelyünk.
Természetesen egy helyi cluster esetén használható a Hyper-V Replica Broker is, van recovery point opció, állítható a replikációs intervallum (30mp, 5 perc, 15 perc), van test failover, frankó Recovery Plan-eket gyárthatunk az automatikus átkapcsolásra, természetesen a korrekt hálózati működés miatt össze kell rendelnünk a logikai hálózatainkat. Szükség van letölthető bővítményekre akár a Hyper-V, akár a System Center esetén, plusz az 1. számú alváltozat képes a SAN replikációra is! Egyszóval ez egy teljesen kész megoldás, ami remekül működik.
4. Migration Accelerator
A Microsoft tavaly megvette az InMage nevű céget, amely kifejezetten a felhőkörnyezetekbe történő replikációval foglalkozott. Az ASR kapcsán már használja is ezeket a Microsoft, pl. a VMware szerverekhez vagy a SAN-hoz kapcsolódó megoldás már ennek a vételnek gyümölcsei. De jött és jön még más is, azaz az InMage Scout nevű szoftverén alapuló Migration Accelerator (MA), ami jelenleg még preview állapotban van, és csak az észak-amerikai adatközpontokban érhető el.
A segítségével fogunk tudni migrálni Hyper-V, vSphere és Amazon Web Services* (AWS) virtuális gépeket, gyorsan, gyakorlatilag zéró kieséssel, kényelmesen. VM szintű művelet lesz, lehet szelektíven válogatni, ugyanúgy mint az ASR-nél, a Scout komponenseket illeszteni kell majd a forrásba, és könnyedén kapcsolgathatunk majd a VM két lelőhelye között – ezek az ígéretek, és ez mind nagyon jól is hangzik.
5. Microsoft Virtual Machine Converter 3.0

Ez egy relatíve egyszerű, GUI-s szoftver harmadik verziója, Microsoft gyártmányú, és a 2.0-ás változattól kezdve már nem csak egy vCenter-en keresztüli vSphere importot tud Hyper-V-be, hanem direktben az Azure-ba is. A direktet úgy értem, hogy számunka ez a folyamat nem két lépés, hanem egy, importál, majd feltölt. Szépen műxik, korábban már írtam róla, van PowerShell támogatás a nagyobb mennyiségű migrációhoz önkiszolgáló migráció a System Center Service Manager-rel.

—

*System Center 2012 R2 VMM és az AWS for VMM 1.5 add-in segítségével már tudunk importálni AWS-ből a VMM-be virtuális gépeket (az 1.0-ás add-in-nal még csak alapműveletek voltak elérhetőek), ez gyakorlatilag tegnapi hír, de ki is próbáltam már, működik.