Sziasztok,
Adott egy kis-közép cég 50 felhasználóval. 2 szerver (3 évesek).
1. - HP Proliant DL380G5 1x 4 magos CPU, 4 GB RAM, 3x146 Gb SAS Raid 5
- Oprendszer: Debian Linux
- Feladat: WMS adatbáziskezelés
- Kihasználtság: 10%
2. - HP Proliant DL380G5 1x 4 magos CPU, 6 GB RAM, 2x72 GB SAS Raid 1, 4x146 Gb SAS Raid 5
- Oprendszer Windows 2008 Enterprise
- Feladat: File, nyomtató szerver
- Kihasználtság: 25%
Adatmentést készítek LTO4-re.
Olyan megoldásban gondolkodom, hogy hardver hiba esetén 1 órán belül működő rendszert tudjak "varázsolni". Azaz a rendszer megbízhatóságát szeretném növelni. A meglévő szervereket is cserélném.
Keret: 2-3 Millió
Vennék két azonos szervert (két egymáshoz közeli épületben elhelyezve 50m), az egyikre VMware -t raknék és rátelepíteném a két virtuális szervert. Vennék bele 2x72 Gb SAS Raid 1, és 4x 300 GB SAS HDD-t Raid 5. A másikat meghagynám hideg tartaléknak HDD nélkül. Ha mondjuk az éles szerver alaplapja meghal akkor a HDD-ket kiszedném és átraknám a másikba. A hideg tartalék gép elindulna vele vagy az ESX felismerné, hogy megváltozott a hardver?
6-700 Gb tárhely elég lenne összesen.
Vagy inkább VMware HA clusterben kéne gondolkodnom? Biztos van jobb ötlet is.
Várom a véleményeket. Mebízható rendszerépítő cégek is érdekelnek. Köszi a segítséget!
- 2374 megtekintés
Hozzászólások
A diszk és/vagy raid fejreállást hogyan oldanád meg?
- A hozzászóláshoz be kell jelentkezni
Őö hát igen. Az ellen nem véd!:-) Előző napi mentésből? Ugrott az 1 óra.
Egyáltalán működne pl. alaplap vagy cpu hiba esetén a kézi átcipelés, elindítás?
- A hozzászóláshoz be kell jelentkezni
Működne, csak mindkét gépet azonos fw/sw és minden verzión kell tartanod. Ez egyébként a garinál is fontos.
- A hozzászóláshoz be kell jelentkezni
még azt se feltétlen. A HP-nál tudomásom szerintem kompatibilisek a driverek / raid-set-ek egymással. Azaz E200 vezérlőről is átrakhatod P400-ra.
Max a hálókártya MAC-je változik - ha ez zavar valakit.
ps: én esetleg azonos diskeket is vennék mindkét gépbe és DRBD-vel (v hasonló megoldással) tartanám szinkronban a háttértárat.
- A hozzászóláshoz be kell jelentkezni
HP gépekre tudsz venni 4 órán belüli garantált hibaelhárítást, diszkből meg spare-t. Ez nem egyszerűbb? Biztos megér ekkora ráfordítást egy elég alacsony valószínűségű probléma?
(Ilyenkor hoznak egy fullos gépet gyakorlatilag és ami rossz azt cserélik, tehát relatív tartható.)
- A hozzászóláshoz be kell jelentkezni
Jó veletek beszélgetni, mert ez véletlenül sem jutott volna eszembe. A Raid szétesés kikerülhető lenne 2 db 1 TB-os SAS HDD-vel RAID 1-ben. Gondolom ezzel jóval kevesebb hiba van mint a Raid 5-el.
A HP -nál 4 órás Care Pack 4 évre (munkanap 13 órában) 450.000. Valamit-valamiért.
- A hozzászóláshoz be kell jelentkezni
én 5-6 db 250-es diszket raknék bele raid 5-ben vagy 6-ban.
Ha virtualizálsz és esetleg később még több oprendszer kerül rá, akkor nem árt, ha IOPS-ban is tud valamit a rendszer.
Márpedig, ha ráérzel a virtualizáció ízére, akkor simán bejön oda hamarosan még egy pár oprendszer.
- A hozzászóláshoz be kell jelentkezni
Valszin olcsóbb mint egy másik tökolyan gépet venni. :) Ez a 450e elég soknak tűnik, szerintem adják azt olcsóbban is.
Diszkből a RAID5-re koncentrálj hotspare-el és hidegtartalékkal. A 4-5x300GB-os 10k-s vinyókból egész jókat lehet kihozni.
- A hozzászóláshoz be kell jelentkezni
-1
Én inkább vettem 2 db egyforma használt szervert, így nálam a javítás 1 percen belül megkezdődik. :)
Használt szerverekben hiszek, olyanokban ami jó helyen volt meghajtva így a gyári hibás alkatrészeket már az előző tulaj kicserélte, nekem pedig maradt a "gondtalan" üzemeltetés. cca 10++ éve így csinálom és nekem bejött, arról nem is beszélve, hogy sokkal olcsóbb így nekem. Persze nekem nem kell nagy számítási teljesítmény...
- A hozzászóláshoz be kell jelentkezni
3 éves gépnél is romolhat el nem mozgó alkatrész...
azt is számold bele, hogy a használt gép áramban majd' 2x annyit fogyaszt, szóval akár csak fogyasztás miatt is megérheti lecseréni a gépeket (főleg ha hostingban áram után külön fizetsz)
- A hozzászóláshoz be kell jelentkezni
Ez akkor megy, ha több gépet kell üzemeltetni, kettővel még nem biztos, hogy jó dolog. Ilyet én is csinálok egyébként. :)
A jelen helyzetben viszont adott keret van könnyen lehet, hogy a management (vagy aki elé a fenti projektet leteszik) igencsak csúnyán néz egy "hátvegyünkhasználtbólkettőt" szolúcióra.
Az adatvesztés ellen szintén kell védekezni, az egy másik része a dolognak. Egy raid vezérlő vagy akármilyen storage fejreálláson nem segít és nem is előzi meg a fenti gari nyilvánvalóan.
- A hozzászóláshoz be kell jelentkezni
a raid-ben széteshet a vezérlő, és még a backplane is (én pont így jártam most)
1 gépnél _talán_ megéri ilyet venni, két gépnél már szerintem nem.
(olcsóbb a 3. gépet megvenni, mint mindkét gépre egy ilyet)
persze abban az esetben, ha van, aki ki tudja cserélgetni a vasakat.
- A hozzászóláshoz be kell jelentkezni
Egy hasonlóval kísérletezem éppen.
Két openfiler HA clusterben ezek szolgáltatnák a storage-ot iscsi-vel a vmwarenek. Ha nem kell azonnal helyreállni akkor a vmware nem kell, hogy cluster legyen.
A két openfiler már megyeget és a drbd is sikrült, de a cluster managementet még tanulnom kell.
Kérdés:
Más is tapasztalta, hogy a linbitféle java GUI elrontja a drbd.conf-ot?
Nekem a global részből kiszedi a usage-count sort és ezért a szolgáltatás indításakor a script rákérdez amitől a crm behal.
(legalábbis most ez az elméletem, hogy a crm miért nem indítja el.)
- A hozzászóláshoz be kell jelentkezni
"Biztos van jobb ötlet is."
A VMware-nek van erre megoldasa, VMware Disaster Recovery-nek hivjak, de ez ide szerintem nagy lesz.
Mi az RPO?
"Mebízható rendszerépítő cégek is érdekelnek."
Ha VMware-ben gondolkozol, oket probald meg: netalfa.hu.
Szerk: esetleg nezd meg ezt meg ezt.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Ilyen kihasználtsági számok mellett szerintem adja magát a virtualizáció.
Megkockáztatom, hogy még a vasak is maradhatnak (Ezek azok? http://vb.net/products/HP/12477_div.html). Ha már veszel 4 HDDt(/gép) akkor RAID 10 nem lenne biztosabb megoldás. Diszk hiba esetén gyorsabban helyreáll ( http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt ).
Na és innentől jöhet bármilyen cluster, vagy szinkronizáció, vagy akármi, ami a két gépen a virtuális gépeket szinkronban tartja.
### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#N210/Xubu
- A hozzászóláshoz be kell jelentkezni
bruttó 350-400k között lehet kapni megfelelő szervert (pl. dell T110, 8GB ram, 1x Intel Xeon X3440 2 x500GB sata ennyi.)
Nettó 1 millió körül kapsz egy normális redundáns iSCSI storage-ot. (legyen mondjuk bruttó 1300k)
Ha a két épület között van normális gigabit hálózat, akkor midkét épületbe 1-1 szerver, az iscsi-t kiajánlani mindkettőnek, a vasakra vagy Vmware vagy (Citrix) Xen, és onnantól kezdve tetszőleges vason tudod futtatni bármelyik oprendszeredet. Xen abból a szempontból jobb, hogy az ingyenes verzió is tud live migration-t, amíg ez a feature a Vmware esetében ha jól tudom elég brutál ár.
2-300k-ból pedig meg lehet csinálni, hogy a szerverek között kábel és switch szinten redundáns legyen a hálózat.
Mielőtt még azt mondanád, hogy ok, de storage-ből csak egy van, azt mondom, hogy szerintem, ha kontroller szinten redundáns a dolog, akkor baromi kicsi az esélye, hogy bármi gond legyen vele. (Személy szerint jobban szeretem a brand, redundáns tárolókat, mint az occsóért pc-ből nagy szakértelemmel tákolt drbd-s megoldásokat.)
- A hozzászóláshoz be kell jelentkezni
+1 (+szunetmenetes a storage melle!...az sem olcso...)
+1 a regi vasaknak is! Elmennek azok hostkent is. (max kell bele + RAM esetleg + proci)
- A hozzászóláshoz be kell jelentkezni
Szimpatikus megoldás. A két épület között üvegszál van. Milyen iSCSI storage-ot tudsz ajánlani? IBM, DELL?
- A hozzászóláshoz be kell jelentkezni
Nem nagyon vagyok napi szinten képben ezekkel.
Pár hónapja egy Netapp storage-el szemezgettem saját magunknak, de érdemes megnézni melyik gyártó mit ajánl.
- A hozzászóláshoz be kell jelentkezni
"Mielőtt még azt mondanád, hogy ok, de storage-ből csak egy van, azt mondom, hogy szerintem, ha kontroller szinten redundáns a dolog, akkor baromi kicsi az esélye, hogy bármi gond legyen vele."
Akkor viszont DR szempontbol semmi ertelme kulon epuletbe tenni.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Ha leég égjen minden! :-) Világos hiszen az adatok a Storage-on van és abból csak egy van. Talán annyiból van értelme külön tenni mert ha leég az az épület amiben a storage van akkor a másikban marad egy gép és ha van mentésem a virtuális gépről és az adatokról akkor egy új storage-on viszonylag gyorsan helyre állítható a leégés előtti mentésből.
- A hozzászóláshoz be kell jelentkezni
ebben igazad van.
Bár az is lehet, hogy a két épületes dolog egyéb okok miatt van, és nem a DR miatt.
Csak a DR miatt külön szedni tényleg nincs értelme, csak akkor ha 2 storage is van.
De szerintem ez csak abban az esetben éri meg, ha gazdaságilag is indokolt (pl. 1 órányi állásidő legalább 1-200k kimutatható kárt okoz a cégnek)
Lehet esetleg két megfelelő szervert beállítani a két oldalra, és valamiféle drbd-vel tükrözött iscsi megoldást összerakni - hát hmm... van aki erre esküszik.
- A hozzászóláshoz be kell jelentkezni
A két épületes dolognak történelmi okai vannak. Régen csak 1 épület volt amiben volt egy szerver szobácska. Pár éve épült egy új amiben szintén van egy kis lik-luk. Mind a két épületben vannak felhasználók.
- A hozzászóláshoz be kell jelentkezni
Namost, azt ugye tudod, hogy a redundancia nem helyettesíti a backupot? Ergó az a kérdés, hogy backupból visszaállni mennyi az idő, ha mondjuk sérül a hiperredundáns fájlrendszer?
Én a helyedben lehet, hogy inkább azonnal indítható mentést csinálnék a másik gépre, mintsem hogy redundanciával kössem össze őket.
- A hozzászóláshoz be kell jelentkezni
"Adatmentést készítek LTO4-re." illetve "mert ha leég az az épület amiben a storage van akkor a másikban marad egy gép és ha van mentésem"
- A hozzászóláshoz be kell jelentkezni
Ez nem egyenértékű azzal, hogy olyan mentést csinál, amit egyből be tud bootolni. Apró, de adott esetben sok órát jelentő különbség.
- A hozzászóláshoz be kell jelentkezni
elég ritkán csinál olyan mentést az ember, ami több példányos, és bármelyikről azonnal tud bootolni.
Az olyan mentés meg túrót nem ér, ami csak egy példányos.
A mentésnek nem az a feladata, hogy egyből tudj bootolni belőle, hanem az, hogy megfelelő mennyiségű adat-duplikátummal rendelkezz, és megfelelő biztonsággal tetszőleges részét vissza tudd tölteni szükség esetén.
Ha másik gépen folyamatosan szinkronban tartasz egy darab állapotot, amit minden nap frissítesz és azért kellene visszatölteni egy mentést, mert mondjuk hónap végén derül ki, hogy Gizike hónap elején véletlenül kitörölt egy fontos könyvtárat, akkor cseszheted az azonnal bootolható "mentést".
Bármilyen kritikus rendszert is nézel, az adatok megléte mindig fontosabb a helyreállítási időnél.
- A hozzászóláshoz be kell jelentkezni
Nem vitatkozom, nem ugyanarról beszélünk. Magától értetődik, hogy rendszeresen kell egyéb mentést is csinálni a cuccról, de az a visszaállítás idejét masszívan le tudja csökkenteni egy teljes hardver crash esetén, ha van egy relatíve friss, bootolható másolatod az egészről, különben lehet az egészet visszamásolni a mentőgépről, ami sok fájlnál egészen sokáig el tud tartani.
- A hozzászóláshoz be kell jelentkezni
+1
van egy storage-ra használt gép durva kontrollerrel és drága lemezekkel, ezt folyamatosan lehetne replikálni egy olcsó, kevésbé redundáns (de főleg jóval gyengébb IOPS) gépre. vész esetén még el is tudhatsz onnan indulni.
- A hozzászóláshoz be kell jelentkezni
Én a helyedben valami host alapú replikációs megoldáson törném a fejem. Ajánlották a veeam céget. De ha vársz kicsit akkor jön az új ESX talán abban is lesz ilyen.
Ekkora környezetben a két storage nagyon elviheti a költségeket.
- A hozzászóláshoz be kell jelentkezni
En anno inkabb azt az utat valasztottam, hogy cfengine-nel telepitettem a gepeket (igy teljes es tokeletes dokumentacio is adott) es adatokat mentettem, replikaltam.
Ha valami nagy zur jott akkor felhuztam egy uj rendszert, cfengine megcsinalta a beallitasokat, aztan adat vissza es kesz.
Clusterezes meg automatikus failover az en esetemben tobb bonyodalmat okozott mint amit segitett.
Nyilvan feladat, adatmennyiseg, felhasznalas valogatja hol mi a jobb, neha az egyszerubb rendszer praktikusabb szerintem.
- A hozzászóláshoz be kell jelentkezni