Videó: Установка драйверов ADB и Fastboot под Windows (November 2024)
A heves hetekben, amikor a házastársak milliói izzadták az Ashley Madison szivárgását, és Isten elérte, hogy legalább négy villámcsapással elcsípje a Google-t, a Microsoft csendesen kiadta mind a Windows Server 2016 (WS2016), mind a System Center műszaki előnézetét 3 (TP3). A Configuration Manager (ConfigMan), valamint néhány más probléma, például a Microsoft Deployment Toolkit (MDT) 2013 frissítése - amelynek végül teljes mértékben támogatnia kell a Windows 10-et.
Még mindig megemésztem a ConfigMan és az MDT specifikációit, de két 4 órás, mélyreható webinaron keresztül a Windows Server 2016-on keresztülmentem ezen a héten, Matt McSpirit, a Microsoft vezető műszaki termék-marketing menedzserének és Corey Hynes, Microsoft-nak. MVP és vezérigazgató a Learn on Demand Systemsnél. A WS2016 webináriumain, annak ellenére, hogy már TP3, az volt az első valódi expozícióm az új operációs rendszerrel (Hé, életem van!).
Az első dolgok először: Ezek a munkamenetek hosszúak, de rendkívül értékesek voltak, lefedve a Windows Server összes mérföldkőbeli újdonságát, de hasznos mélységgel. A Microsoft mindkét munkamenetet rögzítette, és hamarosan szabadon elérhetőek lesznek a Microsoft Virtuális Akadémia webhelyén, a munkamenet-csomagokkal, bemutatókat és az erőforrás linkeket csatolva. Tehát, ha egyáltalán a WS2016 a radaron van, nagyon ajánlom figyelni őket.
Windows Server tárolók
A fontos tulajdonságokkal kapcsolatban: Kétségtelen, hogy a TP3 számára a legfontosabb hír az, hogy a Microsoft beépítette a Docker-kompatibilis tárolótechnológiát, mind az operációs rendszer, mind a Hyper-V rétegeken. Ahogyan a redmonditák rámutattak, a konténerek régi hírek a fejlesztők és talán a DevOps nindzsák számára, ám valószínűleg nem voltak a legtöbb informatikai adminisztrátor gondolkodásában. Végül is van virtualizációnk, tehát kinek kell tárolók? Nos, talán te.
A konténerek fogalmazásának a legjobb módja egy pillanatkép a mögöttes operációs rendszer egy adott állapotáról, amelyet önállóan elválaszthat és futtathat. Tehát például összecsukhat egy konténert egy alapvető WS2016 példány alapján, hozzáadhat egy tárolókészülékre kész alkalmazást, csíphet be bizonyos beállításokkal vagy engedélyekkel, majd mentheti az egész shebang-ot, hogy emlékeztessen arra, amikor ez a operációs rendszer-állapot a jövőben szükséges.
Ez nem egy virtuális gép (virtuális gép), hanem egy olyan beállítások és alkalmazásmutatók gyűjteménye, amelyek úgy gondolják, hogy független operációs rendszer, és aktiválásuk során így viselkednek - mindaddig, amíg a mögöttes operációs rendszer, amelyen futnak, rendelkezik az összes szolgáltatással, konténer igényeinek. Ez nem biztosítja a teljes bekapcsolt virtuális gép teljes elszigeteltségét vagy hordozhatóságát, de sokkal gyorsabban skálázódik (gondolom másodperc), és sokkal nagyobb sűrűséget biztosíthat gazdagépenként. Nem hasznosak az IT részlegektől elvárható szolgáltatások közül soknál (talán még a legtöbbnél is), ám ezek nagy értéket képviselhetnek a dinamikus alkalmazáskiszolgálásban, valamint a nagyszabású fejlesztői / tesztkörnyezetekben.
Ahol a WS2016 tartályok számára bonyolult lesz, ott van a Hyper-V réteg. Igen, a Microsoft bevezeti a "Windows Server tárolókat" és a "Hyper-V tárolókat", és nem, nem ugyanaz. A Microsoft teljes mértékben megvalósította a tárolókat az operációs rendszer rétegén, vagyis telepíthet egy fizikai gazdagépes operációs rendszert, és abból építheti a tárolókat (Windows Server tárolók), de a Hyper-V hipervizor rétegén is megvalósította a tárolókat. Tehát most már rendelkezhet gépi szintű operációs rendszerrel a Hyper-V futtatásával, majd összeállíthat konténereket egy virtuális gépben, amely ugyanazon a dobozon található, vagy két vagy több.
Valójában ezt kétszer megteheti, valójában fészkelő hipervizorokat: A kiszolgáló futó Hyper-V, virtuális gépet tárolva, amely egy csomó tárolót tárol egy másik virtuális gépen, valamint egy Hyper-V futtatással, amely egy másik csomagot tárol. Miért? A Microsoftek nem voltak egyértelműek ebben, kivéve azt állítva, hogy egy Hyper-V tároló egy kicsit veszít az erőforrás-konszolidációs osztályon, miközben elnyeri az izolációs képességeket, ezért gondoljon a speciális tárhely és a többszörös bérlő szcenáriókra.
A konténerektől eltekintve, amelyek nagy hírek voltak, a McSpirit és a Hynes számos más tulajdonságot mutatott, amelyek többségét megemlítették a TP korábbi dokumentációjában:
Nano szerverek: Még több mini-me virtualizáció. Gondoljon egy Windows Core stílusú virtuális gépre, amely csak az adott funkció végrehajtásához szükséges biteket tartalmazza. Gyorsan felépíthetők, és mivel csak a szükséges kódot magukkal veszik, kevesebb, mint 200 MB-n tudnak futni, nem pedig egy tipikus virtuális gép 3–4 GB-os + helyén. Ezenkívül nincs szükségük szokásos virtuális gép újraindítási ütemére, mivel a kódnak csak kis százalékát kell javítania. A Microsoft a Nano-kiszolgálókat használja az alapszövet-szolgáltatások előnyben részesített kiszolgálójaként (lásd alább). A hátránya, hogy konfigurálásuk után nem frissíthetők és nem változtathatók meg, és a Microsoftee sem tudta, hogy mi lesz az ilyen példányok licencterve - bár mindkettő gyanította, hogy nem lesz új mini-me licenc, csak egy szokásos szerver ára. Csak egy újabb lendület a tavaszhoz a Datacenter kiadáshoz.
Titkosított virtuális gépek: Végül, még néhány biztonság a virtuális gépek körül. Ebben a sémában a Microsoft a BitLocker használatával védi a Hyper-V virtuális gépeket, a kulcsokat egy megbízható AD erdőben tárolja, és bizalmi kapcsolatot épít ki a virtuális gép erdő és a kulcs erdő között (és ez alatt az erdőt értem, nem a tartományt). Ez megvédi az árnyékolt virtuális gépeket a lopásoktól, ellenőrzésektől és bármiféle manipulációtól, bár nyilvánvalóan logóval ellenőrzött hardvereket igényel a szerver oldalán, amelyeken megbízható platformmodul (TPM) szilikonnak kell lennie, és Unified Extensible Firmware Interface-t (UEFI) kell használni.
Nincs állásidő-frissítés: Jó azok számára, akik misszió szempontjából kritikus szolgáltatásokat nyújtanak, vagy szolgáltatási szintű megállapodás (SLA) korlátozások alapján dolgoznak. Ez egy olyan sémának felel meg, amelyben a gazdagépek és a fürt virtuális gépek egyaránt frissíthetők WS2016-ra a szolgáltatás lekérése nélkül. A bemutató manuálisan és nagyrészt a parancssorban, a PowerShell-en keresztül történt, de a Microsoft a végső kiadás révén további automatizálást ígér.
Szoftver által definiált tárolás: Az újdonság elsősorban a Direct Spaces Direct-re összpontosít, amely lehetővé teszi az adminisztrátoroknak, hogy a különálló csak egy csomó lemezt (JBOD-ket), valamint a fájlkiszolgálókat egyetlen rétegbe egyesítsék, több réteg helyett. Hynes szavaival: "Gondolj rá RAID-re szerver szinten, vagy nevezze megosztott-semmi klaszterré."
Rugalmas fájlrendszer (ReFS): Nem új, de határozottan érett a WS2016-ban, jelentős teljesítménynövekedéssel érhető el a kezelési műveletek, például az egyesítések.
Tárhelyreplikáció: Új a WS2016 számára, ez a technológia lehetővé teszi a tárolási szintű szinkron replikációt az adatfürtökön, beleértve a metró távolságokat is, és a csomópont azonnali feladatátvételét eredményezi, szolgáltatásmegszakítás nélkül.
Elkerülhetetlen PowerShell
Mindezek a funkciók nagyszerűen hangzanak, de megdöbbent egy, a mindet átlépő funkciótéma: a PowerShell. Hynesnek még egy mondó idézete volt, bár kissé újrafogalmazom: "Ha szerver adminnak akarsz lenni, akkor elkerülhetetlen a PowerShell tanulása, ezért tanulj meg szeretni." Ez nem teljesen új üzenetküldés a Microsoft-tól, de a tompa érzés friss. A lényeg az, hogy a Microsoft figyelmeztette Önt: a PowerShell már nem csak egy lehetőség.
És a szinte minden olyan demó jellege alapján, amelyet ezen a nyolc ülés órájában mutattak be, nem viccel. Igaz, a TP3-nál vagyunk, tehát sokkal grafikusabb felhasználói felület (GUI) lesz az általános elérhetőség (GA) által támogatott, de kipróbálhatja néhány ilyen funkciót, és akkor is láthatja, még ha GUI-fedvényt kapnak a jövőben nagyrészt a PowerShell szem előtt tartásával készültek. A Microsoft all-in megy a DevOps koncepcióival és a szoftver által definiált mindent, és a PowerShell a stratégia csúcsa. Ha a munkaköri leírása jelentős számú Windows platformon működő gép - kiszolgálók vagy kliens eszközök - kezelését foglalja magában, és valóban meg akarja őrizni ezt a munkát, akkor vedd át a Hynes-től: Csatlakozzon és tanulja meg a PowerShell alkalmazást.
Szerencsére valóban ez egy hatalmas technológia. A PowerShell, a McSpirit és a Hynes segítségével sikerült az on-the-fly automatikát konfigurálni és konfigurálni és felcsavarni a Nano Szervereket egy (hosszú) kódsorral, növelni és csökkenteni a futó virtuális gép memóriáját, és csatlakozni a virtuális gépekhez, amelyek bejelentkezéssel és hálózati zavarral rendelkeznek. a PowerShell parancsok végrehajtása a virtuális gép buszon keresztül. A következő nyolc órányi Windows-figyelésem után a következő játékváltóhoz vezet: Szoftver-alapú hálózat (SDN).
Az SDN a Windows Server 2012 R2-ben már egy meglehetősen összetett kép volt, a Hyper-V bővíthető kapcsolóra és a Virtuális hálózati átjáró szerver szerepére összpontosítva. A WS2016-ban mindez tovább javul, ám e fejlesztések nagy része abból származik, hogy a Windows Server miként indít egy második hálózatot - a Hyper-V hálózatot - egy szinttel a jelenlegi nettó alatt. A McSpirit és a Hynes által használt másik általános kifejezés: "Hagyja, hogy a szoftver aggódjon." A szoftver, amelyről beszélnek, a kezelhető virtualizációs logika e rétege, amely az IP-hálózatok alatt helyezkedik el, összeköti őket, és kezeli a közti forgalmat és az irányelveket.
Az IP-címkezelés (IPAM) például képes megjeleníteni az összes IP-hálózatot, az Active Directory (AD) tartományokat, valamint a fizikai vagy virtuális hálózatokat (beleértve az Azure-alapú hálózatokat) - akkor is, ha vannak redundáns címzési sémákat, és kezeli a forgalom és az erőforrások elosztását közöttük.
Egy másik kulcsfontosságú fejlesztés a virtualizált hálózati funkciók bevezetése. Gondolhat ezekre mint készülékekre (és fogadhat el, hogy a Nano Server használatával rá kell őket telepíteni), amelyek a mai kapcsolóállványokon összeszerelt doboz funkcióit teljesítik: tűzfalak, útválasztók, intelligens kapcsolókat és terheléselosztókat, hogy csak néhányat említsünk. McSpirit rámutatott, hogy ezeknek a "készülék által igénybe vett" képességeknek nagy része csata-tesztelt technológiák, amelyeket az Azure-ból hoztak le a Windows Serverre (ahol már egy ideje futnak), így nem kell annyira aggódnia az átalakítás miatt az újtakarékos szoftver infrastruktúrája. Megvárom, majd megnézem ezt, de újdonság az, hogy miként konfigurálják és kezelik őket. Ez történik az új WS2016 Network Controller segítségével, amely úgy hangzik, mint egy honking konzol, új szerver szerep, vagy valószínűleg mindkettő.
A hálózati vezérlővel teljes mértékben ellenőrizheti az SDN telepítését, és nemcsak az IP hálózati jellemzőit (beleértve a tűzfalakat, a terheléselosztókat és a Windows Server Gateway-t), hanem a Hyper-V szövet rétegeit is vezérelheti. még a szolgáltatás teljesítménye az intelligens forgalomátirányítás révén.
Összességében, ha egy vállalati informatikai adminisztrátor vagy, ez a cucc izgalmasnak tűnik. De a bennem lévő cinikus attól tart, amikor bárki azt mondja nekem: "Ne aggódj a te szép fejednél, hadd vigyázzon rá neked." Nagyon sok a bonyolultság, amelyet eltakar a virtualizált, parancssori, kód-nehéz logika. A McSpirit és Hynes új trendként festette fel, amely csökkenti a hibaelhárítás szükségességét. Nem vagyok benne olyan biztos. Tapasztalataim alapján úgy hangzik, hogy egyszerűen áthelyezi a hibaelhárítást a vezetékektől és a villogó lámpáktól a parancssorba - és a fent említett és egyre elkerülhetetlen PowerShell-re.
Ezenkívül, miközben a virtuális gépek BitLockerrel történő árnyékolása nagy lépés, sokat szeretnék hallani - sokat! - többet meghallgatni a biztonsági bevált gyakorlatokról a hálózati vezérlő védelme szempontjából. Jelenleg valaki veszélyeztetheti a hálózatomat, és megragadhatja annak részeit - még a nagy részeit is. De ezzel a hálózati vezérlőrendszerrel úgy hangzik, mintha mindent megragadnának, még több hálózatot is, ha a hálózati vezérlőt egynél több szövet irányítására használom. Ez egy csomó tojás egy Microsoft kosárhoz. Színezz bennem a látomás, de a valóság még nem volt meggyőzve.
Nyilvánvaló, hogy még sok más van a WS2016-nál, amiket át kellett ragyognom, mint például a távoli közvetlen memória-hozzáférés (RDMA) virtuális támogatása, fokozott automatizálása, további édesség a Linux számára, a PowerShell webes hozzáférés és még sok más. Szerencsére a McSpirit és a Hynes sok hasznos linket tett közzé (lásd alább), köztük a TP3 letöltését, amely lehetővé teszi a WS2016 alaposabb felfedezését. Letölthetek néhány PowerShell útmutatót.
