Hozzászólások
Hát, vzdump-nál maradok inkább, heti 4x 4 fizikailag is külön helyre.
- A hozzászóláshoz be kell jelentkezni
Azért a Veeam egy kicsit más kávéház.
Ahol vegyesen kell VMware, Hyper-V, fizikai szerverek és most akár még pluszban Proxmox infrát _is_ (pl. átmenet egy VMware -> Proxmox irányba akárcsak teszt jelleggel) üzemeltetni, ott kell egy közös nevező, amivel mindegyikbe belelátsz mentésileg és tudod is ipari standardok (CBT stb.) szerint menteni. Mivel ezek a mentőmegoldások nem két forintba kerülnek, nem biztos, hogy az az irány, hogy mindegyikből tartasz egyet. Ráadásul az adminisztrálásuk is több helyen csak az overhead-et növeli.
A Veeam eddig is a #1 mentési megoldás volt ilyen helyeken, de ezzel a lépéssel már jobban elhúzott a követőktől.
F1-es hasonlattal élve vezeti a futamot és a másodiknak adott fél kört.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Tudom, használunk Veeam-et, igaz már csak DR oldal kezeléséhez. Mielőtt nem migráltunk Netbackup-ra, akkor a Veeam-ről mentek az OS mentések is Vmware-en. Proxmoxaink már nagy sajnálatomra csak pár darab van, azok is infra sandbox gépek, melyeket simán vzdump-al mentjük.
Itthon szinte csak Proxmoxaim vannak, azokra tökéletes a vzdump, bár nagyon ajánlották a Proxmox Backup termékét is, ami nekem ágyúval verébre. Cégnél nem tervezik a Proxmox komolyabb bevetését, helyette kényszerből OLVM-et kell majd az Oracle szaroknak használni, többi vm pedig marad Vmware-en. Ezeknek közös nevezője nálunk mentés oldalról a Netbackup, melynek szintén meg van az oka, hogy miért lett lecserélve.
- A hozzászóláshoz be kell jelentkezni
Ezeknek közös nevezője nálunk mentés oldalról a Netbackup
Oracle miatt? A Veeam Oracle plugin-je nem volt elég?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ebből kimaradtam, mert a dbadminok és az architect-ek jutottak arra a döntésre, hogy átállnak. Szerintem a licensz ára volt inkább a döntő, egyszerűen a Netbackup olcsóbb. Illetve van egy nagy OVM clusterünk, állítólag az országban a legnagyobb, amit a Netbackup képes menteni meg snapshotolni. Ez manapság nem tűnhet nagy dolognak, de az OVM-et aki ismeri, az tudja, hogy mennyire elavult pusztulat... De a Netbackup kipróbáltan és üzembiztosan tudja menteni. Nem ez a tény volt szerintem a döntő, hanem mint említettem az ára.
- A hozzászóláshoz be kell jelentkezni
Hát, az OLVM legalább van, szemben a RedHat EV-vel, amit ugye beszántottak és kb. tesztpilótát csináltak a fizetős ügyfelekből mondván h. az OpenShift ezt is tudja. Jah. Kubevirt-hez tákoltak valamit az OKD nevű sz.rban, de kva messze van az enterprise virtualisation-től. Oracle legalább tartja a támogatott oVirt-et a termékpalettán.
Ahol azon túl is számít a dolog h. mennyire punk a megoldás (értsd licenselhetőség, support, stb.), ott az OLVM nem is olyan szar alternatíva, hiszen a sima OracleLinux supportban kapod a támogatást és nem kell még proxmoxot v. vmware-t is vásárolni.
- A hozzászóláshoz be kell jelentkezni
Nekem ez annyit mond (Proxmox Backup-ot használunk mindenhol jelenleg), hogy a Proxmox tényleg szintet lépett (üzletileg, ismertségben, stb.), és képbe kerül olyan cégeknél is, ahol a Veeam már jelen van, így igény jelentkezett a Veeam támogatásra. Nyilván nem a homelabberek kedvéért került bele ez a támogatás, hanem a fizetős ügyfelek igényei alapján. Szerintem ez jó dolog.
- A hozzászóláshoz be kell jelentkezni
Vagy a szükség nagy úr, ahol VMware megugró költségei miatt váltanának Proxmox-ra, ott hiányzott egy jó backup megoldás. Ezt látva a Veeam betöltötte a piaci rést.
Ez jó a Proxmox-nak is. Csak látva ezt el ne kurvuljanak. Mármint a Proxmox.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én azért drukkolok a Proxmoxnak, ez is előbbre viszi őket is. De jah, nem lenne baj ha ettől nem ereszkedne le a rózsaszín dollárfelhő a szemükre :)
- A hozzászóláshoz be kell jelentkezni
Sokan a Proxmox gyengéjének tartják, hogyha 2-3 gépes clustert akarnál, hogy ezeken fut a shared storage is, akkor erre nem ideális, production szinten. A Vmware Vmfs szintű megoldás nem volt régebben a Proxmoxhoz. Proxmox esetén a Ceph nem ideális 2-3 gépnél még mindig? Ott az Nfs vagy Drbd, ezekből vagy másból lett Vmfs szerű alternatíva már? Vagy van tervbe véve? Kérlek aki képben van ossza meg, hol tart ebből a szempontból a Proxmox a gyakorlatban. Hány gépes clustertől szokás élesben használni, shared storage használattal azonos gépeken? Vagy mi mást szoktak 2-3 gép esetén, ami free? Thx.
- A hozzászóláshoz be kell jelentkezni
Csak 3+ gépes cluster a támogatott (már ha a HA clusterre gondolsz) és a 2 gép amin még storage is van, azt én nem annyira nevezném production szintnek. Úgyhogy ez nem a gyengéje, csóróknak ott van a replikáció.
Asszem Trey szokta mondogatni, aki majmot akar, annak legyen pénze banánra.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
- A hozzászóláshoz be kell jelentkezni
Ceph 3 géptől működőképes érdemben, replikációval (ahogy a Proxmox HA is 3 géptől HA). Erasure Coding esetén (RAID 5-6-hoz tudnám hasonlítani a működést, jobb helykihasználás mint a replikációnál) 7 node az indulási alap.
Mi használunk élesben 3 éve egy 4 node-os Proxmox-Ceph HCI rendszert, eddig semmi baj nem volt vele. Pont nemrég írtam le valami bejegyzés alá, hogy az élő, futó rendszert futó VM-ekkel hogyan frissítettem Proxmox 6-7-8 és Ceph 15-16-17-18 verziókra, probléma mentesen. A mentése a kezdetektól Proxmox Backup Server, azzal sincs gond.
Természetesen a replikációs mód miatt a tároló kapacitás bukó óriási. De ez nem a Proxmox-ból vagy a Ceph-ből fakad, hanem a tárolási módból és az elvárt megbízhatóságból. Lehetne utóbbiból engedni, akkor több hasznos kapacitás maradna, de akkor minek a HA, ha a tárolónál elengedjük. Ugyan olyan megbízhatósággal szerintem más sem oldja meg kevesebből.
VMware vSAN-nal sajna nem tud összehasonlítani, olyanhoz sose volt közöm, csak szóló ESXi telepítésekhez.
Két géphez a legjobb támogatott megoldás a ZFS replikáció, ami ugye nem szinkron, nem adatvesztés-mentes a node kiesése.
Támogatja még a GlusterFS-t, de az meg nem az igazi VM-ek alá.
Lehet kézzel DRBD-t használni, de két gépnél hogy dől el, hogy ki halt meg? Két node nem HA.
- A hozzászóláshoz be kell jelentkezni
Nekem pont ez a bajom hogy az n+1 enterprise iSCSI storageon kb mehet a kukaba mert nincs tamogatott, production ready clusterfs proxmox ala ha blockdevicet hasznalsz. Kinomban mar a HyperV linux VM tamogatasat stressztesztelem.
- A hozzászóláshoz be kell jelentkezni
HyperV linux VM tamogatasat stressztesztelem
Hja, azt legalább támogatja az összes enterspájz backup megoldás.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Node minden ami debianva supportalt, az proxmoxba is az nem? Azokbol egy se volt jo megoldas neked?
- A hozzászóláshoz be kell jelentkezni
En meg varom A Dell NetWorker tamogatast, majd akkor elgondolodom rajta. A Veeam-et csak kis ,30-40 gepes infrakban hasznalunk, normalis, 7-800 gépes infrakban komolyabb cucc kell.
- A hozzászóláshoz be kell jelentkezni
Kinek mire van szüksége ....
Az 1 x 800 pont annyi, mint a 20 x 40 ....
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
2024.08.28-án jelent meg a v12.2, onnantól van egy félkész Proxmox VE támogatás.
Nagy volt a nyomás, gyorsan ki kellett adni, ezért félkész, még nincs benne Instant VM recovery, File level recovery, talán még Application aware backup sem, stb.
2024 decemberre ígérték a végleges változatot, amiben a fentiek is benne lesznek, de már ez is használható.
- A hozzászóláshoz be kell jelentkezni
Az kemény.
Mondjuk nem lepődök meg, pipa szintjén sok mindent állitanak veeam-ról, aztán a gyakorlatban egy vicc.
MSSQL támogatás. Úgy hirdetik, hogy full extrás backup rá. Helyette vagy a mentett gépről(!) magad ütemezel(!) be egy tök külön program által kihányt parancssort, ami felnyomja a repository-ba a mentést, amiről aztán veeam management oldalról semmit(!) nem tudsz, mintha ott se lenne, ill. ez is pár naponta szétesett, amikor a szerver is csinált egy full backup-ot a VM-ről, mert a diff backup nem tudta lekezelni.
Hogy mondjuk eldöglött az egész bohóc-mentés és talán kéne róla központi alert? Ugyan minek. Majd felmész szépen a mentendő szerverre és megnézed mi lett a parancssoros bohózatnak az errorlevelje(!), mivel mint mondtam a központi management semmit nem tud erről, hogy itt készülne egy adatbázis mentés, igy a hiányáról sem tud.
Vagy használod Veeam server oldalról a Guest process-t, mikor is annyit tudsz beállitani, hogy hány percenként hozza el a logokat és hogy törölje vagy ne a szerverről. Hogy melyik adatbázist? Ugyan már, uri huncutság, MINDET bzmeg, ami csak létezik a szerveren, akárhány instance, akárhány adatbázisát folyamatosan menti. Természetesen ugyanazzal a schedule-al, ugyanannyi ideig megtartva stb-stb.
És ez nem egy most kijött funkció, sok év alatt jutott el idáig.
- A hozzászóláshoz be kell jelentkezni
Hát ha a Veeam ennyit tud MSSQL terén, akkor ez egy rossz vicc. Ennyit még én is összerakok Powershellben / Bashben, ami NFS-re / S3-ra / Azure Backupba ment. Mondjuk az én szkriptjeim legalább értelmesen logolnak is és értesítést is küldenek.
- A hozzászóláshoz be kell jelentkezni
Én örülnék, ha valaki megcáfolna, hogy van normális támogatás, csak én nem találtam meg...
DPM-ről jöttem, ott természetes volt, hogy leküldöd az agent-et, megjelenik a szerver a management felületen, fastruktúrában ott látod az összes SQL instance-t, kivlasztod a mentendő adatbázist és egyenként úgy állitod be a mentési paramétereket ahogy akarod.
Gondoltam ez a minimum, de kiderült, hogy ez űrtechnika.
- A hozzászóláshoz be kell jelentkezni
Dell NetWorker Ugyanez. Agent fol es onnantol mindent a NetWorker UI rol kell csinalni. Ezert mondtam, h miniben el lehet bohockodni a Veeam el de nagyban nagyon gyenge...
- A hozzászóláshoz be kell jelentkezni
Szerintem ez még 1 gépes játékkörnyezetben is gáz.
- A hozzászóláshoz be kell jelentkezni
A veeam egy jo cucc, kis es kozepvallalkozasoknak, de komoly ipari kornyezetben csak egy vicc :)
- A hozzászóláshoz be kell jelentkezni
Nekem két kedvencem van a témában. Az egyik a natív Linux-os Veeam B&R, mióta az eszemet tudom azt nyomják a rendezvényeken és workshopokon, hogy de most már mindjárt itt van! (És ezt először 2010-ben hallottam :D).
A másik a rest API-juk, ami nem kezeli a tape és replication jobokat.
- A hozzászóláshoz be kell jelentkezni
Nekem még a most bevezetett 2FA is nagyon tetszik, mikor is TOTP-t is kér a management felület-re való bejelentkezésre, majd megláttam, hogy egy registry kulcs törlésével le is lehet róla beszélni. Ez aztán meggátolja a támadót :)
- A hozzászóláshoz be kell jelentkezni
MSSQL támogatás. Úgy hirdetik, hogy full extrás backup rá. Helyette vagy a mentett gépről(!) magad ütemezel(!) be egy tök külön program által kihányt parancssort, ami felnyomja a repository-ba a mentést, amiről aztán veeam management oldalról semmit(!) nem tudsz, mintha ott se lenne, ill. ez is pár naponta szétesett, amikor a szerver is csinált egy full backup-ot a VM-ről, mert a diff backup nem tudta lekezelni.
Plusz egy PostregSQL support is jól jönne, mert az általuk javasolt "Pre-Freeze and Post-Thaw Scripts" használata a konzisztens mentéshez is leginkább csak egy vicc.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
"Pre-Freeze and Post-Thaw Scripts" > ez pont annyira vicc, mint a VSS, ami miatt epp nem futott le napok ota az egyik mssql szerver veeam-es mentese :)
- A hozzászóláshoz be kell jelentkezni
Szerintem 10+ éve nem láttam VSS-related problémát, ott valami más probléma is lesz. Számtalan MSSQL-t mentek Veeam-mel, Barracuda Backup-pal, CA ArcServe-vel, Windows Backup-pal, megy szépen az összes hiba nélkül application-aware módban. A tranzakciós logok megfelelő truncate-je mellett, ofkoz.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
aha, persze, worksforyou, tudjuk :)
csak nezd meg az implementaciojat a vss-nek, kb. mindenki azt csinal amit akar. (egymasra tromfolnak a vss providerek, log 0, "something went wrong") :) tenyleg sokkal jobb, mint linuxon egy "random shellscript", FS snapshot, stb. :)
- A hozzászóláshoz be kell jelentkezni
Igen, láttam ilyet, olyan képzett üzemeltetőknél, akiknél az ajánlásokkal ellentétben nem célszerverek voltak, hanem egy szerverre összehányva minden:
- célszerver -> MSSQL szerver
- összehányt szerver -> egy helyen AD, EXCH, MSSQL (billió instance), Sharepoint, fájlszerver és még a holdkóros fasz is :D
Mondjuk ez kb. akkor szűnt meg, amikor a Microsoft is belátta, hogy az SBS terméke, ami ezeket role-okat egy szerverre (később min. kettőre) szórta fel, egy saját lábon lövés. A VSS writer-ek meg nem győzték követni a hülyeséget :D
Na, ez kb. 10+ évvel ezelőtt volt. Azóta nem nagyon láttam ilyen frankenszervereket. :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
semmi frank nem kell ehhez, csak tobb vss backend. amibol a win alapbol ad egyet, mssql megegyet, backup SW (veeam) megegyet, hypervisor pedig neha beszol, h haver, FS freeze! :) aztan jol osszeakadnak. itt konkretan csak egy koszos sql szerver van a gepen kb. 100G ram, parszaz GB DB. w2022, alig fel eves install. szoval a frankenszarozasod nagyon melle ment :) de good try! :D
reboot X ideig gyogyitja, ahol X randomgeneralt :)
- A hozzászóláshoz be kell jelentkezni
Ha esetleg nem menne, vagy segítség kellene, szólj nyugodtan, a srácok profik az ilyenekben, majd kitalálnak valamit a problémátokra 😊
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ha mar neked nem sikerult? pedig nagy volt a pofad! :D (es faszsag a feltetelezesed)
- A hozzászóláshoz be kell jelentkezni
Már mi nem sikerült? Nem tudlak követni 😏 Mi ez a durva hang? Segítséget ajánlottam. No, nem ingyen ... 😘
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
jajajajaja! kosz a helpet! mi is a help? a nagy lof*sz? :D
https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-an…
tudjuk milyen az effele segitseg :) MS is megmondta: shutdown. :D ez az ajanlott hivatalos gyartoi solution :D
addig meg nincs veeam mentes. ez van. ezet mentjuk storage alrendszer szinten is, ami ugyan nem konzisztens, a semminel viszont tobb. idonkent meg megy a dump.
hint: a vss ilyen (szar). valahol nem allithatsz meg csak ugy sqlservereket kedvedre karokozas nelkul... (7/24-es uzem) :D
- A hozzászóláshoz be kell jelentkezni
LOL mint említettem, SQL szerverek tucatjait mentem, legalább 4 megoldással, diszkre, szalagra, kötvetlen szalagra, CA agent-tel, Veeam agent-tel, Barracuda agent-rel, agent nêlkül, VSS writer-rel stb. gond nélkül.
Minden tetves nap, van amelyiket többször, több irányból. Pl. Barracuda telibe menti virt. gép szinten, majd az SQL agent-tel akár naponta többször, éjjel meg kipörög szalagra Veeam-mel, vagy CA-val ami offline ba megy kifele ...
Van olyan gép, amin 3 3rd party agent is fent van. Gond nélkül
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
jaja, nalad soha nem fordult elo == nem letezik :D ezert is van rola MS hivatalos fix: https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-an…
linkeltem is fentebb, csakhat neked nem kell azt tudni, mer' nalad mukodik! :D (itt is, amig eppen nem sikerul dupla 6-ost dobni a kockaval :D)
ms szerint es a tapasztalatok alapjan ossze szokott akadni, szerinted meg nem. eldonthetem azert kinek hiszek, ugye? :P :)
- A hozzászóláshoz be kell jelentkezni
Milyen meglepő a példában az SBS szó 😆😆😆
Pont ezekről a frankenmocskokról írtam feljebb, nahát!
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
csattints csak el egy veeam vss error guglikeresest, nezd a boldog sokadalmat! :D akiknel szinten osszeakad :) 8-10 eve is, meg azota is. \o/
semmivel nem masabb az SBS VSS-e, mint a veeam VSS-e [insert random vss provider here] ebbol a szempontbol. :) pont errol a fankenstein VSS-rol beszelek az elejetol fogva! nahat! :D
- A hozzászóláshoz be kell jelentkezni
Amint érinteni fog, nem keresést fogok elcsattintani, hanem egy ticket-et meg egy "hama' hama' sürge legyen meg a javítás", de mint mondtam, számtalan helyen használjuk, nem tapasztalunk ilyen hibát.
pont errol a fankenstein VSS-rol beszelek az elejetol fogva! nahat!
Én meg arról, hogy ott, ahol betartják az ajánlásokat és nem használnak SBS retkeket, ott ilyen probléma nincs. Nahát! Loop.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
jajajaja, tudjuk! :D mindenki mas helikopter! :D
- A hozzászóláshoz be kell jelentkezni
A konkrét hibáidat írd ide, amik a te rendszereden jelentkeztek. Tényleg kíváncsi vagyok rájuk. Teljes leírás mellett: milyen szerver, mik futnak rajta, hogyan van mentve, mivel van mentve, milyen időközönként, mi app-aware beállítások mellett, milyen load van a mentés idején stb. stb.
Ne a bohóckodást csináld :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
leirtam. osszeakad a vss, onnantol minden ilyen veeam vss request fail. neha, epp csak olyan suruseggel, hogy ne erje meg utanamenni, kidebugolni, ezzel baszakodni (megjavitani ugysem tudod, max. nem csinalsz vss menteseket, es/vagy kerulod az mssql maintenance taskokat).
nem veeamspecifikus a dolog (es ha mar itt tartunk igazabol nem is mssql, csak jellemzoen ott jon elo), ne is vard az o oldalukrol a javitast, ez az implementacio ilyen. vannak hibai. szolg. leallitas (lustabbaknak: reboot, ami kevesebb ido fenti rendes vason, mint ezt az egyebkent a csokott ertetlenseged vegett full ertelmetlen kommentet ideirni) javitja. lasd MS doksik, veeam [insert random vss backed backup sw here] forum/ticketek.
- A hozzászóláshoz be kell jelentkezni
a klasszik, 0x80042316. nem tudom mit ertetlenkedsz ezen :D mondom, keress ra. kibaszhatod a vss-t alola, ez a megoldas (csak az vinni fogja az mssql-t is). :)
eleg beszedes:
The flush and hold writes operation on volume \\?\Volume{####} timed out while waiting for a release writes command.
haladjunk tovabb :) faraszto, h nem akarod erteni.
- A hozzászóláshoz be kell jelentkezni
https://forums.veeam.com/vmware-vsphere-f24/volume-shadow-copy-service-…
A reagálások számából nem úgy tűnik, mintha ez egy széles körű, ismert probléma lenne. Szerinted, ha ez széles kört érintene, ennyi komment lenne?
https://www.backupassist.com/support/en/knowledgebase/BA917-Volume-Shad…
Ott vannak a lehetséges problémák és a megoldások ^
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
nekem mondod mit kell csinalni? mint mondtam mssql alol nem fogod kibaszni csak ugy a vss-t, akkor meg mar a reboot hamarabb megvan. :)
mar reg megvolt a reboot, a kov. x nap/het/honap/evben nem kell ezzel foglalkoznom :) x == random generated.
a "segitseged" ennyit is er LOL:
Re: Volume shadow copy service running at backup start causing error Code:0x80042316
Post by robns » Aug 18, 2024 9:19 am
Wow, is it a strain typing those three words? LOL.
- karsten123
- Service Provider
- Posts: 460
- Liked: 114 times
- Joined: Apr 03, 2019 6:53 am
- Full Name: Karsten Meja
- Contact:
Re: Volume shadow copy service running at backup start causing error Code:0x80042316
Post by karsten123 » Aug 18, 2024 12:35 pm
sure. no problem
- A hozzászóláshoz be kell jelentkezni
El is olvastad mit írt? Kb. azt, hogy rendes bugreportot szeretne látni.
:D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
jajajaja! vss error, please szalljkiszalljbe! :) ez tortent. az egyetlen szolgaltatast kell megallitani a gepen hozza.
a reboot hamarabb vegez. annyit nem er a kerdes, h kiadd, h vssadmin list writers, aztan elkezdd mazsolazni ki kicsoda.
aki talalkozott mar ezzel, tudja, hogy a fix: stop/start (hany kommenttel ezelott is mondam el? :D). haladjunk tovabb! :)
- A hozzászóláshoz be kell jelentkezni
Elmondtam:
Építesz egy célszervert, rá MSSQL (nem telebaszva mindennel is), lemented virt. gép szinten, app-aware bekapcsolva, ennyi kb. a MSSQL mentése.
Vagy mented agent-en keresztül, CBT driver-t is felteszed.
Ha ez mindeninél megrohadna, a termék kb. nem létezne egy év múlva.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
es ki a tokom mondta, h mindenkinel allandoan megrohad? ne farassz mar, direkt hulye vagy vagy mi van? :D
hint: random elojon X idonkent (lehet napok, lehet honapok telnek el) reboot 2 perc, vss debug (aminek a vege mssql stop/start) 10-vegtelen perc. valassz! :D
- A hozzászóláshoz be kell jelentkezni
Most már engem is érdekel.
- Milyen végpontvédelmi megoldás van azon az MSSQL szerveren?
- Hogy néz ki a diszk alrendszer? Full HDD? Full SSD? Netalán SAN bootos?
- A hozzászóláshoz be kell jelentkezni
- Milyen végpontvédelmi megoldás van azon az MSSQL szerveren? > irrelevans. az nem hasznal vss backendet.
- Hogy néz ki a diszk alrendszer? Full HDD? Full SSD? Netalán SAN bootos? > full ssd zfs pool, ami szinten irrelevans. a vm nem lat ki maga alol. ugyanigy random elszarodik, mikor ssd hwraid van alatta meg mikor network storage. meg mikor masik hypervisor "hajcsa". been there, done that.
- A hozzászóláshoz be kell jelentkezni
irrelevans. az nem hasznal vss backendet.
Láttam én már sok mindent összeakadni / leállni / összeomlani a "szuper" végpontvédelmi megoldás beállításai miatt.
full ssd zfs pool, ami szinten irrelevans. a vm nem lat ki maga alol.
Ez pusztán azért fontos, mert láttam már olyan rendszert, ahol az elfogyó IO rogyasztotta meg a VM-t. Hiába volt ZFS, hiába volt virtualizáció, a hiba tova terjedt a VM-ben futó alkalmazásokra is.
- A hozzászóláshoz be kell jelentkezni
tevuton jarsz, nem performancia bottleneck vagy obskurus viruskergetes.
elojon idonkent "mezei" desktopokon is, ahol sql backend van valami csudaszoftver alatt. :) azokrol csak hallomasbol ertesulok, nem nekem kell nyomkodni a restart gombot.
- A hozzászóláshoz be kell jelentkezni
Installált már valaki Proxmoxot (Entrerprise módon) HPE szerverre min. 2 HBA-val vagy Debian 12-vel 0 LUN(0 belső diszkkel)-ról bootolva(multipatht jól bekonfigurálva? :) ? Ha igen, hogyan :) Még a SLES/RedHaten se sikerül? :) Almalinuxon talán? Vannak az Enterprise Linuxokkal is gondok rendesen.
- A hozzászóláshoz be kell jelentkezni