Tak tyhle dva články mě teda nadšením nenaplňují. Ani tématem, ani zpracováním. Dovolím si zde uvést pár praktických postřehů z mého úhlu pohledu.
Podle mého názoru je SLES 9 a SLES 10 distro výborné pro desktop. Server je z toho spíše z nouze ctnost, tak jako je uvedeno v těch předchozích článcích.
Proč si dovoluju tak hanebná slova?
Jsem adminem "jen tak bokem" na našem oddělení ve firmě, která se mimo jiné zabývá technickými výpočty hlavně prouděním kapalin + pevnostní výpočty. Má hlavní náplň je výpočtář, servery na kterých počítáme spravuji jen tak bokem ještě se dvěma kolegy ve stejném režimu - nejsme IT specialisté na supr výši. Servery máme rozhozené do několika clusterů. PC 32bit cluster na Fedoře (dnes ale již zastaralý, rušíme ho), cluster 8x IA64-4CPU s RHEL, cluster 10x x86_64-4CPU dualcore na SLES 9 a 10. Na lokálech na peckách mají lidi různá distra (včetně Suse 10), drtivá většina ale jede na MS Windows a k serverům přistupuje přes Cygwin X server + ssh (chvála bohu, na widle máme ve firmě jiné dva nešťastníky + většina lidí je schopna si je rozumně opečovávat dlouhodobě sama).
Suse se strašně powidlilo (a z posledních Fedor mám také trochu strach). Grafické krásné fičurky, YAST, paralelizace služeb při spouštění, ... Pěkné to jo, ale tak na ten desktop, nebo singl server ala DB, Apache, SMB, ... Ale ne na cluster který musí být HOMOGENNÍ, CENTRÁLNĚ SPRAVOVANÝ (nejlépe pomocí scriptů spouštěných přes ssh), SE ZAJIŠTĚNÝM POŘADÍM SPOUŠTĚNÍM SLUŽEB (to nám momentálně pije krev nejvíc) a VŠEOBECNĚ KAMENNĚ SE DRŽÍCÍ ZABĚHLÝCH STANDARDŮ NE JEN DISTRA, ALE UNIXU OBECNĚ.
My jsme v situaci, že počítače počítají distribuované výpočty. Každé jedno vlákno výpočtu žere spoustu CPU i RAM a všechna vlákna mezi sebou komunikují. Typicky na 1 CPU běží jedno vlákno výpočtu a žere 1 až 3 GB RAM a komunikuje s ostatními vlákny na dalších CPU napříč stroji. Trošku jiná představa paralelizace než mají lidi od DB, Apache nebo i někteří fyzici a matematici z jiných oborů. Člověk spustí výpočet, řekne že chce 10procesů a ono se to spustí na třeba 2 mašinách a jede to nad společnými daty a komunikuje to spolu přes myrinet. Všechny mašiny jsou v rámci clusteru stejné (až na síťové nastavení a tak) aby na nich vše běhalo stejně. Uživáci přes NIS, home NFS, přístup ssh, scp.
Debian: není podporován výrobci komerčního výpočetního SW a lámání distra je příliš časově náročné, moc knihoven (verzí) v nekompatibilní verzi.
Fedora: Není přímo podporována výrobci SW, ale lze dost snadno najít verzi která jde snadno zlámat. SW je většinou psaný pro RHEL a SLES, tak se kouknout na verze klíčových knihoven a najít příslušnou Fedoru a ohlídat si to... Drží standard ve smyslu startovacích scriptů, administrace přes text a scripty v pohodě, UnionFS také lze dobře, ale nedrží kamennost. Občas nějaká knihovna je moc vpředu a jsou problémy s komerčními SW (nekompatibilita knihoven). Po odladění distra a jeho ostrého nasazení je potřeba být velmi opatrný s updaty, aby neujely knihovny moc dopředu a výpočetní SW s mnohem pomalejší frekvencí updatů (typicky 1x za rok) nepřestali chodit...
RHEL: SW je pro něj psán výrobci. Supr. Není moc co vytknout až na cenu a dobu podpory - respektive zase cena. Z těchto důvodů vedení zatlačilo na levnější variantu, vždyť víte, prachy hýbou světem, ušetříme desetikorunu i kdyby nás to mělo stát stovku...
SLES 9 a 10: SW je pro něj psán výrobci. Ale negativa. Jak sakra 100% spolehlivě nahodit NIS a NFS, když startování démonů jede přes nějakou binárku, která zajišŤuje paralelnost běhu... Kde je záruka, že se NFS začne mountit až když už je síť 100% nahozená? Ntpd to samé, vzdálený monitoringovací SW také potřebuje síť, NIS i NFS už před nahozením. Plus ta zatracená binárka nám znemožnila použít UnionFS pro homogennost / mezi nody. Plus kterého čerta napadlo rvát do /opt knihovny důležité pro systém? Vždyť /opt je pro věci mimo distro, které jdou extra a nedoržují unix rozdělení adresářů, ale jedou si na svém jednom adresáři (typicky ty výpočetní SW) a tak je vhodné to mountovat centrálně přes NFS...
Zastávám názor, že systém - extra na server ne - by neměl vyžadovat extra učení se odznovu všeho, ale držení se standardních postupů a pohlídat si jen security záležitosti a tak. Máme práce nad hlavu s těmi všemi komerčními SW + řešit HW (při tomhle počtu strojů je každou chvíli něco a i přes gold servis je to spousta času jen to telefonování + řešení infrastruktutry a trvalý rozvoj...) + řešit BFU problémy s linuxem (i výpočtáři jsou líní se učit cokoli o unixu když mají své Windows - ale pokusy s Win serverem u jednoho exota jim dokázali scestnost této myšlenky).
Asi tak se dívám na SLES a na distra pro servery vůbec...