nLite és vLite
Tudta Ön, hogy ingyenes szoftverekkel kidobálhatja Windows telepítőjéből a felesleges részeket, vagy automatizmusokat és meghajtóprogramokat (pl. RAID driver) építhet bele?
A Windows 2003 Server install floppy-t kér?!
intel RAID meghajtó integrálása a Windows Server telepítőjébe
A szoftverek világában az a szép, hogy sokszor egyetlen ember áll elképesztően hasznos programok fejlesztése mögött. Például Alexander Roshal, akié a WinRAR, vagy Miklós Tamás, aki az AIDA32, illetve az Everest fejlesztője. Az nLite és a vLite is egyetlen személy, Dino Nuhagic - azaz nuhi - gyermeke. Előbbi program segítségével a Microsoft Windows 2000, a Windows Server 2003 és a Windows XP, utóbbival a Windows Vista szabható méretre. Az nLite nem újdonság. Most azért vettük elő, mert decemberben megszületett a Vistát átszabó testvére, illetve itt van az ajtóban a XP harmadik és a Vista első szervizcsomagja is - ezeket igazán hasznos rögvest beépíteni az operációs rendszer telepítőjébe, mintsem utólag installálni.
Mire valók?A két program funkciói gyakorlatilag azonosak: arra szolgálnak, hogy teljesen a mi igényeinknek megfelelően szabjuk át a fent említett Windows-változatok telepítőit. Hogy pontosan mire nyílik lehetőségünk?
A vLite kezelése kicsit kényelmetlenebb, mint elődjéé
• Szervizcsomagok, javítások integrációja: Nyilvánvaló előnyei vannak, ha rögvest a Windows telepítőkészletbe integráljuk a legújabb frissítéseket. Rövidebb a telepítési idő, és az utólag installált service pack sem "szemeteli össze" az állományaival a merevlemezt. Arról már ne is beszéljünk, hogyha valaki hozzánk hasonlóan rögtön a premier után szerezte be XP-jét, akkor valószínűleg beleütközött abba a problémába, hogy az "ős", az SP1 és SP2 elõtti XP egy mostani, SATA-vezérlős, PCI Express-es gépre fel sem települ, hanem még a karakteres képernyős állapotában "kékre fagy". Ha valaki ebben a cipőben jár, akkor számára az nLite valóságos áldás. Ráadásul nincs szükség semmiféle trükközésre, egészen egyszerűen meg kell mutatni az nLite-nak, hogy hol találja a pakkot, amit integrálnia kell, a többit már magától elintézi.
• Beépített komponensek eltávolítása: Gyanítjuk, ez a funkció sokak kedvence lesz. Végre megszabadulhatunk olyan összetevőktől, amelyeket ha akartunk, ha nem, a telepítő odapetézett a merevlemezünkre! Manapság ez nem igazán a feleslegesen felhasznált merevlemez területről szól - bár szólhat arról is, hiszen amíg gyémánt árban mérik a solid state meghajtókat, és azok kapacitása csak töredéke a merevlemezekének, minden megabájt számít. Mindennél fontosabb azonban a dolog pszichológiája. Végre nincs ott a menüben az az átkozott Fekete Macska, a flipper, vagy éppen az Internet Explorer 6, ami helyett úgyis a 7-est telepíti az ember - ezt eleve integrálni lehet a telepítõbe -, vagy a Firefoxot, vagy amit éppenséggel szeret. • Meghajtóprogramok integrálása és eltávolítása: Meg fogunk lepõdni, hogy mekkora hely szabadul fel, ha kidobáljuk azoknak a hardvereknek a telepítőit, amelyek az XP 2000-es piacra dobása óta egyszerűen elavultak! Valószínûleg nem lesz szükségünk analóg modemek drivereire, vagy 8-10 éves nyomtatók meghajtóira, és sok más egyébre sem, amiről valószínűleg még csak nem is sejtettük, hogy benne van a Windowsban. Viszont a friss meghajtók integrálása nem biztos, hogy sikerül majd. Ezeket csak akkor lehet lenyomni a telepítő torkán, hogyha úgy készítették el õket, ahogy azt anno a Microsoft szerette volna. • Felügyelet nélküli telepítés: Van mód arra is, hogy például a sorozatszám megadásával olyan telepítõt készítsünk, amelyet elég csak elindítani, kijelölni azt a partíciót, melyen látni szeretnénk, aztán magára is hagyhatjuk a gépet a telepítés közben. A jobbára egységes gépparkkal rendelkezõ rendszergazdáknak nem kell elmagyaráznunk, hogy ez mennyire hasznos.
• ISO állomány készítése: A programok képesek bootolható ISO állományt készíteni, vagy rögvest megírni az optikai lemezeket. A telepítőkészlet elkészítésén kívül a lemezre elhelyezhetünk további állományokat is, például azoknak a drivereknek vagy programoknak a telepítõit, amelyek a rendszer telepítése után azonnal kellenek, vagy jó, ha kéznél vannak.
nLite: ha nem érted, pontosan mit csinál, akkor ne piszkáld
Kíváncsiak voltunk arra, hogy a Microsoft hogy viszonyul az nLite és vLite használatához, hogy nem sérti-e a használatuk a végfelhasználói licencszerződést. A jó hír, hogy nem!
Tanulmányozva az EULA-t az alábbi mondatban definiáljuk a szoftver legális használatát:
A Termék egy példánya telepíthetõ, használható, jeleníthető meg, illetve futtatható egyetlen számítógépen, például munkaállomáson, terminálon vagy más készüléken.
További utalást az EULA nem tartalmaz a módosított telepítésre vonatkozóan. Azaz, ha a felhasználó rendelkezik a szükséges liszensszel akkor megengedett a telepítő testre szabása, frissítése és módosítása. Erre a feladatra egyébként a Microsoftnak a Vista esetében van saját megoldása is, ez a Microsoft Windows Automated Installation Kit (röviden AIK vagy WAIK), mely tartalmazza az összes olyan eszközt, mely a rendszergazdák számára megkönnyíti a Windows Vista képfájl-alapú telepítõkészletének létrehozását és konfigárását. Megkérdeztük a Microsoftot
Buktatók
Mind az nLite-ot, mind a vLite-ot alaposan teletűzdelték rövid és lényegre törő súgókkal, amelyeknek különösen a komponensek eltávolításakor látjuk majd hasznát. Ne gondoljunk semmiféle dagályos, hosszú lére eresztett szövegszörnyre, sokkal inkább "ha ezt eltávolítod, akkor nem tudsz majd nyomtatómeghajtókat telepíteni" típusú figyelmeztetésekről van szó. Ha mindent figyelmesen elolvasunk, és a "ha nem érted, mit csinál, akkor ne piszkáld" irányelvet tartjuk szem előtt, akkor nem csúszhat be gikszer. Ellenben ha valakinek valamilyen okból a minél kisebb telepítőcsomag elkészítése a célja, akkor könnyű kigyilkolni olyan összetevőket, amelyek nélkülözhetetlenek.
Jó, ha tudjuk, hogy vannak olyan Windows összetevők, amelyeket a két program képes sebészeti úton eltávolítani - arra azonban nincs mód, hogy azt a telepített rendszerbe visszaépítsük! Éppen ezért érdemes valahogy kipróbálni a végeredményt, hogy minden működik-e, mielőtt élesben is bevetnénk. A vLite kicsit kényelmetlen sajátossága, hogy minden változtatást külön jóvá kell hagyatni a programmal, hogy azokat végre is hajtsa. Ez az "Alkalmaz" (Apply) gomb gyakori nyomkodását jelenti, és az ember hajlamos ezt elfelejteni. Az nLite és vLite két remek alkalmazás, és még ingyenesek is. A kezelésükhöz nem kell pilótavizsga, az nLite pedig egyenesen hiánypótló mű!
Forrás: Computerworld
Intel® Remote Management Module
Ahogy egy cég infrastruktúrája nő, úgy nő a terhelés a már egyébként is túlterhelt IT személyzeten. Ez különösen igaz a földrajzilag szétterjedt környezetekre. A több épületben vagy távoli helyeken dolgozó dedikált, helyszíni adminisztrátorok szükségessége nagyon gazdaságtalan lehet. A szerverek erőforrásainak közvetlen elérése azonban kritikus annak biztosítása érdekében, hogy a rendszerek optimálisan működjenek és bármilyen felmerülő kérdésre azonnal megoldást lehessen találni.
Az Intel bemutatta az Intel® Remote Management Module-t (RMM), mely segít maximalizálni az IT adminisztrátorok hatékonyságát. Az Intel RMM távoli szerver felügyeletet nyújt az IT személyzet számára, mely a cég méretétől függetlenül hatással lehet a szerver életciklusának szinte minden fázisában. Az Intel RMM használható a szerver telepítésekor, folyamatos termelés figyeléskor, és hibaelhárításkor, valamint szerver visszaállítás és karbantartás közben is. Az Intel RMM segítségével az adminisztrátorok biztonságosan hozzáférnek a teljes képernyős KVM tulajdonságokhoz. Hardver állapot megfigyelés, tökéletes teljesítmény szabályozás, és szoftver telepítés / karbantartás lehetséges anélkül, hogy a szervert bármikor megtekintené.
Szerver Állásidő Csökkentése
Felmerülő trendek felismerése és még gyorsabb reagálás.
Az Intel RMM lehetővé teszi szerver adminisztrátorok számára, hogy tudatosan megfigyeljék a szerver állapotát és segít felismerni a felmerülő trendeket, mielőtt a szerver leáll. 24/7 hozzáférést nyútjva, az Intel RMM lehetővé teszi az IT szakemberek számára, hogy szinte bárhonnan hibaelhárítást végezzenek és gyorsan reagáljanak – még olyan esetekben is, amikor az operációs rendszer omlott össze. Mivel az Intel RMM támogatja a távoli szerver hozzáférést, az IT szakértelmet egy helyen lehet központosítani és még hatékonyabban felhasználni.
Szerver Felügyeleti Költségek Csökkentése
Könnyű integrálás más Intel Szerver Termékekkel lehetővé teszi a tökéletes távoli hozzáférést és csökkenti az utazási időt és költségeket.
Az Intel RMM, egy földrajzilag szétterjedt környezetben, a szerver felügyelettel kapcsolatos adminisztratív személyzet és utazási költségek csökkentésével segíthet csökkenteni a szerver felügyeleti költségeket. A teljes távoli KVM funkcionalitás lehetővé teszi IT adminisztrátorok számára, hogy „kinyúljanak” és a távolból irányítsanak egy szervert, mintha a távoli üzlethelyen ülnének egy helyi billentyűzettel, egérrel és monitorral. A KVM (Kezboard, Video, Mouse) folyamat közben az adminisztrátorok helyileg csatlakoztatott USB egységeket is használhatnak a szükséges szoftverek és frissítések feltöltésére a távolból irányított szerverre. Akár az operációs rendszert is újra lehet tölteni anélkül, hogy a szervert bármikor megtekintené.
Könnyű Telepítés és Használat
Könnyen telepíthető, szabvány-alapú szerver kezelés.
Az Intel RMM másodpercek alatt települ válogatott Intel® szerver alaplapok dedikált portjaira, felszabadítva a kulcsfontosságú bővítő csatlakozóhelyeket más alkalmazások számára. Telepítés után a kártya saját dedikált IP címét használja. Emellett az Intel RMM távoli KVM hozzáférést nyújt biztonságos (SSL) csatlakozáson keresztül sokféle támogatott böngészővel. A telepítés egyszerű: a kártya csatlakoztatása, a szerver elindítása, a böngésző megfelelő IP címre irányítása, és belépés. Végül az Intel RMM könnyen beépül kiegészítő szerver felügyeleti szoftvert - pl. az Intel® System Management Software-t - használó környezetbe.
Az Intel® Remote Management Module tulajdonságai és előnyei
Távoli KVM: teljes billentyűzet, egér és videó hozzáférést nyújt a szerverhez a hálózaton.
Virtual Media Redirection – lehetővé teszi a távoli OS és / vagy szoftvertelepítést és karbantartást, hozzáférést a helyileg csatlakoztatott USB eszközökhöz, mint pl. CD-ROM meghajtók és merevlemezek.
Dedikált Hálózati Kártya – Redundancia és sávszélesség szerint szegmentálja a felügyeleti forgalmat dedikált hálózatokra.
Beágyazott Webszerver – Az adminisztrátorokat, egy támogatott böngészővel, egy biztonságos SSL csatlakozással távoli szerverekhez csatlakoztatja, a rendszer állapotának megfigyelése és karbantartási feladatok ellátása céljából.
|
Szerver virtualizáció, első lépések
A virtualizációs technológiák megítélése korántsem egységes az informatikusok körében. Vannak, akik számára már teljesen természetes, hogy a felügyelt rendszereik egy része virtuális gép. Az óvatosabbak számára ez a technológia még inkább csak játék. A cikkel továbbgondolós játékra csábítom az utóbbi tábor tagjait is, bízva abban, hogy a technológián túlmutató érvek közül is találnak megfontolandót.
Csaknem két évvel ezelőtt jelent meg a TechNet Magazinban Lepenye Tamás kollégám Tervezz merészen! című cikke. Ajánlom mindenkinek újraolvasásra. Akármekkorát változott ugyanis időközben a virtualizációs technológia, a megközelítés, a konszolidációs feladat megvalósítására alkalmazott módszer a mai napig megállja a helyét. Talán csak annyi változott, hogy megjelentek olyan alkalmazások, amelyekkel kevesebb fáradsággal, rendszerezett és jobban használható adatokat gyűjthetünk a konszolidálásra jelölt rendszerekről. Amikor pedig nekivágunk a feladatnak, akkor használhatjuk például a System Center Virtual Machine Manager-t, hogy fizikai gépeinket virtuális gépekké konvertáljuk. No, de ne szaladjunk ennyire előre! Haladjunk nagyjából abban a sorrendben, ahogy konszolidációs folyamat halad!
Ha szerverkonszolidációra adjuk a fejünket, készüljünk fel arra, hogy hosszú ideig nem fogunk tudni látványos technológiai fejlesztéseket felmutatni. Ez a folyamat ugyanis hosszadalmas és gyakran nehézkes tervező-szervező munkával kezdődik. Legelsőként saját magunkban, illetve az IT-n belüli kollégák körében kell közös nevezőre, egységes álláspontra jutnunk a virtualizációt illetően. Tanulságos olvasmány a témában a Kusnetzky Group tanulmánya a virtualizációhoz kapcsolódó 10 legfontosabb mítoszról. Csak a négy legérdekesebb pontot emelném ki ezzel kapcsolatban:
- Az én cégem máris készen áll a virtualizáció alkalmazására
- Nincs szükség különösebb szakértelemre az implementációhoz
- Nincs szükség részletes tervezésre, minden megoldható néhány kattintással
- A virtualizáció csökkenti a rendszer komplexitását
A négy felvetett kérdést akár egymással összefüggésben is vizsgálhatjuk: a virtualizációs technológiák alkalmazása rövidtávon egészen biztosan nem csökkenti a rendszer komplexitását, hiszen teljesen új, korábban nem használt technológiai rétegek kerülnek a rendszerbe, amelyeket egyrészt meg kell ismernünk, másrészt a felügyeletükhöz szükséges folyamatokat ki kell fejlesztenünk és dokumentálnunk. Hosszabb távon jelentkezhet a komplexitás csökkenése, ha a virtualizáció egyfajta katalizátorként hat és ösztönöz bennünket a felügyeleti folyamatok pontosítására, jobb összehangolására és a lehető legtöbb feladat automatizálására. Ha többen dolgozunk az IT szervezetben, akkor szükséges lehet az egyes munkatársak feladatainak újragondolása és összehangolása is, hiszen a folyamatokat nekik kell végrehajtaniuk. Tehát igazából akkor állunk készen, ha az alapvető munkafolyamataink már rendben vannak, és van tartalék kapacitásunk a virtualizációs technológia bevezetésének idején jelentkező többletfeladatok elvégzésére.
Kiemelten figyeljünk erre, ha egymagunk vagyunk "az IT": mérjük fel, mennyi idő alatt, milyen kisebb lépéseken keresztül tudjuk elérni a kitűzött célt úgy, hogy közben nem hanyagoljuk el az élő rendszereket sem. Ezen a ponton máris a tervezésnél tartunk. Tervezni pedig kötelező! Mégpedig több irányban egyszerre. Mindenképpen szükség lesz egy pénzügyi tervre. Elég nagy a valószínűsége annak, hogy a konszolidációs folyamatot nem tudjuk véghezvinni pénzügyi befektetés nélkül, tehát feltétlenül meg kell győznünk azokat a döntéshozókat, akik finanszírozzák terveinket. Meggyőzésükhöz több helyről is gyűjthetünk érveket, néhány példát a következő fejezetben bemutatok.
A következő lépés a konszolidációs útiterv: milyen gépeket, szolgáltatásokat mozgatok virtuális platformra, milyen sorrendben, milyen módszerrel és mi tervem, ha valami nem sikerül (ez az a bizonyos gyakran elfelejtett roll-back plan). Ezen lépések tervezéséhez remekül használható a fentebb említett cikk. A tervezés másik vonulata a hosszabb távú tervezés: ha gondot okozott a fizikai szerverek túlzott elszaporodása (egyedi feladatokra, hosszabbtávú koncepció nélküli beszerzések), akkor mit fogunk kezdeni az elszaporodó virtuális gépekkel?
A virtuális gépek olcsók, nem lesz meg az a beépített korlát, amit a pénzügyi lehetőségek jelentettek a fizikai gépek beszerzésekor. Sőt, virtuális gépek esetén még a licencelés is egyszerűbb. Megvannak-e az eszközeink a hibriddé vált számítóközpontunk felügyeletére, van-e eljárásunk a licenckövetésre? Megfelelően nyilvántartjuk, dokumentáljuk-e virtuális tárolóinkat (storage) és hálózatainkat? Több olyan kérdés, amire megnyugtató megoldást kell találnunk és ez még mind mindig csak a tervezés.
A szakértelem kérdése talán a legegyszerűbb, ezen a területen van ugyanis talán a legnagyobb motiváló erő: a technológiai érdeklődés. Aki virtualizációs megoldás bevezetésére adja a fejét, azt már valamilyen mélységben megragadta a technológia és a benne rejlő lehetőség. Szerencsére az bevezetéshez szükséges eszközök használata nem túl bonyolult. A szakértelem kérdése sokkal inkább a tervezési és az üzemeltetés bevezetési fázisban nyer jelentőséget, ahol rendszer szinten kell gondolkodni a siker érdekében.
Hogy csak egyetlen üzemeltetési példát említsek: meg kell változtatnunk a javítócsomagok telepítésére vonatkozó eljárásainkat. A szokásos eljárás nagy valószínűséggel használható marad a virtuális gépek többségére és a virtualizációba nem bevont fizikai gépekre, a virtuális gépeket futtató szülő partíciók frissítése viszont jobban szervezett eljárást igényel, hiszen amikor ezeket frissítjük a rajtuk futó virtuális gépek szolgáltatásai is kiesnek. Ha technológiai szempontból nem is, de szervezési szempontból mindenképpen összetettebb a feladat. (Értjük már miért ajánlott a Windows Server 2008 Core telepítés, mint szülő partíció? Kevesebb frissítési ciklus, kevesebb fejfájás a szervezés körül.)
Nézzünk bele néhány fontosabb folyamatba, amivel a szerverkonszolidáció során találkozhatunk, és ismerkedjünk meg néhány olyan eszközzel, ami segíthet a kezdeti fázisok nehézségeit legyűrni.
Gondolkodjunk-e szerver-virtualizációról, ha egészen kis cégnél dolgozunk, ahol kiszolgálóból is esetleg csak egy van? Amikor először tettem fel magamnak a kérdést, akkor szinte azonnal rávágtam: nem. Ne erőltessünk egy megoldást ott, ahová nem való. Aztán feltámadt bennem a kisördög és arra gondoltam tervezzünk itt is merészen. Tegyük fel, van a vállalatunknál egy Small Business Server 2003 kiszolgálónk. Három-négy éve teszi a dolgát a sarokban, néha már bizonytalankodik a hardvere, fontolgatjuk a cseréjét, hiszen már a garanciája is rég lejárt.
Felmerül az igény, hogy szükség lenne egy másik gépre, például egy könyvelési vagy vállalatirányítási szoftver számára. Milyen megoldások közül választhatunk? Vásárolhatunk például két új belépő szintű szervert: a megszokott SBS-ünket átmigráljuk az egyikre, a pénzügyi szoftvert feltesszük a másikra. Nincs is ezzel a megoldással semmi baj, ha csak az nem, hogy a szép új processzoraink alig-alig dolgoznak 5% feletti teljesítményen. Ennél még a legelső gőzmozdonyok is jobb hatásfokkal működtek a XIX. század közepén.
Van más lehetőség? Gondoljunk egy merészet és mondjuk azt, hogy igen. Vásároljunk egy kicsit komolyabb szervert, de csak egyet. Ha jól választunk, a hardverköltségben még meg is takaríthatunk egy keveset. Célozzunk meg mondjuk egy négymagos processzort, 4 GB memóriát és néhány SATA csatolófelületű lemezt (legyen ebből több, mondjuk 2x80 GB és 4x250 GB) tartalmazó konfigurációt. Vegyünk hozzá egy Windows Server 2008 Standard Edition operációs rendszert a 64 bites szériából, ami tartalmazza a Hyper-V virtualizációs megoldást. Licencekkel máris rendben vagyunk, hiszen a Small Business Server 2003 licencünk megvan, a Windows Server 2008 pedig önmagán felül megenged egy további példányt, így a pénzügyi rendszerünk alá is megvan az operációs rendszer.
Egy virtuális kisvállalat sematikus felépítése
Mielőtt nekifognánk a rendszerek átszervezésének, készítsünk legalább egy vázlatot arról, hogy hová szeretnénk eljutni: lesz egy gazdagépünk két virtuális géppel, valahogy úgy, ahogy az ötödik ábrán látható. Ha már látjuk az alap struktúrát, kezdjük el az erőforrások elosztását. Induljunk természetesen a gazdagép operációs rendszerével, hiszen sok szempontból ez a komponens is csak egy előfizető a rendszer erőforrásaira. Ha nagyon bátrak vagyunk, telepíthetjük a Windows Server 2008-at Server Core telepítési opcióval, de ezt csak akkor vállaljuk fel, ha járatosak vagyunk ezen a területen és még a Hyper-V távoli (nem tartományi) felügyeletével is boldogulunk. (Ennek konfigurálása elég bonyolult, lásd a hivatkozott blog sorozatot.) Bátorságunk jutalma lehet a gazdagép kisebb erőforrásigénye és a kevesebb alkalmazandó frissítés. Akármelyik változatot is választjuk, a gazdagép operációs rendszerét telepítsük a 80 gigabájtos diszkekből kialakított RAID1 kötetre.
A virtuális gépek méretezését kezdjük a Small Business Server 2003 irányából. Az alap egy Windows Server 2003 R2, 32 bites architektúrával. A Hyper-V-ben rendelkezünk megfelelő integrációs komponensekkel, azt kell csak a kis rajzunkra felvezetni, hogy összesen két virtuális processzort adhatunk gépünkhöz. Memóriából valószínűleg most sem rendelkezünk két gigabájtnál többel, ennél több nem kell a virtuális gépünkbe sem. A lemezek konfigurációjánál több választási lehetőségünk van: létrehozhatunk egyetlen RAID5 kötetet vagy két RAID1 kötetet a rendelkezésre álló lemezekből.
A két külön kötet előnye, hogy az SBS így nem "közösködik" a pénzügyi alkalmazással, ha bármelyik virtuális gép intenzív lemez műveleteket végez, akkor legfeljebb a közös lemezvezérlő bizonyulhat szűk keresztmetszetnek. Az egyetlen nagyobb kötet viszont lehetőséget ad arra, hogy bármelyik gép tárolókapacitását növeljük szükség esetén a VHD fájlok kiterjesztésével. Hogy a virtualizált SBS kiszolgálónk nagy sebességgel érhesse el a neki szánt tárolókapacitást, most válasszuk azt a megoldást, hogy egy úgynevezett pass-through diszk formájában rendeljük a virtuális géphez a dedikált RAID1 kötetet. A pénzügyi alkalmazásunk virtuális gépéhez rendeljünk egy virtuális processzort és egy gigabájt memóriát. (A Windows Server 2008 operációs rendszerhez rendelhetnénk akár négy virtuális processzort is, de a kisvállalatoknál szokásos alkalmazásoknak általában nincs ekkora igényük, sőt csak ritkán képesek több processzort használni).
Adattárolásra használjunk rögzített méretű VHD állományt, mert ennek a teljesítménye alig marad el a fizikai diszkétől (többek között, mert a rögzített méret miatt nem töredezik). Az induló méret legyen 80 gigabájt, ez valószínűleg hosszabb időre elegendő lesz. A fennmaradó kapacitást szükség esetén mentésekre használhatjuk vagy akár újabb VHD állományt hozhatunk létre rajta és felcsatolhatjuk az SBS alá kiegészítő tárhelyként. A végső diszkkonfiguráció valahogy így alakulhat.
Tárkapacitás-optimalizálás kicsiben
A Small Business Server migrálása nem könnyű feladat, viszont könyvtárnyi az irodalma, csak keressünk rá néhány kulcsszóra az Interneten és már találunk is néhány alternatívát. Ha konzervatív (és biztonságos) utat szeretünk járni, akkor a migráció történhet egy biztonsági mentés visszatöltésével a virtuális gépbe vagy választhatjuk az úgynevezett "swing migration" technikát, amikor egy ideiglenes (pl. egy PC-n futó) gépet vonunk be ideiglenes tartományvezérlőként, amíg a virtuális gépben újratelepítjük az SBS-t. Vállalkozó szelleműek kísérletezhetnek blokkszintű lemezmásoló szoftverekkel is és átmásolhatják az SBS kiszolgáló diszkjének tartalmát a virtuális géphez rendelendő fizikai kötetre. Ez a megoldás akár működhet is, ha a másolás után a kötetet a virtuális gépünk IDE csatolójához rendeljük. A virtuális gép hardvere alapvetően szabványos, tehát van esélye annak, hogy a Plug&Play pótolja vagy lecseréli a hiányzó hardverkomponenseket és a gép elindul. Gondosan vigyázzunk viszont az SBS eredeti lemezére (lemezeire), hogy legyen visszatérési lehetőségünk, ha mégsem sikerülne a migráció.
A Hyper-V integrációs komponensek a megfelelő teljesítményhez mindenképpen kellenek, tehát ha a migráció sikeres (járjunk bármelyik úton) ezt a csomagot telepítenünk kell. Ezekkel a komponensekkel pedig már élvezhetjük a szintetikus hálózati csatoló és a többi szintetikus eszköz előnyeit és a VMBus nyújtotta gyors kommunikációs csatornát. A migrációhoz képest a pénzügyi rendszer "zöldmezős" telepítése már valóságos felüdülés lesz, viszonylag kevés hibalehetőséggel.
Forrás: Somogyi Csaba, Microsoft Magyarország
|
A hardveres RAID eszközök általában saját BIOS-vezérlőprogrammal, illetve saját konfigurációs programmal rendelkeznek. A diszkek konfigurálását, logikai diszkek létrehozását ezekkel a programokkal végezhetjük el. További előny, hogy így olyan operációs rendszerek alatt is használhatunk RAID megoldásokat, amelyek alapesetben
nem támogatják ezek használatát. (pl.: Windows XP). A RAID vezérlôk maszkolásának egy logikus következménye, hogy különféle alacsony szintű diszk kezelő és diagnosztikai programok nem érik el a diszket, illetve hibásan működhetnek. Külön figyelmet érdemel, hogy ebben az esetben a diszkek SMART adatai sem elérhetőek a diagnosztikai programok számára.
Ha bármilyen kérdése van, vagy konkrét és részletes árajánlatra lenne szüksége,
A szerver kiválasztásánál az egyik legfontosabb kérdés:
SATA, vagy SAS merevlemezek lesznek a szerverbe építve?
