Střípky ze stavby centrálního úložiště

18.2.2010 23:12 | Přečteno: 5233× | Diskuze | | poslední úprava: 18.2.2010 23:34

Před nějakou dobou jsme si přestali stačit s ukládáním dat na lokální disky a museli jsme řešit rozumné úložiště zajišťující dostupnost dat pro víc počítačů v provozu 24x7 bez možnosti větší odstávky. Rozpočet jsme měli omezený, požadavky relativně vysoké.

Postupně tu budu zveřejňovat různé střípky ze stavby. Tento článek jsem původně nechtěl publikovat dnes, ale když jsem se podíval na počet písmenek, tak jsem usoudil, že je škoda to nezveřejnit.

Požadavky na nové úložiště

Naše nároky na úložiště:

• odolnost proti výpadku HW, v případě selhání HW naštveme mooooc lidí a přijít o data si v žádném případě nemůžeme dovolit,
• rozumný výkon pro provoz virtuálních serverů a servírování dat pro aplikace v nich běžící (weby, maily a podobné úlohy, databáze jsou na vyhrazených serverech),
• možnost růstu - nechci skončit na tom, že nebude kam píchnout další disky,
• možnost upgrade bez výpadku služeb nebo jen s minimálním,
• známá technologie - nechceme blackbox o kterém nic nevíme,
• data budeme tlačit po ethernetu, NFS, iSCSI nebo AoE
• podporu od dodavatele HW,
• raw prostor min. 4TB
• cena do 300k Kč s DPH

S kolegy jsme pracovali pro distributora SUNu jako technici, takže víme jak to chodí s HW pro enterprise sféru. Věděli jsme tedy celkem přesně co nechceme - low-end řadu libovolného diskového pole. Low-end disková pole jsou většinou dost omezené záležitosti ve stylu "za hodně peněz málo muziky, hlavně když to má tu správnou samolepku". Použitelná řešení od velkých výrobců HW (SUN, IBM, HP, NetApp) začínají zase na cenách mimo náš rozpočet

Výběr skončil na řešení s využitím dvou serverů mezi kterými budou replikována data pomocí DRBD.

Architektura zvoleného řešení

Zvolená varianta nakonec dopadla následujícím způsobem. Pořídíme dva servery s dostatečnou diskovou kapacitou. Nainstalujeme na ně Linux, data budeme replikovat pomocí DRBD v režimu Primary-Secondary. Data budou vystavená přes NFS a iSCSI nebo AoE. Vysokou dostupnost zajistí heartbeat.

Výběr vhodného hardware

Hardware jsme vybrali od Supermicro, mají case, který umožňuje zastrkat až 24 hot-swap disků. V kombinaci s kvalitním RAIDem Areca 1680 s 2GiB cache zálohované baterkou máme dostatečně prostoru i výkonu. Uvedená RAID karta zvládne SATA i SAS, máme variantu s externím SAS portem, takže případné rozšíření až vyčerpáme všech 24 pozic pro disky je velmi snadné - připojíme externí box s disky a pokračujeme dál. Procesor jsme zvolili čtyřjádrový intel i7 a 6GiB ECC RAM. Do serveru také putovalo víc síťovek - 2 integrované už má, tak jsme přidali další dvě dvouportové gigabitové intelky.

Pro DRBD je nutné zajistit aby byly oba servery stejně silné - nelze si říct, že na Secondary server použiju nějaký slabší (a hlavně levnější) stroj. Koupili jsme tedy oba servery v identické konfiguraci a se supportem na 3 roky, oprava další pracovní den po nahlášení. V případě výpadku jednoho serveru můžeme bez problémů fungovat na jeho dvojčeti.

K serverům jsme koupili i management rozhraní, které umožňuje po síti přes IPMI rozhraní i jejich vzdálený restart. To je velmi důležité - když se server sekne, tak aby mohl druhý fungující server převzít kontrolu, můsí mít možnost násilného restartu. Konfigurace tohoto mechanismu označovaného jako STONITH je popsaná v článku na STONITH - když se oba nody HA clusteru nedohodnout a musí se vzájemně sestřelit.

Instalace a konfigurace OS

Konfigurace sítě

Konfigurace síťe je relativně snadná, pokud si nepromícháte kabely při propojování

Mezi servery doporučuji nepoužívat žádné další prvky - propojte je pěkně na přímo. Používáme tzv. "bonding" kdy jsou spojené dvě síťové karty do jedné virtuální. Linux pak zajišťuje rozkládání zátěže mezi ně a v případě výpadku jedné z nich i převedení veškerého provozu na tu zbývající kartu.

Pro bonding jsem vybral dvě různé karty, jedna integrovaná na desce, druhá v PCIe slotu. Konfiguraci stačí zapsat do standardních konfiguračních souborů CentOSu a on už její nahození zajistí při každém startu sám.

Pro přímou komunikaci mezi servery používáme rozhraní bond0 a pro komunikaci s klienty bond1.

[root@node1 ~]# grep bond /etc/modprobe.conf 
alias bond0 bonding 
alias bond1 bonding 
options bonding mode=balance-rr miimon=100

[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:30:48:B9:6B:50
ONBOOT=yes
TYPE=Ethernet
SLAVE=yes
MASTER=bond0
USERCTL=no

[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth5
DEVICE=eth2
BOOTPROTO=none
HWADDR=00:30:48:9C:2C:80
ONBOOT=yes
TYPE=Ethernet
SLAVE=yes
MASTER=bond0
USERCTL=no

[root@node1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0 
DEVICE=bond1
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
IPADDR=172.16.1.100
NETMASK=255.255.255.0

Každý ze serverů má tedy rozhraní bond0 pro komunikaci s druhým serverem a oba stroje jsou propojené napřímo. Další rozhraní je bond1, které slouží pro servírování dat klientům a poslední používané rozhraní je libovolné volné připojené do management síťě aby bylo možné stroje spravovat. Do management síťe je také zapojené management rozhraní serverů a raid karet.

Při konfiguraci síťe také nezapomeňte na nastevení iptables. Při jejich konfiguraci upravuji soubor /etc/sysconfig/iptables a následně aktualizuji konfiguraci pomocí iptables-restore < /etc/sysconfig/iptables. Jakmile zkusíte použít "klikací" nástroj system-config-security, tak vám konfiguraci iptables totálně rozseká a znefunkční (proto také na uvedený soubor nastavuji atribut "i" - chattr +i ...).

Jumbo Frames

Aby byla zajištěna maximální propustnost sítě, doporučuji začít používat tzv. Jumbo Frames. Výchozí velikost MTU v linuxu je 1500b, podle toho jaké máte síťové karty a switche po cestě doporučuji použít vyšší hodnoty. Náš switch bez problémů zvládne velikost rámce 16k, intelky síťovký zvládají 9k - nastavil jsem tedy pro všechny síťovky velikost MTU 9000.

DRBD

Konfiguraci DRBD a jednu z možností řešení situace kdy se DRBD rozpadne jsem popsal v jiném článku na blogu: Konfigurace DRBD a řešení situace "Split-Brain", pro pochopení způsobu konfigurace to snad stačí.

Konfigurace DRBD pro naše použití je trochu specifická - na svazcích exportovaných z HW RAIDu mám nasazené LVM. V něm vytvořené volumy a ty jsou použité jako zařízení pro DRBD. Mám takto udělané 3 DRDB zařízení (podle konkrétních diskových skupin kde každá je určená pro jiná data) a nad nimi je zase nasazené LVM a v něm vytvořené volumy na kterých je souborový systém.

O první úroveň LVM se stará přímo distribuce - nahazuje ho při startu CentOS standardními skripty. DRBD nahazuje heartbeat, po naběhnutí DRBD heartbeat nahodí druhou úroveň LVM, připojí souborový systém a začne startovat další služby (IP adresy, NFS, AoE). Heartbeat má nastavená pravidla tak aby nahazoval služby tam kde je DRBD ve stavu Primary. Nemůže se tedy stát, že by na node0 nahodil DRBD a připojil souborový systém a na node1 nahodil NFS.

Jestli se vám zdá zbytečné nasadit LVM pod i nad DRBD, tak napište proč to tak nemůže být Mě připadá variabilita takového řešení docela dobrým důvodem - mohu stěhovat data kam chci a jak chci aniž by to klienti poznali a zvětšování prostoru také není úplně k zahození.

LVM na DRBD

Pokud budete chtít tak jako já nacpat LVM na DRBD svazek, je nutné to povolit v konfiguraci /etc/lvm/lvm.conf - v sekci devices jsem upravil:

preferred_names = [ "^/dev/drbd", "^/dev/sd", "^/dev/mapper/" ]
filter = [ "a|/dev/drbd.*|","a|/dev/sd.*|","r|.*|" ]

Heartbeat

Instalaci Heartbeatu a Pacemakeru zvládnete pravděpodobně sami, na Internetu je k nalezení docela dost návodů. Jeden z možných: http://www.clusterlabs.org/wiki/Install Docela pěkný popis konfigurace je také k nalezení na webu Novellu o SLESu.

Servery jsem propojil přes RS232 abych měl zaručený paralelní komunikační kanál k síťovým kartám - pro cluster je to docela důležité. Poižitá konfigurace heartbeatu (/etc/ha.d/ha.cf):

use_logd off
logfile /var/log/ha.log
debugfile /var/log/ha.debug
keepalive 1
warntime 10
deadtime 30
initdead 120
udpport 694
bcast bond0
baud 19200
serial /dev/ttyS0
node node0.domain.tld
node node1.domain.tld
auto_failback on
crm respawn
apiauth         mgmtd   uid=root
respawn         root    /usr/lib64/heartbeat/mgmtd -v
respawn         root    /usr/lib64/heartbeat/hbagent

Zajímavé části konfigurace CRM:

DRBD

Nejdřív si v clusteru nadefinuji jednotlivé svazky DRBD:

primitive drbd0 ocf:heartbeat:drbd \
	params drbd_resource="r0" \
	op stop interval="0" timeout="180"
primitive drbd1 ocf:heartbeat:drbd \
	params drbd_resource="r1" \
	op stop interval="0" timeout="180"
primitive drbd2 ocf:heartbeat:drbd \
	params drbd_resource="r2" \
	op stop interval="0" timeout="180"

Chci aby všechny DRBD svazky nabíhaly do Primary stavu na stejném serveru, proto jsem je seskupil do grp_drbd. Svazky nahazuji najednou a pouze tak aby byl vždy jeden server ve stavu Master (~Primary pro DRBD, definice ms_drbd). Spouštím je na preferovaném uzlu clusteru (pravidlo loc-drbd). Protože je cluster symetrický a nastavený do režimu failover, bude v případě nedostupnosti tohoto uzlu (node1.domain.tld) použit uzel druhý.

group grp_drbd drbd0 drbd1 drbd2 \
  meta migration-threshold="2" failure-timeout="180s"

ms ms_drbd grp_drbd \
  params clone_max="2" clone_node_max="1" master_max="1" \
master_node_max="1" notify="yes" globally_unique="false" \
  meta target-role="Started"

location loc-drbd ms_drbd \
  rule $id="loc-drbd-rule" $role="Master" inf: #uname eq node1.domain.tld

Jak jsem psal, nad drbd je zase LVM, je třeba ho tedy také nadefinovat. V rámci zjednodušení následného zapisování pravidel případně rozšiřování konfigurace jsem všechny LVM svazky vsadil do jedné skupiny (grp_lvm).

primitive lvmdrbd0 ocf:heartbeat:LVM \
  params volgrpname="vgrep0" exclusive="truemeta" start="45" stop="45"
primitive lvmdrbd1 ocf:heartbeat:LVM \
  params volgrpname="vgrep1" exclusive="truemeta" start="45" stop="45"
primitive lvmdrbd2 ocf:heartbeat:LVM \
  params volgrpname="vgrep2" exclusive="truemeta" start="45" stop="45"

group grp_lvm lvmdrbd0 lvmdrbd1 lvmdrbd2 \
  meta target-role="Started"

Souborové systémy na tomto LVM je třeba také připojit, zase to musí obsloužit Heartbeat:

primitive fs1 ocf:heartbeat:Filesystem \
  params device="/dev/vgrep0/lv0" fstype="xfs" directory="/export/d0" options="noatime"
primitive fs2 ocf:heartbeat:Filesystem \
  params device="/dev/vgrep1/lv0" fstype="xfs" directory="/export/d1" options="noatime"
primitive fs3 ocf:heartbeat:Filesystem \
  params device="/dev/vgrep2/lv0" fstype="xfs" directory="/export/d2" options="noatime"
primitive fs4 ocf:heartbeat:Filesystem \
  params device="/dev/vgrep2/lv1" fstype="xfs" directory="/export/clust" options="noatime"

group grp_fs fs1 fs2 fs3 fs4 \
  meta target-role="Started"

Aby všechny služby startovaly na správné straně clusteru, tedy na té kde je DRBD ve stavu Primary, je třeba nadefinovat "colocation" pravidla:

colocation grp_fs_on_grp_drbd inf: grp_fs ms_drbd:Master
colocation grp_lvm_on_grp_drbd inf: grp_lvm ms_drbd:Master
colocation grp_vps_on_grp_drbd inf: grp_vps ms_drbd:Master

Služby sice nastartují na správné straně, ale asi v nesprávném pořadí, proto ještě pořadí explicitně určím:

order ord_grp_fs_after_grp_lvm inf: grp_lvm:start grp_fs:start
order ord_grp_lvm_after_ms_drbd inf: ms_drbd:promote grp_lvm:start

Jak vidíte, pravidla popisující na které straně cluster nahodí služby a v jakém pořadí zapisuji již jen přes skupiny - je to tak přehlednější. Názvy těch pravidel se snažím volit co nejvíc popisné abych se v tom snadno orientoval, stejně jako v případě názvů skupin a služeb.

Export dat ke klientům

Ata over Ethernet - AoE

Na straně serveru je nutné nainstalovat vblade (teda nutné, existují i jiné aoe targety, ale vblade znám), který zajistí export dat. Exportovaná dat jsou obrazy disků pro XEN, tedy velké soubory. Veškerá konfigurace vblade se zadává při startu, je tedy třeba jí zapsat do CRM. Pro spouštění je možné použít skript ocf:heartbeat:AoEtarget, ale ten neumožňuje zadání dalších příznaků, které jsou pro mě důležité, -d a -s. Umožňují totiž v novém vblade exportovat data s příznakem O_DIRECT a O_SYNC. Skript jsem tedy upravil a pojmenoval AoEtargetKl. Poslední verze vblade je důležitá - chová se stabilněji. Při provozu doporučuji věnovat trochu času čtení dokumentace a ladění sítě pro kombinaci vblade a Jumbo Frames.

primitive aoedomU1 ocf:heartbeat:AoEtargetKl \
  params binary="/usr/local/sbin/vblade" \
device="/export/d1/domU1.img" nic="bond1" shelf="11" slot="0" vbladeparams="-d -s"
primitive aoedomU2 ocf:heartbeat:AoEtargetKl \
  params binary="/usr/local/sbin/vblade" \
device="/export/d1/domU2.img" nic="bond1" shelf="12" slot="0" vbladeparams="-d -s"
group grp_aoe aoedomU1 aoedomU2
	meta target-role="Started"
colocation grp_aoe_on_grp_drbd inf: grp_aoe ms_drbd:Master
order ord_grp_aoe_after_grp_fs inf: grp_fs:start grp_aoe:start

Docela prima u AoE je, že na straně klienta se při spouštění (tedy modprobe aoe) dá zadat parametr jak dlouho má klient čekat na timeout serveru. Přehození clusteru z jednoho nodu na druhý tedy aoe přežije velmi snadno, stačí nastavit rozumný timeout a není nutné řešit multipathing.

NFS

Konfigurace NFS bude v dalším zápisku.

Článek je také k nalezení na mém blogu kam postupně přesunu vše technické z původního blogísku na www.zdenda.com.        

Komentáře

[Jan Kundrát (jkt)]

Nerozumim, proc v /etc/sysconfig/network-scripts/ifcfg-eth1 je uvedeno DEVICE=eth0 (+ obdobne i pro druhy interface); jako jediny duvod me napada nejake znasilnovani udevu, ale nemyslim si, ze by to bylo az tak jednoduche a takhle to fungovalo.

Pozorovali jste se zmenou MTU nejaky meritelny narust rychlosti?

Ohledne propojeni seriovym kabelem -- konfiguraci heartbeatu nerozumim, ale prijde mi, ze pro spravnou funkci jak drbd, tak stonithu potrebujete dostupnou sit, tedy split brain u vas nastane v okamziku, kdy se rozpadne privatni sit mezi dvema uzly. Jakou vyhodu ma ona seriova linka? Zduvodneni v blogpostu je takove tautologicke :).

Jako vyhodu LVM pod DRBD berete predpokladam moznost jednoducheho rozsireni prostym pridanim disku (coz se mi zda sice trosku fuj, asi bych to resil pridavanim "celeho noveho RAID volume" a udelanim dalsi DRBD partitiony, ale budiz) a jako duvod pro LVM nad DRBD zas moznost hezky delit misto pro virtualni stroje, je to tak?

Jinak hezky clanek (resp. blogpost, ktery by vydal na hezky clanek).

[Zdeněk Burda]

U přenosu přes AoE s MTU 1500 byla rychlost kolem 10-11MiB/s, s MTU 7000 cca 75MiB/s.

Když na sebe servery neuvidí tak nastane problém - mohou si o sobě myslet, že "zrovna já jsem naživu a ten druhý mrtvý" a nahodí služby oba najednou. Propojením seriovou linkou si zajistím alternativní cestu mezi servery - pokud umře síť, je pořád dost velká šance, že si popovídají po rs232.

LVM nad drbd aktuálně používám jen na malé nedůležité oblasti na snapshoty. Porcování na virtuály zatím nepoužívám, ale časem budu.

Zápisek měl být původně jen jako osnova pro článek, ale když už jsem toho měl tolik, tak jsem to zveřejnil. Počítám s postupným rozepsáním jednotlivých kapitol (konfigurace a funkce heartbeatu např.).

[pht]

Takové pěkné technologie a nad tím vším je ext3?

[Zdenek]

Ja tam vidim XFS.

[pht]

Aha. Já se řídil tím obrázkem. :)

[Zdeněk Burda]

Ať si každý používá co chce

[RoboShim]

Tak teda podobny reseni pouzivame taky:)

Mame HW od Thomas Krenn s RAIDem Areca (tusim) 1260. IMPI taky.

Mame servery od sebe dal (jeden v -2. patre a druhy ve 3. patre), takze heartbeat zeneme po vlastni siti, pro replikaci mame dalsi oddelenou sit, pres kterou se taky pripojuji data na virtualni hosty a pak sdileji ke klientum.

S iSCSI jsme meli na zacatku problemy, takze servirujeme jenom pres NFS.

Vytvoreny RAID disk ale mirrorujeme rovnou na druhy disk a teprve na drbd zarizenich mame VG, ktere pak rozdelujeme do LV. Je to tak jednodussi, ze pri pridani noveho disku nemusim konfigurovat znovu drbd a startovat synchronizaci, ale proste jenom vytvorim LV. Na druhou stranu, pokud se musi udelat full-sync, tak to trva na celem disku. Ale radsi si pockam na full-sync, nez bych pri upravach drbd shodil oba servery:)

Jako FS na NFS share pouzivam reiserfs.

heartbeat se u nas stara o nastaveni drbd primary, nahozeni VG z DRBD, aktivovani LV ve VG, pripojeni oddilu, nahozeni shared IP a nastartovani NFS.

Pro XEN image pouzivame soubory na NFS.

[neaktivni]

Moc pekne, to bych dal klidne do clanku.

[Trained.Monkey]

Primlouval bych se za clanek, takhle dobry popis jsem uz dlouho necetl.

Testovali jste uz jak se to chova kdyz jeden server vypnete ze zasuvky?

[Zdeněk Burda]

V testovacím režimu to běželo několik měsíců, různých násilných restartů, výpadků a dalších událostí bylo několik desítek.

Článek bude. Začal jsem to psát jako osnovu k článku, ale když jsem viděl kolik textu jesem už napsal, zveřejnil jsem to aspoň v blogu. Mám tak možnost získat připomínky, které zohledním v článku.

Co mám zatím poznamenáno na doplnění do článku:

• učesat text tak aby byl čitelný a používaly se správné výrazy,
• víc rozebrat proč jsem zvolil řešení s DRBD a ne externí diskové pole,
• dopsat lépe konfiguraci síťě,
• popsat heartbeat a jeho ovládání,
• popsat základní pracovní postupy,
• zkusit vylovit případně doměřit něco tom jak rychle se nám kvedlají disky,
• monitoring clusteru.

+ NFS, IP adresa pro služby, GUI k heartbeatu

[Käyttäjä 11133]

No nevím, ale při požadavcích na vysokou dostupnost bych se asi jen stěží pouštěl do vlastního řešení

Yes, this guy have a NetApp label :)

[Zdeněk Burda]

To jsem čekal

1. máme omezený rozpočet
2. drbd a heartbeat nám už pár let běží u zákazníka a vím co od toho můžu čekat

Můžeš mi udělat odhad na kolik přijde řešení s využitím NetApp?

• synchronní replikace dat mezi dvěma boxy
• support 3r - fix NBD
• počáteční kapacita 4T RAW, RAID6 pro disky 750G SATA pro data kde není třeba výkon (10ks), menší SAS disky v raid 10 pro to kde je třeba výkon a není tolik dat (10ks)
• iSCSI nebo AoE, NFSv3 (předpokládám, že quoty a zámky fungují na NetAppu bez problémů)
• v případě výpadku jednoho boxu je nutné aby služby fungovaly dál - je tedy nutné zajistit multipathing pro iSCSI a správné přehození NFS na druhou stranu.

Na serverech, které používáme pro úložiště běží ještě některé další služby - např. centrální syslog, to předpokládám musím zajistit u NetAppu jiným serverem.

[gtz]

No nedávno jsem řešil nějaký podobný kousek, nakonec jsem pro pole i páskový autoloader volil verzi FC.
Cena byla o něco vyšší, ale rozhodla rychlost pole 8Gbit.

FC/SAS RAID 6, redundant controller, ASIC 667 (G6), 19”, 4x 8 Gbit FC , 2 GB cache, 12x 500 GB SATA
cena kolem 8000€

[Max]

Taktéž jsem čekal, že se ozve :D.
Zdar Max

[gtz]

No taky to bylo tvořeno pro zákazníka coby home-made jen s dodržením podobných parametrů. NetApp byl pro ně celkem hodně drahý.

[Käyttäjä 11133]

Měli jste opravdovou nabídku, nebo jen listovku, protože oproti listovce si můžete dát tak 40% off, případně můžete jít k nSeries IBM a pak je to dalších 10 - 15% off :)

[gtz]

Nabidku pro nas delala jedna Brnenska firma, na Netappu se kvuli tomuto zjistovala moznost Projektove Ceny. I tak ta cena byla ponekud nahore. nSeries jako proc .. servery tam byly DELL / HP. Zakaznik nechtel pole typu DS3x. Ja jsem mu nabizel Hitachi AMS, s kterym mam ty nejlepsi zkusenosti i s Produktovou cenou jsem s AMS byl hodne nad jejich moznosti.

Delam v tomto businessu (storage a ukladani dat) celkem hodne dlouho (od roku 2003), s listovkou bych tam ani nesel. Vim jak je to tezke s zakazniky jednat kdyz maji omezeny financni rozpocet.

[Zdenek]

Pri pozadavcich na kvalitni OS bych se stezi poustel do Linuxu.

Kde jsou dnes ty drahe UNIXy a kde je Linux?

[alblaho]

To je ale bestie.

Když si představím jak je to složité, kolik v tom běžícím kódu musí být bugů, tak je mi ouzko. Nechtěl bych řešit situaci, kdy se někde něco vysype.

[Zdeněk Burda]

Když to rozebereš na samostatné části, tak to tak strašné není. Linux/lvm, drbd, vblade, heartbeat/pacemaker - když se něco podělá, tak jsem schopný velmi rychle nahodit služby i bez heartbeatu na jednom z těch serverů.

Pokud se rozhodneš použít například pole připojené přes scsi/sas, můžeš se zbavit DRBD, ale zase tam bude to pole a některé bugy firmware jsou taky dobrá chuťovka, zvlášť u low-end polí které by se k takovému řešení muselo pouřídit z důvodu ceny.

[CET]

Jojo, a pak to dopada podobne, jako kdyz jsme si do firmy nakoupili male gs108t od netgear jako office switche. Pak jsme zjistili, ze nektery stanice maji pomalou sit, bud jenom na jeden server nebo na vsechny servery. Pres rok od reportovani chyby na support jsme vlastnima silama zjistili, ze problem je v neulozeni MAC adresy do pameti switchi, cili zrejme nejaka kolize a nalezeni dvou kolidujicich MAC adres. Teprve potom support odpovedel, ze to je opravdu kolize hashe, ze to je vlastnost prvni verze switche a druha by to snad mela mit opraveno. Co vic, z toho dokumentu, co poslali, vyslo najevo, ze switch nema (fyzicky) misto pro 8 tisic MAC adres, jak se pise ve vsech manualech k tomu switchi, ale jenom pro 4 tisice, a navic ten pocet je jeste zmenseny o ty hash kolize.

V Linux reseni se aspon muzes pohrabat, v uzavrenych ne. BTW: prave se mam rozhodnout, cim nahradime par starsich windows masin pro uzivatelsky data.

[KKL]

Ahoj, chtěl bych se zeptat proč jste zvolili Centos. Prostě ho znáte, máte nasazený ve větším apd. Zajímalo by mě, zda jste u tohoto typu použití neuvažovali např. o
FreeBSD/ZFS úložiště
Solaris 10/ZFS úložiště
OpenSolaris/ZFS úložiště
Nemá to být flame bajt, jen mě zajímá jak to je. Sám bych zvažoval Solaris, právě kvůli stabilitě a slušné funkčnosti ZFS.

[mimi.vx]

solaris ma pod oracle nejistou budoucnost .....

[Vskutečnosti Saýc]

Krom toho, ZFS je jeste docela nova technologie, a se zalohovacicimi a HA resenimi to neni tak zhave.

[KKL]

Myslím, že Oracle nenechá Solaris padnout, ale třeba se pletu :) Uvidíme co přinese budoucnost.

[regine2]

Není to OS, ale když se db-firma Informix nechala koupit IBM, tak přestalo jít o technologii či služby zákazníkovi, ale je z toho jen bussines až na prvním místě. Škoda.

[Zdeněk Burda]

CentOS případně RHEL používáme delší dobu, jsou s ním dostatečně dobré zkušenosti, má velkou komunitu uživatelů a je tu Red Hat, který za ním (RHEL) stojí. Prakticky každý u nás ve firmě zvládne jeho správu.

U FreeBSD nevím o srovnatelném stabilním řešení pro DRBD a také se o servery nechci starat sám. Musíme tedy nasadit něco známějšího a mám pocit, že v případě Linuxu najdeme snadněji admina než v případě *BSD. Zkušenosti se ZFS na FreeBSD nemám.

Solaris mám rád, ale na SUN HW a v trochu jiném nasazení. Umím si představit SUN Cluster + vhodné diskové pole, jenže to se dostáváme na jinou cenovou úroveň. Včera mi bylo na IRCNetu sděleno, že existuje Sun StorageTek Availability Suite umožňující podobnou funkčnost jako má DRBD, ale nemám s tím dostatečné zkušenosti. Docela by mě zajímalo jak to dopadne s OpenSolarisem a Solarisem jako takovým pod taktovkou Oracle. Taky bysme narazili se správcem Solarisu - asi jich nebude tolik jako v případě Linuxu. Sice ve firmě známe solaris 3 lidi, jenže všichni chceme správu serverů opustit a věnovat se jiným a zajímavějším věcem

[KKL]

Ok, díky za odpověď. Je fakt že SUN Cluster bude cenově dost jinde..... Jak to bude se SUN produkty pod Oracle jsem taky zvědavý, mám z diskuzí pocit, že jsou lidi ohledně budoucnosti dost nervozní - Oracle by měl dát k dispozici jasný plán, co bude jen udržovat, co rozvíjet a co úplně zastřelí. Sun StorageTek Availability Suite - také neznám, mrknu na to - díky za tip.

K.

[Zdeněk Burda]

Nejde o cenu SUN Clusteru (ten je zdarma), ale o ten HW pro Solaris pod ním a o vhodné diskové pole.

[KKL]

Aha, dík za osvětu, to jsem ani nevěděl že i Cluster je zdarma. V této oblasti ( enterprise hw/sw ) se nepohybuju a vím toho o tom prd. :)

[David Krch]

Pokud jde o plan co bude s jednotlivymi produkty Sun po akvizici, tak ten uz je zverejneny nekolik tydnu. Podivejte se na http://www.oracle.com/events/productstrategy/index.html, najdete tam ke kazde oblasti kratke video.

[Miloš Kozák]

Hezký zápisek, v létě jsem nad něčím podobným přemýšlel, ale ještě nepřišel správný čas... Nicméně v mém návrhu je ještě na vrcholu GFS2, s tím, že se GFS2 oddíl budu sdílet mezi 4mi virtualy a ty tam budou moc souběžně zapisovat (WWW,mail,...) ale nutně potřebuji i quoty a možnost simultánního zápisu.. Je možné tohoto dosáhnout pomocí NFSv3 a jak tam s quotama?

[Zdeněk Burda]

Na NFS samozřejmě quoty normálně používáme, jinak bych měl při našem počtu uživatelů (tisíce) docela problémy

[Miloš Kozák]

A jak je to se současným přístupem k filesystemu?

[frEon]

Pěkný článek, jen co je pravda. Akorát i tam chybí část konfigurace pacemakeru -> property, teda pokud tam máte něco zajímavého. Ono property umí dost změnit chování failoveru v různých situacích (např. volby symetric-cluster, default-resource-stickyness atp...).

[Zdeněk Burda]

Vím, že chybí - zatím jsou to vážně jen střípky Bude určitě ve finálním článku.