ARCHIV

Zkušenosti z instalace Mandrake 10.0 Official na AMD Opteron

Na našem dvouopteronovém serveru (více např. zde) jsme se rozhodli otestovat ostrý provoz několika dostupných distribucí. Jednou z distribucí, kterou jsme vyzkoušeli byl Mandrake 10.0 Official pro AMD64.

24.8.2004 08:00 | Petr Houštěk | Články autora | přečteno 21711×

Příprava

První metou, kterou jsme si vytyčili, byla minimální instalace systému s funkčním urpmi na zvolený (poněkud exotický) diskový layout. Dalším krokem pak instalace updatů a připravení systému do stavu, kdy je možné začít instalovat a konfigurovat zamýšlené služby.

Popišme nejprve zvolenou strukturu diskových svazků. V serveru nemáme hardwarový RAID řadič, použijeme proto služeb softwarového raidu v kernelu Linuxu. Root svazek umístíme na RAID-1 pole vytvořené přes první partice dvou identických SCSI disků (/dev/sda1, /dev/sdb1). Následují swap oddíly. Ty bohužel není možné umístit na softwarový RAID-1, neb by to v jistých situacích mohlo vést k deadlocku v kernelu (došla fyzická paměť, je třeba některé stránky odswapovat, k tomu ovšem MD driver potřebuje alokovat jisté množství paměti, která ale není). Pro swap tedy ponecháváme oddíly /dev/sda2 a /dev/sdb2.

Na zvláštní svazky umístíme /home a /var. Kvůli flexibilitě a snadnému zálohování (snapshot) ovšem nechceme místo pro tyto svazky alokovat staticky v partition table použitých disků, místo toho hodláme využít výhod další vymoženosti linuxového jádra – LVM. Zbývající místo na obou SCSI discích tedy přiřadíme particím, /dev/sda3 a /dev/sdb3, přes necháme vytvořit RAID-1 pole a toto pole využijeme pro LVM. Založíme jednu volume group (pojmenovanou vg0) a v ní pak logical volumes pojmenované home a var. Ve vg0 ponecháme místo na případné založení dalších (dočasných) svazků, zvětšení stávajících a provádění záloh pomocí LVM snapshotů. Třetí disk v systému je velký IDE disk určený pro zálohy a uložení objemných a nepříliš často používaných dat. Zde se již nic zajímavého nekoná, jednoduše vytvoříme několik oblastí a přímo je použijeme.

Důvody tohoto rozdělení jsou mimo téma článku (je zde ovšem k dispozici diskuse). Pojďme se podívat, jak se tento neskromný požadavek podařilo realizovat v Mandrake 10.0.

Instalace

Mandrake 10.0 Official pro AMD64 lze pořídit zakoupením krabicové verze nebo stažením oficiálních obrazů instalačních médií, které jsou dostupné pro členy Mandrake klubu (silver a vyšší). Instalace tedy probíhala z CD. Na začátku instalace jsme si mohli vybrat z grafické, textové, nebo expertní grafické instalace.

Vzhledem k tomu, že na serveru nemáme myš, jsme se rozhodli pro textovou instalaci. Ta ale úplně selhala při rozdělení disku, resp. textová verze programu DiskDrake se odmítla přes opakované pokusy spustit. Nezbylo tedy než zvolit grafickou expertní instalaci. V té se již program na rozdělení disků spustil. Po vytvoření root oddílu na RAID-1 instalátor oznámil, že z RAID oddílu nelze bootovat a musí se vytvořit oddíl pro /boot.

Toto samozřejmě není nutné (lilo má výbornou podporu pro bootování přímo z RAIDu). Nicméně dočasně jsme instalátoru vyhověli a jeden oddíl pro swap jsme tedy změnili na /boot oddíl. Po rozdělení disku můžete jednotlivé oddíly nechat zformátovat. Pokud ale máte speciální požadavky (např. u XFS velikosti inodů), nezbývá než přejít do textového režimu a přeformátovat (teprve po formátu instalátorem je program mkfs.* k dispozici) oddíly s požadovanými parametry. Po formátu a výběru kompletů balíků (zde jsme odznačili vše a nechali pouze základní instalaci s urpmi) začal systém instalovat balíky. Během instalace ale došlo k přerušení kopírování. Následně nezbývalo než restartovat celý instalační proces.

Při opakování instalace ale během vytváření LVM systém ohlásil chybu "Illegal division by zero", DiskDrake zkolaboval a odmítal se znovu spustit. Po peripetii, kdy jsme se snažili celý proces s různými obměnami opakovat a najít, kde je chyba, jsme se nakonec vzdali myšlenky vytvořit LVM už během instalace a celý systém jsme nainstalovali (tentokrát bez větších problémů) na kořenový svazek.

Po startu nově nainstalovaného systému již nic nebránilo ručnímu vytvoření LVM. Nejdříve jsme zinicializovali /dev/md1 jako physical volume a následně jsme na něm založili volume group vg0.

pvcreate -M2 /dev/md1
vgcreate -M2 vg0 /dev/md1
vgchange -a y

Nakonec jsme vytvořili oddíly home a var na vg0 a vytvořili na nich filesystém.

lvcreate -L 13G -n home vg0
lvcreate -L 13G -n var vg0
mkfs.xfs -L home -i size=512 /dev/vg0/home
mkfs.xfs -L var -i size=512 /dev/vg0/var

Dále stačilo upravit /etc/fstab a přesunout stávájící obsah /var do vytvořeného svazku. Další problém ovšem nastal v okamžiku, kdy jsme se rozhodli zbavit devfs. (Tento vynález nikdy pořádně nefungoval, v kernelu je označen jako obsolete a bude v budoucnu pravděpodobně nahrazen mechanismem udev. Na serveru navíc nepřináší prakticky žádnou výhodu.) Po vypnutí devfs se ale LVM neaktivovalo. Pole by měla být aktivováno skriptem /etc/rc.sysinit. Po zběžné diagnostice jsme zjistili, že v tomto skriptu dochází při absenci devfs k volání příkazu vgmknodes, který končí s nenulovým návratovým kódem, takže iniciační příkaz vgchange -a y se již neprovede. Po odstranění zbytečného vgmknodes se pole již aktivovalo. Zarážející na tom ovšem je to, že se patrně nikdo v rámci QA testů neobtěžoval tuto možnost (tj. LVM bez devfs) vyzkoušet, přestože skripty i dokumentace se tváří, že by to fungovat mělo.

Updaty, zdroje balíčků

První mety jsme tedy po mírných zaváháních dosáhli a můžeme se pustit do konfigurace urpmi a updatů. Protože binární balíčky Mandrake 10.0 Official pro AMD64 nejsou k dispozici na žádném mirroru (pokud jsem něco nepřehlédl, tak ani v MandrakeClubu), a protože není možné při každé instalaci měnit v serveru CD disky, zkopírovali jsme všechny balíčky ze všech CD do jednoho adresáře a příkazem genhdlist ho zpřístupnili jako lokální urpmi repository. Z konfigurace urpmi jsme odstranili CD zdroje přidané při instalaci a nahradili je pouze tímto lokálním skladištěm a oficiálními updaty ze sítě (použili jsme český mirror mandrake.contactel.cz). Update proběhl téměř bez problémů. Téměř proto, že první volání urpmi --update --auto-select selhalo s blíže nespecifikovanou chybou. Opakované spuštění nicméně proběhlo úspěšně a chybu se již nepodařilo reprodukovat. Poté, co jsme navíc ručně updatovali kernel, rebootovali systém a povypínali nepotřebné služby a vymoženosti typu autodetekce HW, je i druhá meta dosažena.

Kernel

Čas na první vážnější test :) Zkusme na novém systému rekompilovat kernel. Děláme to víceméně ze zvědavosti, jestli se to podaří, ale při troše snahy dáváme dohromady i několik racionálních důvodů -- např. se chceme zbavit initrd, zakompilovat MD driver staticky (bez toho nefunguje autodetekce raid svazků), odstranit řadu věcí, která je v distribučním kernelu zakompilována staticky a nebudeme je potřebovat atd. Nicméně flamy na téma "proč (ne)kompilovat kernel" a tutoriály "jak kompilovat kernel" necháme povolanějším, zde pouze konstatujeme, že tento test Mandrake zvládl na výbornou. Stáhli jsme aktuální verzi zdrojáků distribučního jádra, nakonfigurovali, zkompilovali (make -j 4), nainstalovali, opravili nešvar s odděleným /boot svazkem ještě z instalace a rebootovali. Boot přes lilo z RAID-1, autodetekce RAID svazků kernelem i všechna další magie spojená s bootem systému proběhla správně. Jediný zádrhel nastal, když jsme chtěli 3rd-party driver bcm5700 pro Gbit síťovky nahradit kernelovým ovladačem tg3. Nástroj pro konfiguraci sítě totiž (patrně skrze lspcidrake) trpí utkvělou představou, že s jiným modulem než bcm5700 naše síťovky fungovat nebudou. Nenašli jsme způsob, jak tento nástroj přesvědčit o opaku, provedli jsme tedy přímý zásah do souboru /etc/modprobe.conf. Při ručním odstranění starého modulu z kernelu navíc došlo k chybě (o důvod víc, proč použít tg3 driver), pro jistotu jsme tedy systém ještě rebootovali.

Služby

Po úspěšné kompilaci kernelu jsme začali testovat základní síťové služby. Některé služby byly již zkonfigurované a pracovaly bez vážných problémů, jiné naopak začaly fungovat až po určitých zásazích. Mezi námi testované základní serverové služby, které běžely po instalaci a základní konfiguraci zcela bez problémů, se zařadily:

• mail transport agent postfix 2.1.0
• ftp server vsftpd 1.2.1
• ssh server openssh 3.6.1p2
• super server xinetd 2.3.13
• current version system cvs 1.11.11
• dns server bind 9.2.3

Základní konfigurace těchto démonů byla postačující, potěšilo, že bind byl spouštěn pod neprivilegovaným uživatelem a konfigurace počítala i s během v chrootovaném prostředí (i když to si musí administrátor připravit sám).

Na druhou stranu některé služby zcela bezproblémové nebyly. Např. obě testované databáze - MySQL a Postgresql provázely jisté potíže. Konkrétně při instalaci Postgresql selhala inicializace databázového ringu. Při následné ruční inicializaci proběhlo vše jak má a databáze fungovala bez potíží. MySQL po instalaci sice fungovalo, ale pouze s vestavěnou konfiguraci -- v distribuci není pro MySQL žádný konfigurační soubor, třeba i zakomentovaný, což je přinejmenším pozoruhodné.

Jednou z klíčových serverových služeb je nepochybně Apache http server, v Mandrakelinuxu maskován pod patetickým názvem Advanced extranet server nebo též ADVX. Cílem tohoto projektu je připravit apache a související software v podobě, ve které je instantně použitelný ke všem možným i nemožným funkcím. To obnáší poněkud specifickou kompilaci s maximálním využitím modulů, modulárně pojatou konfiguraci, ve které se řada věcí ovlivní pouhou (ne)přítomností určitého souboru. Tolik nezaujatý popis. (Kdybych měl ADVX popsat zaujatě, zeptal bych se, proč když všichni distributoři dělají s apachem v podstatě to samé, jedině MDK považuje svůj přínos za natolik významný, že kvůli tomu vymýšlí nové jméno. Marketing je prostě všude ...)

Při testu na několika virtuálních serverech se statickými stránkami, dynamicky generovanými stránkami pomocí php, mod_perl a generických cgi skriptů, docházelo bohužel k pádům jednotlivých obslužných workerů a při jednom testu dokonce celého serveru. Chyby se projevily při velké zátěži a jejich kořeny byly různé, od konfiguračních nedostatků až po relativně závažné memory leaky v kódu. Většinu se podařilo odstranit, nicméně z komunikace s vývojáři bohužel vyplynulo, že jejich prioritou je nyní příprava verze 10.1 a podpora (aktuální oficiální verze) je až na druhém místě (nejedná-li se o bezpečnostní updaty, ty v Mandrakelinuxu fungují velmi dobře).

Software mimo distribuci

Vzhledem k faktu, že Mandrakelinux je výběrem software spíše desktopově zaměřená distribuce, některý serverový software v oficiálních zdrojích chybí. Jako první člověk vyzkouší contrib. Ten má ale řadu nevýhod -- např. nejsou dostupné binární contrib balíky pro AMD64. Dále Mandrake pro contrib neposkytuje v podstatě žádnou podporu a kvalita se různí balíček od balíčku. Existují i další neoficiální zdroje, ale protože AMD64 je stále spíše exotičtější platforma, většina těchto zdrojů je kompilovaná pouze pro i586. Lze také (v určitých případech s problémy) rekompilovat SRPM balíky určené pro jiné distribuce. Pokud se člověk vzdá balíčkovacího systému, může získat software přímo z mainstreamu. Kupodivu je to v některých případech jednodušší a rychlejší cesta než rekompilace contrib balíků a jejich následné ladění.

Ze softwaru mimo oficiální distribuci jsme použili např. GNU Arch (balík se jmenuje tla), který jsme bez problémů rebuildovali z contribu. Naopak tomcat5 z contribu byl téměř nepoužitelný a místo hledání jeho nedostatů jsme raději použili mainstreamovou verzi. Pro testovací účely jsme chtěli nainstalovat databázi FirebirdSQL. Pro tu ale téměř neexistují balíky a navíc v současné verzi (než bude dokončen a integrován projekt Vulcan) funguje Firebird v SuperServer režimu jen ve 32bitové podobě a využívá jen jediné CPU. S těmito omezeními se ho ale z mainstreamového balíku podařilo bez větších zádrhelů zkompilovat a zprovoznit. Zde se ukázala výhoda distribuce, která je pojatá jako tzv. bi-arch (jsou přítomné nástroje a knihovny současně pro provoz AMD64 i x86 aplikací).

Java

V distribuci je přítomná Java RE i SDK ve verzi 1.4.2 od Blackdown, což byla v době vydání distribuce jediná dostupná nativní kompilace Javy pro AMD64. Bohužel nejde zatím o release a je to bohužel znát, při provozu větších aplikací (jako např. již zmíněný tomcat) docházelo k velkému množství chyb. Tento JRE se sice dá použít na nativní 64bitový běh různých java-appletů v 64bitové mozille, pro serverové aplikace je v podstatě nepoužitelný. Se standardní 32bitovou verzí SUNu tomcat běžel bez problémů.

Závěr

Nasazení Mandrakelinuxu na AMD64 server má své plusy i mínusy. Jeho nespornou výhodou je již poměrně vyspělá rpm nadstavba urpmi, která velmi usnadňuje správu instalovaného software. Pro serverové použití určitě není výhodou jeho krátká životnost (vývojový cyklus je dlouhý 6 měsíců) a z toho se odvíjející ne zcela propracovaná podpora (oficiálně trvá jeden rok). Četnost výskytu různých problémů, které je nutno ručně řešit, je v porovnání se serverovým standardem poměrně vysoká. Možná je to tím, že otázku, zda vložit do distribuce ne zcela odladěný a otestovaný software, nebo zůstat u starší verze (případně software zcela odstranit), řeší často u Mandrakesoftu tím prvním způsobem. Na druhou stranu potěší velmi aktuální software a rychle fungující bezpečnostní updaty.

Verze pro tisk

DISKUZE Hmm... servery 25.8.2004 04:27 Petr Zajíc   Re: Hmm... servery 25.8.2004 16:28 Jan Houštěk Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.