Synology VMM Pro: Éles virtuális gép megfelelő méretezése mesterséges intelligenciával (2026)
A műhelyt futtató virtuális gép hónapokig kétszer annyi hardvert cipelt, mint amennyire szüksége volt. Nyolc virtuális CPU, tizenhat gigabájt memória, és egy olyan valós munkaterhelés, amely soha nem érte el mindkettő negyedét. Ez nem szokatlan. Az első napon nagylelkűen méretezzük a vendéggépet, mert fogalma sincs, mire lesz szüksége, a webhely működik, és senki sem tér vissza soha. Ez a cikk a visszatérés naplója. Ezt a vendéggépet négy vCPU-ra és nyolc gigabájtra csökkentettük Synology használatával. VMM Pro, egy MI asszisztenssel, aki a parancsértelmezőt vezette, és a tároló két perc hét másodpercig elérhetetlen volt. Maga az átméretezés az unalmas rész – két mező egy párbeszédpanelen. Az érdekes részek a mérés, amely bebizonyította, hogy nyolc gigabájt elég, a műveletek sorrendje, amely megakadályozza, hogy a vendég operációs rendszer kifogyjon a memóriából az első rendszerindításkor, és a pillanatkép, amely mindezt visszafordíthatóvá tette. Az VMM Pro mindegyiket olcsóvá teszi, és ez a valódi érv mellette.
SynoPower Club pont：A megfelelő méretezés a legkevésbé vonzó feladat az önkiszolgáló tárhelyszolgáltatásban, és ez hozza a legjobb megtérülést. Senki sem ír blogbejegyzést a visszaadott nyolc gigabájtról. De a túlméretezett vendéggépben tétlenül álló memória semmit sem takarít meg – egy Synology-n rögzítve van, így a gépen semmi más nem használhatja. Nyolc gigabájtot kaptunk vissza egy olyan hoston, amely kezdett megtelni, ami két további vendéget jelent, amihez már nem kell hardvert vennünk. Ami inkább biztonságossá tette, mintsem ijesztővé, az az alatta lévő VMM Pro volt: egy zárolt pillanatkép az első parancs előtt, és egy gép, amelyet kilencven másodperc alatt vissza tudtam állítani az eredeti állapotába, ha ezek közül bármelyik rosszul sült el. Nem sült el rosszul. De nélküle el sem kezdtem volna.
Tartalomjegyzék
Mi az Synology és VMM Pro?
Az Virtual Machine Manager az Synology hipervizor csomagja. A Csomagkezelési központból telepíthető, ingyenes, és egyetlen NAS-on gond nélkül futtat Linux, Windows és Virtual DSM vendég operációs rendszereket helyi pillanatképekkel. VMM Pro a fizetős frissítés, amely az egyetlen egységből álló hipervizort egy kis klaszterré alakítja: több NAS egység egyetlen készletként kezelhető, vendégek mozoghatnak közöttük, magas rendelkezésre állás és pillanatkép-replikáció egyik hosztról a másikra.
Ez a különbségtétel azért fontos a cikk szempontjából, mert a megfelelő méretezés kapacitásbeli döntés, és a kapacitás csak akkor válik érdekessé, ha egynél több gép van a csoportban. Egyetlen NAS-on a felszabadított memória az a memória, amely nem használatos az adott NAS-on. Egy VMM Pro klaszterben ez az a memória, amelyet egy másik gazdagép kölcsönözhet egy feladatátvétel során, vagy amelybe egy új vendég beépíthető anélkül, hogy bármit is vásárolna.
A Virtual DSM A vendég – egy teljes DSM telepítés virtuális gépként fut – az a munkaterhelés, amelyet itt átméreteztünk. Ez a Container Managert futtatja, amely a tároló mögötti két Docker konténert futtatja. Ez a rétegezés szándékos, és ez tette biztonságossá a munkát. A Docker-verem vendég rendszerek közötti mozgatását a következő részben tárgyaltuk: VDSM Docker migrációs útmutatónk; ez a cikk arról szól, hogyan lehet a vendéget alatta megfelelő méretűre állítani.
VMM Pro vs. az ingyenes kiadás: Mit vásárol valójában a frissítés?
Az ingyenes kiadás nem egy gyenge demó. Vendégélményt nyújt, pillanatképeket készít, és egyetlen NAS-hoz valóban mindent megad, amire a legtöbb embernek szüksége van. Amit megvásárolsz, az a következőket tartalmazza: VMM Pro nem egy vendég jellemzői, hanem a házigazdák jellemzői.
| Képesség | Ingyenes kiadás | VMM Pro |
|---|---|---|
| Vendég szerverek futtatása egyetlen NAS-on | Igen | Igen |
| Helyi pillanatképek | Igen | Igen |
| Több NAS egység egyetlen klaszterként | Nem | Igen |
| Vendég áthelyezése a házigazdák között | Nem | Igen |
| Magas rendelkezésre állású feladatátvétel | Nem | Igen |
| Pillanatképek replikálása egy másik gazdagépre | Nem | Igen |
Vásárlás előtt ellenőrizd a referenciákban linkelt hivatalos funkcióoldalt, mert az Synology módosította a DSM kiadások közötti kiadásfelosztást. A gyakorlati teszt egyszerűbb, mint a táblázat: ha van egy NAS-od, és boldogulsz a pillanatképből való kézi visszaállítással, az ingyenes kiadás rendben van. Abban a pillanatban, amikor van egy második NAS-od, és azt szeretnéd, hogy az első vendégei túléljék a halálát, akkor egy... VMM Pro licenc.
A klaszterünk három csomópontból áll, és ezek közül csak kettő van bekapcsolva a legtöbb időben. A harmadik egy hideg készenléti állapot, amely ütemterv szerint felébred, hogy replikált pillanatképeket kapjon, majd visszamegy alvó állapotba. Ez a minta – csak akkor fizess az áramért, amikor redundanciára van szükséged – egy VMM Pro minta, és ez az oka annak, hogy a konzol állandó figyelmeztetést jelenít meg egy olyan gazdagépről, amelyet nem tud elérni. A figyelmeztetés a működő terv, nem pedig a hiba.
Hogyan válik egy vendégprodukciós szereplő kétszer akkorává, mint amennyire szüksége lenne
Három dolog hajtja felfelé a vendégeket, és semmi sem taszítja őket vissza. Az első, hogy a kezdeti méret csak becslés, és egy nagylelkű becslés az első napon semmit sem kerül. A második, hogy minden incidens azzal végződik, hogy valaki megemeli a limitet. A mi esetünkben két memória-incidens is történt egy héten belül; mindkettőt úgy oldották meg, hogy több helyet adtak neki, és egyiket sem vizsgálták felül soha. A harmadik, hogy egy nyolcvan százalékos memória-kihasználtságot mutató irányítópult riasztóan néz ki, így senki sem jelentkezik önként, hogy elvenjen memóriát. Mindez nem VMM Pro probléma. Emberi probléma, és ezért a túlméretezett vendégek a norma.
Ez utóbbi a csapda, és érdemes világosan kimondani: a legtöbb ember rossz számot használ annak eldöntéséhez, hogy egy konténerben van-e hely. A mi esetünkben az adatbáziskonténer a korlátjának nyolcvanegy százalékánál volt. Nem így volt. Az ötödik szakasz teljes egészében arról szól, hogy miért, és arról a mérésről, amely az VMM Pro átméretezést biztonságos, nem pedig reményteljes döntéssé tette.
Élő vendég megfelelő méretezése VMM Pro-vel 4 lépésben
A teljes feladat négy lépésből áll, és csak a harmadik lépésben kapcsolják le az oldalt. A teljes állásidő számunkra két perc hét másodperc volt, a konténerek leállásától az első HTTP 200-ig mérve, miután a vendég visszatért. VMM Pro az első és a harmadik lépésben vesz részt; a középső lépés a vendég belsejében történik.
Készítsen egy zárolt pillanatképet, mielőtt bármi mást tenne
Készíts pillanatképet a vendéggépről az VMM Pro gépről, és jelöld meg zároltként, hogy az ütemezett pillanatkép-rotáció ne tudja törölni. Ez a visszavonás gomb minden további lépéshez, és az egész gépet rögzíti egyetlen mappa helyett. Adj hozzá egy leírást, amelyből kiderül, hogy mit fogsz csinálni, mert három hónap múlva az időbélyeg önmagában semmit sem fog jelenteni számodra.
Mérd, hogy mit használ valójában a munkaterhelés, ne azt, hogy mit jelent a műszerfal
Olvasd le az egyes konténerekben található cgroup memóriastatisztikákat, és válaszd szét az anonim memóriát az oldal gyorsítótárától. Csak az anonim memória nem igényelhető vissza, és csak ennek a számnak kellene meghatároznia a méretezést. Ellenőrizd az adatbázis pufferkészletét az adatbázis valós méretével. A miénkben egy három gigabájtos pufferkészlet volt egy hatszázhatvanhárom megabájtos adatbázis előtt.
Zsugorítsd össze a tartályokat, mielőtt a vendéget zsugorítanád össze
Először csökkentsd az alkalmazás és az adatbázis memóriakorlátjait, majd szinkronizáld ezeket az értékeket a compose fájlodba, hogy egy későbbi újraépítés ne vonja vissza őket. Egy olyan konténert, amelynek jelenlegi kihasználtsága már meghaladja az új korlátot, nem lehet egyszerűen korlátozni – változtasd meg a konfigurációját, és indítsd újra, hogy kisebb legyen, majd alkalmazd az alsó korlátot. Ha ezt a sorrendet rosszul csinálod, akkor az első rendszerindításkor memóriahiányos ciklust hozol létre.
A konténerek pontos leállítása, átméretezése és a beállítások helyett a viselkedés ellenőrzése
Állítsd le az adatbáziskonténert egy nagyvonalú időtúllépéssel, és erősítsd meg a tiszta leállítást a naplójában, hogy a vendég ne induljon el összeomlás utáni helyreállítási módban. Állítsd le a vendéget, állítsd be az új vCPU és memória értékeket az VMM Pro-ben, majd kapcsold be újra. Ezután ellenőrizd, hogy mit érintenek meg a felhasználók: valódi oldalak adnak-e vissza 200-at, helyesek az árak, nincsenek-e memória-túllépési események – nem csak a párbeszédpanelen beírt számok.
Miért fogja lebeszélni a Docker statisztikái a helyes válaszról?
Az átméretezés előtt a konténer irányítópultja úgy nézett ki, mint egy gép, aminek nincs helye:
docker statisztika WordPress 2.51 GiB / 7 GiB (35.9%) WordPress-DB 3.25 GiB / 4 GiB (81.1%) <-- úgy tűnik, majdnem tele vanOlvasd el ezt, és arra a következtetésre jutsz, hogy az adatbázisnak szüksége van a négy gigabájtjára, és a vendég nem mehet tizenkettő alá. Mindkét következtetés téves, mivel az eszközök által jelentett memóriahasználat magában foglalja az oldal gyorsítótárát is, és az oldal gyorsítótár automatikusan visszanyerhető, amint valami másnak szüksége van a memóriára. Az a szám, amely eldönti, hogy memória-elégtelenség miatti kill-t kapsz-e, az anonim memória. Olvasd el közvetlenül:
docker végrehajtó sh -c 'awk "/^(cache|rss) /{printf "%-8s %8.0f MBn", $1, $2/1048576}" /sys/fs/cgroup/memory/memory.stat' WordPress rss 1305 MB gyorsítótár 1609 MB WordPress-DB rss 2553 MB gyorsítótár 1543 MBMost a kép megfordul. Az alkalmazáskonténer valóban 1,3 GB-ot használ, nem 2,5 GB-ot. És ebből az 1,3 GB-ból 768 MB egyetlen megosztott opcode gyorsítótár, amelyet minden munkafolyamat leképez, nem pedig lemásol – tehát húsz munkafolyamat fejenként nagyjából huszonhét megabájtba került, nem pedig a kétszázötven megabájtba, amit egy naiv folyamatmemória-összeg sugall. Az adatbázis 2,5 GB-ja szinte teljes egészében egy három gigabájtos pufferkészlet volt egy 663 MB-os adatbázishoz.
Még egy csapda ugyanebben a családban: a történelmi csúcsszámláló boldogan mutatja a felső határt elérő konténert, mivel ez a számláló tartalmazza az oldal gyorsítótárát is. Mindkettőnknek volt ilyen. Egyikünket sem ölték meg soha memóriahiány miatt. A memóriahiány számlálót ellenőrizd, ne a csúcsértéket.
Ezzel a két ténnyel a nyolc gigabájt már nem volt kockázatos szám. A pufferkészlet egy gigabájtra csökkentése – ami még mindig kényelmesen nagyobb, mint a teljes adatbázis – több valós memóriát szabadított fel, mint amennyi átméretezésre szükség volt. A végül az VMM Pro-be beírt számot már a vendég szerver leállítása előtt bebizonyítottuk.
Hogyan használja egy kis csapat az VMM Pro-t egy egész szerver visszaszerzésére?
Egy Synology vendéggép memóriája fixált. A hipervizor zárolja és előre lefoglalja, ami azt jelenti, hogy nem lehet túljelentkezni rá, ahogyan néhány más platformon lehetséges. Tizenhat gigabájt, ami egy vendéggépnek van kiosztva, tizenhat gigabájt, amivel más vendég nem rendelkezhet, akár foglalt, akár tétlen. Ez a korlátozás teszi érdemessé a megfelelő méretezést a következőn: VMM Pro Konkrétan: a memória felszabadítása az egyetlen módja a kapacitásnövelésnek egy NAS megvásárlásán kívül.
Nyolc gigabájt tért vissza egy 46,83 GB-os hoszton. Az elérhető memória nagyjából huszonkét gigabájtról 30,29 GB-ra csökkent. A gyakorlatban ez két további vendéggépet jelent, ami megegyezik a miénkkel, pusztán mérésekből létrehozva. Egy háromcsomópontos fürtön ez azt is jelenti, hogy a túlélő hosztoknak nagyobb mozgásterük van ahhoz, hogy elnyeljék egy meghibásodó csomópont vendéggépeit, ami az VMM Pro kifizetésének lényege.
A CPU oldal ugyanezt nyíltabban fogalmazta meg. A vendéggép nyolc virtuális CPU-val rendelkezett, és nyugalmi állapotban egy mag körülbelül hatodát használta. A négy nem volt kompromisszum; négy még mindig bőséges, és az VMM Pro egyetlen mezőben alkalmazta. Az átméretezés óta a vendéggép átlagos terhelése 1,36 négy vCPU-val szemben, ami nagyjából a nap legforgalmasabb szakaszában a kihasználtság egyharmadát teszi ki.
A műveletek sorrendje, amely megakadályozza a rendszerindítási idő miatti memória-túllépési ciklust
Ez az a rész, amit könnyű elrontani, és amit drága elrontani. A konténer memóriakorlátai és a vendégmemória, amit az VMM Pro-ben állítasz be, két különálló felső határérték, és ha a konténerkorlátok összege meghaladja a vendégmemóriát, akkor jelezted a konténereknek, hogy többet használhatnak, mint amennyivel a gép rendelkezik. Terhelés alatt a kernel úgy oldja fel ezt az eltérést, hogy valamit leállít.
A változtatás előtti korlátunk hét gigabájt volt az alkalmazáskonténer és négy az adatbázis számára – tizenegy gigabájt egy tizenhat gigabájtos vendéggépen, ami rendben volt. Egy nyolc gigabájtos vendéggépen ez egy olyan incidens lett volna, amely az első forgalmi csúcsra várt volna. Tehát a konténereknek kellett először leállniuk:
| Beállítás | Előtt | Után |
|---|---|---|
| Vendég | 8 vCPU / 16 GB | 4 vCPU / 8 GB |
| Alkalmazástároló korlátja | 7168 MB | 4096 MB |
| Adatbázis-tároló korlátja | 4096 MB | 2048 MB |
| Adatbázis pufferkészlet | 3 GB | 1 GB |
| Adatbázis kapcsolatok maximális száma | 300 | 100 |
| Apache munkás mennyezet | 50 | 35 |
Egy másodrendű szabály rejtőzik abban a táblázatban. Nem csökkentheted egy konténer memóriakorlátját a jelenleg használt szint alá, és nem várhatod el a kerneltől, hogy udvariasan reagáljon erre. Az alkalmazáskonténer kevesebbet használt, mint az új korlát, ezért élőben korlátozták újraindítás és leállás nélkül. Az adatbáziskonténer többet használt, ezért a pufferkészletét újra kellett konfigurálni, és először újra kellett indítani a konténert; csak ezután lehetett alkalmazni az alsó korlátot. Ezek közül a lépések közül egyik sem történik meg az VMM Pro verzióban – mindkettőt be kell fejezni, mielőtt megnyitnád az átméretezési párbeszédpanelt.
A munkavállalói korlát az egész folyamat egyetlen valódi költsége, és érdemes kimondani, ahelyett, hogy eltemetnénk. Az alkalmazáskonténer hét gigabájtról négyre csökkentése azt jelenti, hogy kevesebb egyidejű kérés lehet folyamatban: ötvenről harmincötre, ami harminc százalékos csökkenést jelent a párhuzamos kérések csúcsidejében. A webhely nap mint nap tizenegy munkavállalót futtat, így semmi sem változott. Egy reklámhullám alatt előfordulhat. Ezt a cserét tudatosan végeztük, és leírjuk, hogy a következő személy ne fedezze fel újra egy kiesés során.
Mit csinált valójában a mesterséges intelligencia asszisztens, és hol hibázott?
Az asszisztens elvégezte a türelmet jutalmazó részeket: pillanatképet készített az VMM Pro-ről, mielőtt bármihez is hozzányúlt volna, a dashboard helyett a cgroup statisztikáit olvasta, kiszámolta a konténerkorlátok rendezési korlátját, és az eredményt valódi oldalak lekérésével és annak ellenőrzésével igazolta, hogy az árak továbbra is a megfelelő pénznemben jelennek meg. Ez talán negyven percnyi gondos munka néhány percbe sűrítve, és valóban hasznos.
Egyetlen alkalommal háromszor is hibázott, ami a történet hasznosabb fele.
- Tíz gigabájtot ajánlott, miközben a tulajdonos nyolcat kért. A tulajdonosnak igaza volt – de csak azért, mert a túlméretezett pufferkészletet is ezzel egy időben javították. Az asszisztens előtt ott volt a mérési eredmény, és továbbra is a biztonságosabb számon alapult.
- Átnevezte a vendéget, olvassa el
siker: igazaz API-ból, és az átnevezést készként jelentette. Nem volt átnevezve. Az általa használt átnevezési mező azonosítja a vendéget, nem pedig azt, amelyik megváltoztatja a nevét, és az API minden esetben sikert ad vissza. - Látott egy VMM Pro klasztert, amely egy elérhetetlen gazdagépre figyelmeztetett, és leromlott állapotú feladatátvételi útvonalként jelölte meg. A gazdagép egy hideg tartalék állapotú volt, amelyet szándékosan kikapcsoltak. A riasztás már hónapok óta ott volt szándékosan.
Mindhárom esetben ugyanaz a minta: magabiztos kimenet egy hihető ellenőrzésből. A ténylegesen fontos védőkorlátok ezért nem túl szépek. A pillanatképet minden alkalommal az első parancs előtt készítsd el, ne pedig a kockázatos parancs előtt. Soha ne fogadj el visszatérési értéket bizonyítékként – olvasd vissza az állapotot, és nézd meg a módosítani kívánt mezőt. És a viselkedést ellenőrizd, ne a beállításokat: egy betöltő oldal és egy helyes ár felülmúlja a nullával megegyező számú megerősítést, amely szerint egy parancs kilépett.
Mindez nem kifejezetten a mesterséges intelligenciára vonatkozik. Ugyanaz a fegyelem, amit egy root hozzáféréssel rendelkező új kollégától várnánk el, aki gyors, fáradhatatlan, és időnként biztos valamiben, ami nem igaz.
Hol találhat további hivatalos forrásokat?
Három videó, ami megéri az időt, mielőtt bármit is átméreteznél az VMM Pro-vel. Az első a csomag legjobb áttekintése; a másik kettő a vendégprogramok létrehozását és licencelését tárgyalja, amivel a legtöbben elsőre elakadnak.
Korlátok, amiket tudnod kell, mielőtt megbízol az VMM Pro-ben a gyártással
A memóriát nem lehet túllicitálni. Minden egyes hozzárendelt gigabájt el van zárva a NAS összes többi adatától, függetlenül attól, hogy foglalt-e vagy sem. Ez az a korlát, ami értékessé teszi a megfelelő méretezést, és ez az oka annak is, hogy az első napon egy nagylelkű becslés drágább itt, mint azokon a platformokon, amelyek lehetővé teszik a túllicitálást.
A memória csökkentése újraindítást igényel, mivel az VMM Pro nem vesz el memóriát egy futó vendéggéptől. Egy virtuális lemez bővítése élőben történik, ahogy bizonyos erőforrások bővítése is, de a memória elvétele a vendéggép leállítását jelenti. Tervezzen be egy rövid leállást, és ütemezze be; két perc is elérhető, de nem nulla.
A virtuális lemezek növekednek és soha nem zsugorodnak. Ha a memória helyett a tárhelyet osztod ki túl, VMM Pro nem adom vissza. Az egyetlen út egy új vendégház építése és abba való migrálás, ami sokkal hosszabb délutánt vesz igénybe, mint ez volt.
A konténereken belüli CPU-korlátok egyáltalán nem biztos, hogy működnek. Ezen a vendég szerveren a kernelnek nincs CFS sávszélesség-szabályozása, így a konténer CPU-kvótáit a rendszer elutasítja – és ami még rosszabb, ha egy parancsban memóriakorlátként próbáljuk beállítani őket, az egész parancs csendben meghiúsul. A memóriakorlátok és az alkalmazás saját munkavégzői korlátja az egyetlen elérhető CPU-védelem.
A pillanatkép nem biztonsági mentés. Ugyanazon a gépen és ugyanazon a tárolókészleten található, mint a védett vendéggép. Az VMM Pro képes replikálni a pillanatképeket egy közelebbi gépre, de egy épülettüzet továbbra is az adatok külső helyszínen tárolt biztonsági mentése él túl.
Végül figyeld meg, mit mutat a konzol. A konténer részletes oldalai egyszerű szövegként jelenítik meg a környezeti változókat, az adatbázis jelszavakkal együtt. Ez inkább a Docker őszinteségét mutatja, mint a csomag hibáját, de azt jelenti, hogy egyetlen képernyőkép a rossz oldalról közzétesz egy hitelesítő adatot. Ha ez zavar – zavarnia kellene –, helyezd át a titkokat egy fájlba, amelyet a konténer beolvas, ahelyett, hogy változóként adná át őket.
Hivatkozások
- SynoPower Club, az Synology NAS útmutatóink és kameráink ismertetői
- Synology — Virtual Machine Manager, a hivatalos funkció- és kiadás-összehasonlítás
- Synology Tudásközpont — Virtual Machine Manager súgó, vendégbeállítások és klaszterbeállítás
- Docker — docker konténer frissítés, egy futó konténer memóriakorlátjának módosítása
- Apache — MaxRequestWorkers, a hetedik szakaszban tárgyalt munkavállalói felső határ
Gyakran Ismételt Kérdések
Megéri az VMM Pro egyetlen NAS-ért?
Valószínűleg nem. Az Virtual Machine Manager ingyenes, és az ingyenes kiadás éles vendéggépeket futtat helyi pillanatképekkel egyetlen gépen. Az VMM Pro megtérül, ha van egy második NAS-od, és azt szeretnéd, hogy a vendéggépek válthassanak a hosztok között, automatikusan átvegyék a feladatokat, vagy replikálják a pillanatképeiket a futtatott gépen kívüli másik helyre.
Leállás nélkül lecsökkenthetek egy Synology virtuális gépet?
Nem. A memória zárolva és előre lefoglalva van egy Synology hoszton, így az VMM Pro nem tudja élőben csökkenteni, és a vendéggépet le kell állítani. A mi gépünk két perc hét másodpercig elérhetetlen volt teljes egészében, beleértve az előzőleg végrehajtott tiszta adatbázis-leállítást is. Egy virtuális lemez bővítése ezzel szemben a vendéggép futása közben is megtörténik.
Hogyan tudom megállapítani, hogy egy konténernek mennyi memóriára van valójában szüksége?
Olvasd el a konténeren belüli cgroup memória statisztikákat, és az anonim memória adatot nézd, ne a monitorozó eszközök által jelentett teljes memóriamennyiséget. A teljes használat magában foglalja az oldal gyorsítótárát is, amelyet a kernel igény szerint visszanyer. Az adatbáziskonténerünk 3,25 GB-ot jelentett a 4 GB-os korlátból, de csak 2,55 GB visszanyerhetetlen memóriát tartalmazott, amelynek nagy része túlméretezett pufferkészlet volt.
Milyen sorrendben kell módosítanom a konténerkorlátokat és a vendégmemóriát?
Először a konténerek, csak utána a vendég – ne nyissa meg az VMM Pro átméretezési párbeszédpanelt, amíg a konténerkorlátok el nem telnek. Ha a konténerkorlátok összege meghaladja a vendég memóriáját, a vendég első indításkor elfogyhat a memóriából. Azt is vegye figyelembe, hogy egy olyan konténert, amely már az új korlátnál többet használ, nem lehet egyszerűen korlátozni: konfigurálja újra és indítsa újra, hogy kisebb legyen, majd csökkentse a korlátot.
Beleszámít a megőrzési időbe az VMM Pro-ben zárolt pillanatkép?
A zárolás mentesíti a pillanatképet az ütemezett rotáció alól, pontosan ezért van rá szükség egy ilyen módosítás előtt. Zárolás nélkül egy zsúfolt replikációs ütemterv csendben törölheti a visszaállítási pontot, amelyre támaszkodott, mielőtt megerősíthetné a módosítás biztonságosságát.
Biztonságos-e egy mesterséges intelligencia asszisztensnek átméretezni egy éles virtuális gépet?
Korlátokkal igen, és a korlátok nem bonyolultak. Készíts pillanatképet az első parancs előtt, ne pedig a kockázatos előtt. Követeld meg az állapot visszaolvasását a sikeres válasz helyett. A felhasználók által látható viselkedést ellenőrizd az imént írt beállítások helyett. Az asszisztensünk három hibát követett el egy munkamenet során, és mindegyiket elkapta az állapot visszaolvasása.
Mit spórolt meg valójában a megfelelő méretezés?
Nyolc gigabájt rögzített memória és négy virtuális CPU került vissza az VMM Pro hosztkészletbe, ami a rendelkezésre álló memóriát nagyjából huszonkét gigabájtról 30,29 GB-ra csökkentette a 46,83 GB-ból. Ez két további, az általunk üzemeltetett méretű vendéggépnek elegendő helyet biztosít, és nagyobb mozgásteret a klaszternek egy meghibásodott csomópont elnyelésére.
Futtatható a Docker az Virtual DSM-n, és a vendég átméretezése befolyásolja-e a konténereket?
Igen, egy Virtual DSM vendég egy teljes DSM telepítés, így a Container Manager pontosan úgy települ, mint egy fizikai NAS-on. A vendég átméretezése az VMM Pro-ben nem érinti magukat a konténereket, de a memóriakorlátjaik egy különálló felső határt jelentenek, amelyet le kell csökkenteni, hogy elférjenek a kisebb vendég számára, mielőtt csökkentenéd a méretét.