redundáns storage letrehozása

Virtualizáció

Sziasztok

Van egy kb 3 éves rendszerünk 3 host, ami Vmware esxi-t futtat valamint egy EMC storage FC felett, valamint 10Gbps-es gerinc switch-ek. Lassan újabb tárhelyre lenne szükségünk, amire rendelkezésre áll kb 2 millió Ft keret, így megvizsgáltuk a lehetőségeinket, és a következőre jutottunk:
- EMC storage bővítés: kb 20 disk jönne ki, ha 900-as sas disk-ekkel számolunk, ez kb 13 TB helyet jelentene (raid, spare diskek, kerekítések figyelembe vételével), viszont a support költségek növekedését jelentené, és akkor "csak" SAS disk-ekről beszélnénk
- redundáns storage építése: a fizikai szerverekbe raknánk SSD meghajtókat. 3 hostba 6-6 disk férne be, amit ha 1TB-os ssd-vel számolunk, akkor beleférünk a keretbe. Ez esetben kb 7-8 TB tárhelyet és SSD disk sebességeket kapnánk SAS disk helyett.A második megoldással kapcsolatban szeretném kérni a segítségeteket, véleményeteket, javaslataitokat.
Amennyiben a fizikai szerverekbe tesszük az SSD-ket, akkor ahhoz, hogy a rendszerben a virtuális gépeket szabadon mozgathassuk, illetve egy host kiesését kibírja a rendszer adatok elérhetetlensége nélkül, akkor redundáns storage-ot kell a 3 hostból építeni.

Eddig a következő verziók jutottak eszünkbe:
Vmvare Virtual SAN : license díja miatt kiesett
Vmware vSphere Storage Appliance : essential plus kit license miatt használhatjuk, de csak vcenter mellé lehet telepíteni windows-ra, nekünk vcenter Appliance van, így ehhez új MS servert kellene telepíteni (szívesen elkerülnénk)
"Saját" megoldást "fejlesztünk" a problémára:
3 hostra 1-1 virtuális gépet teszünk, ami a gépben lévő local diskeket kezeli linux (Fedora) felett.
A 3 gép valamilyen megoldással, redundánsan tárolja az adatokat, majd ezeket a redundáns tárolókat valamilyen redundáns kapcsolatot használva elérhetővé tesszük a vmware felé (NFS/ISCSI), ami majd a virtuális gépek disk-jeit tárolja majd rajta.

Valahogy így:
,-------------ISCSI/NFS---------------------,
`--|HOST-6 disk| -- |VM drbd/gluster| --`
|
,--|HOST-6 disk| -- |VM drbd/gluster| --,
`-------------ISCSI/NFS-------------------`

Erre eddig két-három lehetőséget teszteltünk, ami eddig megvalósíthatónak tűnik:
-DRBD sync a 3 host között primary-primary módban, amit iscsi-n keresztül redundáns útvonalakon keresztül elér a vmware. Itt a tárolóhely vesztés csökkentése és a könnyebb konfig miatt a diskeket 2 csoportra osztva 1-1 másik gépre szinkronizálnának (Host 1 disk A-2B;2A-3B;3A-1B). Ez primary-primary módban redundáns iscsi útvonallal működőképes.
-Gluster(fs) segítségével vagy az előzőhöz hasonlóan elosztva az adatokat, vagy a 3 host felett Striped Replicated módban 1 nagy volume, amit a vmware NFS-el el tud érni. Az NFS sajnos nem támogat redundáns kapcsolatot, így e felett valamilyen cluster megoldással biztosítani kell, hogy egy ip-n folyamatosan elérhető legyen valamelyik host-on keresztül a volume. (Vmware-en akkor lehet azonos névvel felcsatolni a storage-ot, ha minden host-on a beállítás megegyezik, tehát nem tudjuk megtenni, hogy minden host-on a rajta futó disk kezelő rendszer ip-jével vesszük fel. Ha minden igaz csak így valósítható meg a vmotion.) Vagy a volume-on egy file-t létrehozva a file-t iscsi-n publikálva tesszük elérhetővé a kötetet (tesztek során ebben a megoldásban extrém lassú sebességeket mértünk).

Valakinek van-e jobb ötlete a probléma megoldására?
DRBD vagy Gluster(fs)?
ISCSI vagy NFS?
Kinek milyen tapasztalata van a fenti 4 technológiával kapcsolatban?
DRBD primary-primary megoldás tapasztalatok? Tesztes során sajnos többször sikerült egy szimpla újraindítással kizökkentenünk őket.
Ki melyiktől intene minket óva?
Szóba jöhet ebből az árból egy újabb storage, ami valóban redundáns (nem csak a disk)?
Vélemények, ötletek (építő jellegűek)?

Üdv

M

  • 8376 megtekintés

( _ventura_ v | 2016. 04. 16., szo – 07:45 )

Miért a hypervisoron kell local diskekkel mókázni ?

Akkor már venni használt vasakat és abba a diskeket rakni, így építeni redundáns "storage"-t

Fedora 23, Thinkpad x220

sub

Sokáig szemeztem a Dell EQL storage-okkal hasonló célra, az tud active-passive vasak közti redundanciát, de ebbe a keretbe használtan sem fér bele - hasonló ok miatt nálunk sem :/
Marad a használt szerver vasakból épített storage.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

nekem a Dell EQ-ról a lenti log jut a héten eszembe (ha valaki kiszúrná, hogy a fw régi, akkor ezúton jelzem, hogy a Dell support olyan segítőkész, hogy nem biztosít login-t hozzá... akárhogy levelezek velük, mert nem találják a rendszerükben sorozatszám alapján):

szerencsére nincs rajta semmilyen kritikus rendszer még.

437:129:groupname:SP:15-Apr-2016 11:38:46.785011:emm.c:2141:INFO:28.2.22:Dual control modules are now communicating properly.

439:131:groupname:SP:15-Apr-2016 11:38:46.785013:emm.c:1839:WARNING:28.3.51:Warning health conditions currently exist.
Correct these conditions before they affect array operation.
Control modules are initializing. Control module failover cannot occur until the initialization completes.
There are 1 outstanding health conditions. Correct these conditions before they affect array operation.

441:0:groupname:SP [secondary]:15-Apr-2016 11:38:31.010001:ppool_nvram.c:330:ERROR:15.4.1:NVRAM contains valid data. This is a PANIC RECOVERY due to a panic on CPU0.

443:1:groupname:SP [secondary]:15-Apr-2016 11:38:31.040002:ppool_nvram.c:185:ERROR:15.4.5:Saved CPU registers, CPU 0
at ffffffff80f50000 v0 0000000000000000 v1 000000000000003c
a0 ffffffff80924954 a1 000000000000fc01 a2 ffffffff806b0ee8 a3 ffffffff80f4dca0
t0 0000000000000000 t1 0000000016970746 t2 ffffffff804d48d0 t3 0000000000000000
t4 ffffffffd1a65b88 t5 ffffffffc0aa0000 t6 80551700000001f1 t7 59e7ca50c014b0f0
s0 0000000000000000 s1 ffffffffffff00fe s2 ffffffff80924954 s3 0000000000000372
s4 ffffffffffffffff s5 ffffffffffffffff s6 000000000016e360 s7 0000000000000400
t8 0000000000000000 t9 ffffffffe001b430 k0 ffffffff804d3e20 k1 0000000000000000
gp ffffffff80aa6190 sp c00d206800000000 s8 0000000000000001 ra ffffffff806b10b4

443:2:groupname:SP [secondary]:15-Apr-2016 11:38:31.060003:ppool_nvram.c:189:ERROR:15.4.6:Saved CP0 registers, CPU 0
sr 0000fc01 badva c011250c epc 806b15c4 errorepc bfc00000
cause 00000000 errctl 00000000 cacheeri 00000000 cacheerd 00000000
buserr 0000000000000000 cacheerrdpa 0000000000000000

447:3:groupname:SP [secondary]:15-Apr-2016 11:38:31.080004:ppool_nvram.c:195:ERROR:15.4.7:Saved function call stack, CPU 0
804c4f44 806b10b4 8067f3cc 804c2d90 804c2d10 804bfcec 804c3cf4 804d3eb4
806b15c4 804d47d0 00000000 00000000 00000000 00000000 00000000 00000000

447:5:groupname:SP [secondary]:15-Apr-2016 11:38:31.110006:eqllog_mbuf_Q.c:975:ERROR:2.4.0:Panic recovery from CPU0 with reason 'CPU1 (NP) timed out. Please triage the crash dump for cause'.

459:0:groupname:QRQ [secondary]:15-Apr-2016 11:38:32.684881:qrq.c:822:INFO:9.2.0:PS Series Array Firmware Version: Storage Array Firmware V4.3.0 (R106033)

512:133:groupname:SP:15-Apr-2016 11:38:51.505015:emm.c:2123:INFO:28.2.30:Control modules have completed initializing, and failover is now operational.

Nekem is ez jutott eszembe, legalabbis az utan hogy ugy gondoltad a local diszkek elereset atadod egy vm-nek es majd abban megoldani (gondolom mert vmware-el nem tudod megoldani ezt a hoston).
Ez igy szimplan az onsz*patas kategoria lesz, ha meg azt mondod a hoston csinalsz mondjuk glustert es onnan osztod ki a vm-eknek a tarhelyet az kezelheto kategoria, de drbd-t se ajanlanek storage szinkronra ha vm-ek is azokon futnanak.
En azt mondanam ahogy ventura is emlitette vagy hasznalt gepeket vegyetek kulon storage-nak, vagy valami hasznalt storage-ot redundans vezerlovel amibe teszitek az ssd-ket (felteve ha talalsz olyat ennyiert amibe ssd-t is tudsz tenni amit kezel), legalabbis ekkora keretbol kb ezt tudom elkepzelni hasznalhato szinten.

( freeoli v | 2016. 04. 16., szo – 08:12 )

Szerintem:

A: Gluster vagy CEPH, de az se nagyon jön ki belőle és ekkora kapacitásnál kérdéses a megtérülése, viszont bármiből építhető, de nem biztos, hogy túl sok fontosat tennék rá ha ekkora keretből kell megoldani.

B: Megkereslek levélben, de egy kisebb önálló Dell MD ami a legjobb lehet. Teljes mértékben integrálható az infrastruktúrába, különálló tároló nem plusz polc, stb.

( Mik v | 2016. 04. 16., szo – 09:01 )

A VSAN-nal jó irányba indultál el, de túl hamar megálltál a kereséssel...
A kifejezés amit keresel az a Hyper-Converged Storage. A vmware-en kívül van egypár vmware kompatibilis megoldás.
Hamár EMC: EMC ScaleIO. Ezzel kapcsolatban konkrét tapasztalat nincs, de a leírások alapján elég jónak tűnik.
HP StoreVirtual VSA. Ezt használjuk, bár MS környezetben, pont ugyanolyan jól működik mint a dedikált HW-en futó verziója.

Én ebbe az irányba indulnék elsőre, a DRDB és társai csak végső esetben. (bár a DRDB 9 állítólag elég jó lett)
Azon kívül, hogy helyet meg HA-t szeretnél nem sokat mondtál el a teljesítmény elvárásokról... A DRDB 8 tuti agyonüti az SSD-k teljesítményének jelentős részét. És ez szerintem az NFS-re és a Glusterre is igaz lehet.

Scale-IO-t akartam javasolni én is. Egy korábbi változatot teszteltem röviden, jópofa volt, de gyönge vasakon ment így teljesítményről nem tudok mit mondani. Ingyen kipróbálható és használható nem produktív környezetben. Ami már az ilyen rendszereknél előjött 10G Ethernettel kell megvalósítani. Érdekessége, hogy saját kliense és szervere van tehát nem iparági protokollt használ.

( macko003 | 2016. 04. 16., szo – 16:52 )

Köszönöm az ötleteket, jövő héten megpróbálom végignézni a felvetett alternatívákat.

Azért gondoltunk az esxi hostok bővítésére, mert habár 3 évesek, de vásárolunk rá garancia kiterjesztést, így azok működése biztosított. Van bennük disk hely, és nem hiszem, hogy nagy feladat lenne számukra.
Amennyiben használt vasakból raknánk össze (van 3-6 elfekvő régebbi szerverünk ami elbírná), akkor azok működését is biztosítani kellene, plusz helyet és energiát fogyasztana, de ez mellékes. Ezen felül a 2x1Gbps hálókártyát is bővíteni illene, ami kb 150-200e/szerver alap hangon.
Nem tudom hogy milyen előnnyel jár, ha fizikai vas látja el ezt a feladatot egy virtuális helyett.(?) Valamint pl a vmware álltal biztosított vsan és storage appliance is ezen az elven működik, csak ott a virtuális gép ki van hagyva és a hostok maguk intézik ezt.

"Nem tudom hogy milyen előnnyel jár, ha fizikai vas látja el ezt a feladatot egy virtuális helyett.(?)"

Nekem az nem tetszene, hogy a hypervisoron fut az a VPS ami a tobbi VPS-nek adja a disket. Ez nekem a jobb kezemmel vakarom a bal fülem. Körülményes, meg jobban elveszi az erőforrásokat is.

Ha storage akkor legyen külön.

Fedora 23, Thinkpad x220

( nvik | 2016. 04. 16., szo – 20:57 )

"ISCSI vagy NFS?"

Ehhez szólnék hozzá.
A VAAI miatt mindenképp iscsi. A multipath-ról nem is szólva.

Egyébként én inkább külön gépekre tenném a storage-t, akár DRBD akár CEPH akár FreeBSD HAST (két géppel - én ennek mennék neki, ki si jönne a keretből).
És iSCSI-n adnám storaget a vmware alá (a multipath és a VAAI miatt).

( bognarattila | 2016. 04. 16., szo – 22:47 )

Ha jól értem, az a mozgató rugó, hogy SSD-t használjatok. Egyik kérdés, hogy van-e erre szükség (van-e akkora teljesítmény igényetek, amihez SSD kell), másik kérdés, hogy mekkora többlet tárra van szükségetek. A két kérdés együttesen: ez a tárhely többlet megvalósítható-e SSD-vel (a megadott költség keretből, pláne redundáns nem redundáns tárolóval, azaz legalább 2x-es mennyiségű SSD-re van szükség).
Az sem mellékes, hogy mennyi "szabadidőtök" van játszani mindenfélével, az üzlet mennyire toleráns.

Ha alapvetően nincs szükségetek SSD-re (üzletileg nem támasztható alá), akkor felesleges az egész erőlködés, maradjatok az EMC tárolónál. Miért pont 900-as lemezt néztek, ha teljesítményre van szükség?

EMC tárolóba nem tudtok SSD-t tenni? Milyen típusú a tároló?

Redundáns tárolót nem igazán fogsz kapni SSD-vel 2M-ért.

Ha saját készítésű tárolót csinálsz, akkor legalább 6 SSD-t kellene venni (RAID1 + HS, mindez két gépbe) - ez talán belefér, de kb nulla kapacitásod van.
Ha RAID5+HS-t nézel, akkor legalább 8-at kellene venni, de még mindig alig van kapacitásod, ellenben tutira elfogy a keret.
("ha 1TB-os ssd-vel számolunk, akkor beleférünk a keretbe" - nem tudom, ez milyen SSD, de tutira hazavágod az egész rendszert: BMW-re nem rakunk Lada kereket).

Az is egy opció lehet, hogy egy vasba veszel lokális SSD-t, a VM-eket aszinkron replikálod máshova. Persze ez már kicsit más rendszer, főleg egy redundáns tároló alapú után.

( okcomputer44 | 2016. 04. 17., v – 01:28 )

Hali,

En epp most jatszom a GlusterFS-el ESXi alatt.
Mi a Synology-t valasztottuk mint HA cluster storage megoldas, es hogy oszinte legyek en is nagyon megbantam! Reszletek itt: http://hup.hu/node/146190

Sajnos azt gondoltam, hogy ez nagyon facca lesz, de miutan a 3 HA clusterbol az egyik osszeomlott, igy ezutan batran mondhatom, hogy egy kalap sz@r... Hiaba tevedni emberi dolog es sajnos ez egy eleg komoly tanulopenz volt nekem is. Szerencsere nem az osszes host volt erintett, de 1-2 gep kiesett, ami nem volt tul jo.

Szoval amit en mondanek a fentebb emlitett rendszerekrol.
Ha nyogodtan akarsz aludni es nincs eleg kereted ra, akkor csak es kizarolag sajat rendszert epits, amit 100%-ban ismersz almodbol is.

iSCSI szerintem nem jo, mert ha kihal a storage, akkor a host is kihal(hat). (persze gondolom, hogy lesz sok ellenzo itt erre a velemenyemre)
VMware-t kinyirni nagyon nehez kernel szinten, de az iSCSI igen konnyen kepes ra.
Nagyon sokat teszteltem, nem csak googlin lattam, szoval van 1-2 csunya tapasztalatom ezzel.
Bazi gyors meg sokkal jobb mas szempontbol mint az NFS, de nem akkor ha beut a hiba.

A VMware is az NFS-t favorizalja alapbol es nem az iSCSI-t. Amugy az biztos, hogy a multipath meg az alap sebesseg is nagyon jo az NFS-hez kepest.

DRBD szinten zenesz, amig megy jol addig nagyon baro, meg minden, de ha gond van mondjuk ugy hogy mindket node eldobta a lemezt es gyorsan kell reagalni es a rendszert manualisan visszahozni es nem sikerul, akkor biza ez nagyon nem jo megoldas. Ezzel is volt ilyen tapasztalatom es emiatt dontottem ugy, hogy koszi szepen, de ez nem megoldas.
Hasonlo gondom volt a NAS4Free-vel, ami ZFS-t hasznal HAST-al (highly available storage) ket disk haloban szinkronizalja egymas, hasonlo mint a DRBD. Ott is megvan az a "klassz" opcio, hogy a ZFS szetzuhan es csak nezel mint jani a moziban, hogy most mi a f@sz lesz mert mindeket node halott.
Persze a VMware meg nem megy, mert nincs halozati storage...

Na ezek utan en mit hasznalnek, jo kerdes... :)

Osszepakoltam egy Corosync/pacemaker clustert GlusterFS-el.
A GlusterFS-t nem kell bemutatni, mert a ket node-os verzio egyszeru mint a faek. 25 perc osszepakolni.
Alapbol van NFS mountolasi opcio, szoval VMware-en megy faszan. Ezen kivul, ha van ket node, beintegralni 3.-at 4.-et szinten nem nagy dolog, ami lehet off-site backup...

Jelenleg 1 halokartyan erheto el a virtualis node es ezen keresztul 60Mb korul lehet irni a node-ra.
Amugy ez egy VMware host, szoval barmilyen vason elfut. (host egy regi HP G360)
Ezt meg fel fogom tuningolni, load-balanced bonding opcioval a hoston belul.

Szoval maga a szerver amugy 2X 1GB csatlakozik a fizikai halohoz.
Amikor a "sima" NFS szervert teszteltem ugyan ezen a gepen, akkor 80-90MB korul irt, de nyilvan a GlusterFS sokkal komolyabban hasznalja a CPU-t, igy nem tudja az NFS sebesseget.
Gondolom az NFS opcio is ra lett "integralva" a GlusterFS-re, szoval adott hogy nem lesz a sebesseg kozel sem olyan, mint ha natur NFS lenne.

Szoval maga a virtualis node a corosync-el 2 ringen fut.
Az egyik egy "belso" ring, a masodik egy "kulso" fuggetlen a normal halozattol.
Ez azert fontos, hogy a ket gep mindig el tudja erni egymast meg akkor is, ha "atom" szinten le van terhelve a gep.

A belso ring a virtualis gep IP-n fut. A kulso pedig ossze van kotve egy normal halokabelen.
Magyarul a ket ESXi gepen van 3 halokartya, ebbol ketto a virtualis node-ra van kotve, a harmadik pedig osszekoti a ket virtualis gepet switch nelkul.

Szoval az NFS megosztas a virtualis IP-n fut, amit a Corosync biztosit, persze ezt lehetne mondjuk keepalived-al is, de abban a megoldasban nincs lehetoseg az extra szervizek hozzaadasara.
Corosync-ben minden van, ha Mysql vagy barmi mas kell, csak hozzaadod es kesz.

Mukodes:

Ha kilovom az aktualis node-ot, akkor atall a masik node-ra a virtualis IP kb 0.5 sec alatt es ott is marad, ahova atvandorolt. Amugy ez is allithato a Corosync-ben, hogy mi tortenjen, ha a regi halott node visszajott. Ez az opcio nem(sem) allithato a keepalived-ban. Magyarul ha a halozat nem megbizhato es a gepek nem latjak egymast rendesen, akkor ide oda vandorol a virtualis IP.
Hasonlo dolog miatt is dontottem az NFS mellett. Ha az NFS elhal, akkor az ESXi host megy tovabb!
Ha a storage visszajon, akkor az ESXi minden gond nelkul visszahozza a regi futo gepeket.
Ez iSCSI alatt kinyirta a host-ot es minden rajta futo gepet.

Jelenleg a cegunk Named slave szervere(kb ~40 domain fut ezen a gepen) + a ceges Cacti szerver(kb 70 host snmp+ping lekerdezes percenkent es visszairas a lokalis postgresql-be) es a sajat gepem megy rajta.(4 domain + esp8266-os update-ek mysql-be)
Stabilnak tunik egyenlore. :) Ha par honap utan is megy rendesen, akkor valszeg rahuzok komolyabb gepeket is. Az elonye az hogy a node-ok akkor is elerhetoek, ha szetzuhan a cluster, mert mindent fel lehet manualisan huzni. Persze ha csunya osszezuhanas van, akkor lehet hogy mentesbol kell visszaallni, mert mindket node lementheti a borulast is. GlusterFS nem foglalkozik azzal, hogy mit b@sztunk el, ha gond van a geppel, akkor azt is atmasolja. :)

Ha kell tudok adni ovf temlate-et, amit csak installalni kell ESXi-ba.
Kicsereled az IP-ket es kesz a storage. :)
Amugy tervezem hogy felpakolom a netre, de meg nem volt idom "legyartani" a wordpress oldalt.
Egy kicsit bonyolult megerteni az egeszet, ha nincsenek kepek. Kepeket meg "legyartani" eleg sok ido.

1-2 hasznos link, amiket hasznaltam a setup-hoz:
http://foaa.de/old-blog/2010/10/intro-to-pacemaker-part-2-advanced-topi…
http://www.gluster.org/community/documentation/index.php/Getting_starte…
http://zeldor.biz/2010/12/activepassive-cluster-with-pacemaker-corosync/
http://www.sebastien-han.fr/blog/2012/08/01/corosync-rrp-configuration/

"Ha kilovom az aktualis node-ot, akkor atall a masik node-ra a virtualis IP kb 0.5 sec alatt es ott is marad, ahova atvandorolt. Amugy ez is allithato a Corosync-ben, hogy mi tortenjen, ha a regi halott node visszajott. Ez az opcio nem(sem) allithato a keepalived-ban. Magyarul ha a halozat nem megbizhato es a gepek nem latjak egymast rendesen, akkor ide oda vandorol a virtualis IP."

Ezt erosen cafolom, keepalived-vel hajtok haproxy HA setupot, es nekem hibatlanul mukodik hogy magatol nem vandorolnak ide-oda a virtualis ip-k, ha egyszer atallt a rendszer a 2-es node-ra akkor ott is marad akarhanyszor jarkal fel-le az 1-es node.

Hali,

Nalunk is fut egy par gepen keepalived, pont emiatt hasznaljuk a corosync-et erre, mert a keepalived mindig a nagyobb prioritasu gepen fog futni.
Van 2 osip load-balancerunk, meg egy 4 gepes mysql cluster ha-proxyval.

Szoval idezet a RedHat oldalrol:
###
The interface parameter assigns the physical interface name to this particular virtual IP instance, and the virtual_router_id is a numerical identifier for the instance. The priority 100 specifies the order in which the assigned interface to take over in a failover; the higher the number, the higher the priority. This priority value must be within the range of 0 to 255, and the Load Balancing server configured as state MASTER should have a priority value set to a higher number than the priority value of the server configured as state BACKUP.
###

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…

vrrp_instance RH_EXT {
state MASTER
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass password123
}
virtual_ipaddress {
10.0.0.1
}
}

Szoval ha kilovod a halokartyat a master gepen akkor atall a virtualis IP a slave-re, ha visszakapcsolod, akkor visszall a master-re. Nem kell cafolnod a keepalived igy mukodik.

Lehet hogy a te konfigodban van valami extra, ami felulirja az alap futo konfigot, de a "sima" keeplived igy muxik. Pont ezert problemas, ha a network "flipping", mert ilyenkor vandorol es nem is tul gyors.

####
VRRP is based on advert sending over multicast (advert interval determined by advert_int in keepalived.conf normally configured for 1 sec). This is an election protocol. Master is the one with the highest priority. When the master crashes, an election is held to find the next highest higher priority VRRP master.
####
Plussz itt: http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.failover.html

Gondoltam hogy bemasolok 1-2 referenciat mielott az lesz, hogy a vakvilagba lovoldozok. :)

Te meg szerezz egy angol szotarat. :)
Hogy melyik resz nem volt vilagos, azt tenyleg nem tudom.

Akkor ismetles megyegyszer, csak neked:
Balancing server configured as state MASTER should have a priority value set to a higher number than the priority value of the server configured as state BACKUP.

Es ismet:
the higher the number, the higher the priority

A keepalived alatt a virtualis IP ertendo.
Nem ertem, hogy mi a f@sznak kell kotekedni...

van egy ilyen hasznos opciója:

# VRRP will normally preempt a lower priority
# machine when a higher priority machine comes
# online. "nopreempt" allows the lower priority
# machine to maintain the master role, even when
# a higher priority machine comes back online.
# NOTE: For this to work, the initial state of this
# entry must be BACKUP.
nopreempt

Tegyük hozzá, hogy ezek a megoldások csak akkor működnek, ha a VRRP indulásakor a gép látja a hálózatot (azaz véletlenül sem lehet a portja STP szempontból várakozó állapotban). Különben feljön, megállapítja, hogy egyedül van, ő lesz a master, aztán amikor "belecsöppen" a hálózatba, akkor az erősebb lesz a nyerő.

Ilyen ellen at lehet allitani a switchportot portfast-ra, vagy pl tenni egy init scriptet a keepalive ele ami varakoztatja addig mig pl gateway nem valaszol.
Mondjuk ettol nem vagyok a keepalive hive, pl corosync-ben tobb a lehetoseg, de bizonyos esetekben keepalive/vrrp/carp is eleg lehet.

Én szeretem a keepalived-t, viszonylag sokféle szolgáltatás esetén használjuk/használtuk. Készítettünk rá egy szkript alapú keretrendszert, hogy könnyű legyen akár több szolgáltatást alávonni, semmi gondunk nem volt még vele. Egyszerű, hatékony, sokszor bizonyított már.

STP: valóban, egyrészt portfast segíthet, másrészt nem tapasztaltuk még, hogy ilyenek miatt szétesett volna, bár tény, hogy főleg virtuális gépben használjuk.

Ahogy olvasom, a corosync mélyebb alkalmazás szintű integrációt igényel, de ennek főleg állapottartó alkalmazásoknál lehet jelentősége, ahol a szinkronizáció nem oldható meg másként.

( macko003 | 2016. 04. 17., v – 13:02 )

bognarattila

Az emc jelenleg 300as és 900as SAS disk-kekkel van tele, emiatt gondolkodunk a max 900-ban. Alkalom adtán most is tapasztalunk performancia gondot, amit megoldana az SSD. Tudunk az EMC-be is SSD-t rakni, viszont az ára nagyon magas, ezért maradna a SAS. Az EMC útvonalat a politikájuk miatt hanyagolnánk. Pl. új disk-re 3 hó gart adnak, mivel ez nem termék, hanem bővítés..., felújított disk-re egy évet gart. Viszont ha beépítjük a storage-ba, akkor a config megváltozik, és még pluszban fizethetünk a supportra is.
Nem azt mondom, hogy 300-as vagy 900as disk-kekkel nem tudnánk olyan sebességet elérni, ami az igényeknek elegendő, de ha azonos árból ki lehet hozni egy sokkal gyorsabb rendszert, akkor miért építsünk korlátokat?
Tárterületben a jelenlegi elvárás min 4TB, viszont a bővülés kb fél TB/év, így nem szeretnénk évente bővítgetni.
Nem értem, hogy miért vágnánk haza a rendszert az SSD-vel.

okcomputer44

Köszönöm a tippeket, meg fogjuk fontolni. Az ovf miatt jelentkezem.

Olyan SSD vágná haza a rendszert, ami 1TB-os és 18 darab kerül 2M-be. 111e-ért nem kapsz olyan 1TB-os SSD-t, ami ilyen környezet terhelésére lenne kitalálva. Ha mégis, megköszönném, ha megírnád a típusát.

Van egy "normál" rendszeretek, és elkezditek tákolni, teljesen bizonytalanul.

"ha azonos árból ki lehet hozni egy sokkal gyorsabb rendszert, akkor miért építsünk korlátokat?" - a sebesség akkor ér valamit, ha az minden szempontból megbízhatóan működik. Legalábbis olyan környezetben elvárás szokott lenni a megbízhatóság, ahol egyszer már vettek egy redundáns tárolót. Ilyen SSD-kkel ez erőteljesen kérdéses. Ráadásul ezen SSD-k fölé kell valami rendszer, aminek az ára biztosan nem nulla (munkaidő is pénz).

- ettől még 2M-ből szerintem nem jön ki 18db 1TB-os olyan SSD, ami neki kell, és akkor a rendszer szoftveres része még teljesen hiányzik
- nyilván mindenki úgy oldja meg redundáns tároló igényét, ahogy akarja, amire tudása és ideje van
- attól, hogy a Storwize ilyen, más tároló lehet jó
- arra sincs garancia, hogy "akármi" alapon jobbat fogsz kihozni, kevesebből, belátható időn belül, ami legalább annyira fenntartható stb stb.
- kérdés, hogy a munkáltató mennyire díjazza az egyedi rendszereket, mert ez is kockázat

teljesen mindegy, egyszeruen a szoftver nem olyan rajta. ha van csodaszoftvered fole (ezt hasznalja a nimble, meg szinte mindenki, nekunk is van, itt lehet olvasni a mikentjerol)

szoval vagy veszel jo enterprise grade flasht (Intel S3600/S3700/P3xxxx sorozat), vagy szerzel csodaszoftvert ra.

Production feladatra (és még a build/homokozó gépek is ide tartoznak, mert azok is termelő eszközök!) csak hardveres RAID-et használunk, amin nem megy át a discard.

Egyébként, kipróbáltam stand-alone SATA portra dugva, discard-dal. Sokkal jobb, de akkor is jelentősen hullámzik a teljesítménye.

Mi áttértünk Intel DC S35xx/S36xx modellekre, ég és föld a különbség.

Ez egy viszonylag olcsó asztali SSD. Őszintén szólva nem volt alkalom/lehetőség, hogy egy infrastruktúrában ilyet bekockáztassunk, de amiket olvastam az SSD-kről, ezeket nem folyamatos üzemre tervezték. Értsd: jó eséllyel hamarabb meg fog pusztulni, illetve teljesítmény problémák is lehetnek. 2M ahhoz sok pénz, hogy újra el kelljen költeni.

http://www.kingston.com/us/ssd/enterprise/best_practices/enterprise_ver…
http://www.idgconnect.com/blog-abstract/1696/a-world-difference-enterpr…

http://www.samsung.com/us/business/oem-solutions/pdfs/SSD-FAQs-2012.pdf
Q: What’s the value of the SM825 over standard “value SSDs?”
A: Unmatched sustained write performance, power loss protection, and extended write-endurance.

http://www.anandtech.com/show/8216/samsung-ssd-850-pro-128gb-256gb-1tb-…
"the 850 Pro does not have power loss protection or end-to-end data protection for example"

Egy már létező redundáns tárolóval én nem kockáztatnék, de nyilván mások vagyunk, nem ismerem sem a cég vezetőségét, sem a cég méretét, sem az anyagi helyzetét. Tipikusan a világos beszéd a legjobb: ha 2M-ért nem lehet normálisan végrehajtani a szükséges fejlesztést, akkor kár belefogni (legfeljebb úgy, hogy most történik valami olyan fejlesztés, ami egy következő fázissal teljesedik be, de ezt a pénztárnok számára is világossá kell tenni).

Őszintén szólva nem tudom: mint SSD, valószínűleg bevállalható, de még mindig vannak fontos kérdések:
- a szerverek befogadják-e (egyrészt SATA, másrészt gyártói kiszúrás)
- szerverekben van-e RAID vezérlő, az sem nulla forint (ez a típusú SSD már eleve drágább, tehát valamit csökkenteni kell)
- kell fölé valami szoftver, aminek a beállítása nem nulla idő (pénz) és kockázatot jelent; vannak pénzes szoftverek is ilyen célra (több is), de ezek akár közvetlenül is pénzbe kerülhetnek, a keret eleve szűkös
- meg kell nézni, miért választottak ki "márkás" tárolót (vezetőség szempontjából), ezek az érvek most miként állnak: ilyen SSD és nyílt szoftver alapon összehozni egy rendszert nagyon erős váltás üzleti szempontból is

Nem tudom hogy be merjem-e vallalni ezt a megoldast.
Ahogy a wiki-t nezem, mar az alap install is vagy egy het. :)

Amikor nezegettem par eve, pont akkor is ez volt a gond, hogy nem volt ido a reszelesre.
Most is kb ez a helyzet, nincs ido, de kell a storage gyorsan. :)
A ceph ahogy nezem kb olyan mint a corosync/pacemaker kombo tesoja.
Crm vagy UltraMonkey vagy CMAN, vagy epp amit az admin hasznal a "reszeleshez".
Persze nyilvan a Synology meg a masik veglet, de ez azert eleg meredek.

Lehet hogy futok megegy kort a NAS4Free-vel, mert abba integralva van a HAST alapbol.
Addig meg tesztelgetem a Glusteres kombot amit reszeltem.

Ha van install.sh script a ceph-hez, akkor szolj legyszi. ;)

Hm ez eleg baratian hangzik.
Persze nyilvan egy alap install az meg csak arra eleg, hogy az ember nezegesse, hogy mi es ez valojaban. :)

Ezt az installt neztem (a wiki-n kivul) es eleg egyszerunek tunik.
Viszont ez eleg szomoru comment volt az admitol:

###
Thanks Ben.
Sadly Ceph is still a solution that requires a lot of tuning and hacking in the commands and config files to make it work. Calamari is the biggest example of this, after months I'm still fighting to have a working and repeatable installation and configuration process.
###

Szoval azert ezen reszelni kell, nem is keveset.
Ha majd lesz idom ranezek azert.

Rakjatok SSD-t a lokális szerverbe cache-nek, a Qlogicnak van olyan FC kártyája ami transzparens módon SSD cachet is tartalmaz.
FabricCache http://www.qlogic.com/Resources/Documents/DataSheets/Adapters/DataSheet…
Így maradhat az FC protokoll, a vmware licensz is, a teljesítményen viszont jelentősen dobna.

Igen: cache-be kerül, amit gyakran olvas, de tárkapacitást a HDD adja (azaz kevesebb SSD-t kell venni, tárhelyet újonnan vett HDD biztosítja).
Olyan, mint normális tárolón belül az automatikus rétegzés/tiering (amit például az EMC is tud); előnye, hogy kevesebb SSD kell, mint amennyi adatod van, jól méretezett SSD réteggel gyorsul a rendszered, hiszen az intenzív elérési adatok SSD-re kerülnek.

( mr shadow v | 2016. 04. 17., v – 15:47 )

sub
--
>'The time has come,' the Walrus said<

( akoscomp | 2016. 04. 18., h – 09:56 )

2M-ból szerintem simán kijön egy redundáns NetApp storage SSD cache-el, főleg ha nincs szükséged az extrákra.

Nekünk a régi Dell MD3000i tároló kezd elöregedni ezért én is sokat gondolkoztam egy ilyen tárolómegoldáson, de eddig nem találtam megoldást, amit elég stabilnak gondolok.
A DRBD elég érzékeny a split-brain helyzetekre (2-3 éve nem követem, a 9-es verzió lehet megoldotta a problémákat). Jól be lehet állítani, de mégis néha előfordul, hogy kézzel kell helyreállítani.
GlusterFS-t mostanában használtam egy sima 3 node-ból álló webszerver alatt. Eddig csak egyszerűbb weblapokat tettem rá, de elég könnyen elhasalt. A többiek írásai alapján (elég komoly környezetben használják) nem tartom kizártnak, hogy én rontottam el valamit... Sebesség terén is voltak gondok vele, igaz csak 1Gbps-es hálókártyával vannak összekötve, de 10-20 MB/s-re csökken a másolás ha sok apró fájlt másolok a GlusterFS-re.
A Ceph a legígéretesebb, de oda komolyabb infrastruktúra kell és KVM-re lenne optimális váltani.

Jelenleg a kevésbé kritikus gépekhez redundancia nélküli ZFS-es tárolómegoldást használok, amivel nagyon meg vagyok elégedve. SSD cache van sima SATA lemezek ellőtt, de még nem sikerült jelentősen leterhelni a rendszert, pedig már több mint 10 virtuális gép fut róla és igénybe is veszik.
Itt sajnos ha bármi HW galiba lenne akkor kb 1 óra kieséssel jár egy új gépbe áttenni a tárolókat.

Visszakerestem egy pontos NetApp árat (FAS2552).
2015 áprilisában kaptam, és 25000 euró+áfából (1,937,500 Ft) kijött:
- Redundáns kiépítés
- 4x200 GB SSD, 20x600GB SAS HDD
- CIFS, iSCSI, NFS licenc
Azt nem tudom kivenni az ajánlatból, hogy milyen extrákkal jön, de az alap az biztos benne van.

p.s.
valamit nagyon elszámoltam... újraszámolva kb 10 milla

Azért azt tegyük hozzá, hogy ha a DRBD split-brain -be kerül, annak mindig reprodukálható folyamata van, nem kopogó szellemek okozzák. :) Nem hiszem, hogy lesz valaha automata merge split-brain után, ehhez ismerni kellene az eszközön lévő fájlrendszer felépítését, ami a DRBD hatáskörén kívül esik. Ez a magasabb szintű megoldások privilégiuma (más területen meg ők vannak bajban).

Így, hogy felvilágosodtam, mennyi is az a 2 milla, én két külön fizikai gépen egy DRBD klasztert valósítanék meg Primary-Secondary felállásban (így kevésbé érzékeny).
Az első gépbe egy SSD read cache-es ZFS-t, a másodikba pedig egy sima HDD-s tárolást (ha a ZFS mindkettőbe kéri az SSD cache meglétét, akkor mindkettőbe).
A második gépbe lehet sima SATA vagy NL-SAS HDD-t is tenni, ha nem elég a keret, mivel ott csak írás történik.
ZFS esetében az NFS az optimálisabb kiszolgálás.

8x1.2 TB-s 10000 rpm-es HDD-vel és egy vagy két SSD-vel (pl. intel S35xx) kb bele is fér a keretbe.

Terhelés függvényében le lehet menni NL-SAS HDD-ig, amivel 3x több lenne a tárkapacitás de ott már nagyon kellene a write cache is, aminek a replikálása lehet több idő mint az adatok kiírása direkt a HDD-re.

( wyx v | 2016. 04. 18., h – 09:59 )

"mire rendelkezésre áll kb 2 millió Ft keret, így megvizsgáltuk a lehetőségeinket, és a következőre jutottunk"

Ebből elosztott adattárolót nem építesz ki, vagy ha igen, lassú lesz.
A Ceph-nek legalább 3-4 node kell, darabonként min. 600e Ft-os szervereken, és 10 Gbit/s közöttük. Ha az áraklat összerakod, 5-6 milcsi min.

A nyitó hsz-ban a 18 disk úgy meríti ki a 2 millás keretet, ha az emc-től vesz "brand-elt" 900-as SAS disk-et.
A sarki kiskerben terás WD RE bruttó 29k, vagyis bruttó 520-ból (nettó 410) megúszod a lemezeket. IOPS-ben nyilván sehol nincs a kettő egymáshoz, de tesco PC-hez inkább az utóbbi illik, vagy inkább a felébe kerülő "mezei" 7.2k-s terás lemez :)

( joco01 v | 2016. 04. 19., k – 13:01 )

Én a buta hardverek fölé épített masszívan skálázható elosztott szoftveres megoldásokban hiszek, mint pl. a GlusterFS vagy a Ceph. De azt nem tudom, hogy konkrétan virtuális gépek alá az mennyire jó, érdekelne. A polcról levehető storage hardverekben valamiért kevésbé bízok, biztos jók valamire, de az esetleges meghibásodásuk elég nagy fejfájást tud okozni, és szerintem ár/érték arányban is a szoftveres megoldások jobbak.

--

( AiRLAC v | 2016. 04. 19., k – 15:54 )

Nem számoltam utána a költségnek, de gondolatébresztőnek:
https://www.napp-it.org/hybrid_en.html

Én biztos valami 2+ darab Supermicro storage server köré építenék, hogy aztán FC vagy 10GB iSCSI/NFS az egyéni szájíz. Lehet csak kapacitásra menni sok nagy SATA 7200rpm és SSDk cachenek.

Értelemszerűen support contract és a megfelelő licenszek HA és/vagy async replication.

( asm v | 2016. 04. 22., p – 09:20 )

Ezek hany socketes szerverek? VSANra kertetek arajanlatot?
Ha egy socketesek, akkor talan meg bele is ferhet a 2 millios keretbe.