Archiv pro štítek: Cluster

Vysoká dostupnost dat bez diskového pole

Stalo se to ve 3 hodiny ráno, zvoní telefon. Na druhém konci kamarád s tím, že odešel souborový server a firma stojí. Zkrátím to. Provoz jsme obnovili krátce po sedmé ráno a to jen díky tomu, že jsem měl náhradní server s kompatibilními disky. A teď co s tím aby se to příště nestalo…

Zadání je jednoduché: Postavit řešení, které bude sloužit jako souborový (Samba) server a bude odolné vůči výpadku jednoho serveru.
Continue reading

Prezentace HA LAMP clusteru

Před pár týdny jsem uspořádal v naší firmě malou interní prezentaci na téma HA LAMP cluster v délce cca 2 hodiny. Cílem prezentace bylo obeznáméni kolegů s principy vysoké dostupnosti našeho řešení. V rámci prezentace jsem vysvětlil základní obecné pricipy clustrování a sestavování clusteru. Samotnou implementaci clusteru jsem předvedl na sestavení dvouuzlového clusteru, který má sloužit jako clustrovaný LAMP server. Cílem clustrování je obecně zabezpečit vysokou dostupnost služeb, zvyšovat spokojenost zákazníků a znižovat náklady spojené z výpadkem služeb.

Continue reading

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

Úkládání dat a zajištění jejich bezpečnosti a dostupnosti je docela složitá disciplína a věnuje se jí hodně lidí. Existuje spousta řešení jak ukládat data – některá jsou levná, jiná drahá, některá spolehlivá a jiná zase nespolehlivá (přičemž spolehlivost a cena spolu velmi často vůbec, ale vůbec nesouvisí).

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 24×7 bez možnosti větší odstávky. Rozpočet jsme měli omezený, požadavky relativně vysoké.

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 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.

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í 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 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ítť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ř