Vlákno názorů k článku Nastavení důležitých služeb ve SLES 10 od Martin Prokš - Zdravím Tak tyhle dva články mě teda nadšením nenaplňují....
-
Martin Prokš (neregistrovaný)Zdravím
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... -
anonymníMa to par balickov navyse, hlavne pre vedcov https://www.scientificlinux.org/about/customize. Podporu tomu robia minimalne 2 chlapici, kt. su zamestnani u Fermi labs na tuto cinnost, takze vacsinou opravy su velmi rychlo. Maju aj fastbug repository, kde su opravy hned bez ich testovania. Neviem to porovnat s CentOS, nikdy som nepouzival. Len ma napadlo, ze ked uz to pouzivaju ako cluster na vypocty, tak to ma priznacny nazov :-) a je to ten ich RHEL.
-
anonymníAsi bychom mu řekli, že parametr
RUN_PARALLELv souboru/etc/sysconfig/boot, který tohle řídí, má ve svém popisu výslovně "Run all scripts or rather start/stop all services which are independent from each other in parallel." Taky bychom podotkli, že se to dá (ó, jak překvapivé když na to je parametr :-)) vypnout, že/sbin/insservvypočítává závislosti, kterými se pak spouštění služeb řídí (man insserv), želess /etc/init.d/READMEaman startparby mu také leccos řeklo, že zárukou pro nahození síťové služby je řádek na způsob# Required-Start: $networkv souboru/etc/init.d/skript, že by bylo možná lepší udělat initskript s mountem pronoautosíťové oddíly a že jestli mu něco blbne (tohle by se dalo tak brát), má nám vynadat v Bugzille. ;-) Protože jinak nikdo nic neopraví... -
anonymníJak jsem psal, šetří se jak se dá. Takže systém byl nakoupen v režimu organizace "výzkumu, vývoje, školství", nebo jak je ta škatulka pojmenovaná, přes nějaké středisko multilicensí vysokých škol. Z úhlu pohledu financí a právničiny je to OK, protože jsme taková organizace. Ale vše jde přes to středisko multilicensí a tam je "komunikační špunt". Už jsme nad tím zlámali hůl.
Ad distra, Scientific Linux neznám (možná kluci jo), CentOS je jeden ze 3 kandidátů na nahražení toho SLES po novém roce. Nejradši bych tam já osobně viděl RHEL a vydupat si tentokrát přímý nákup s placenou podporou na 3 roky. Ty aplikace jsou pro něj psané (většinou je uváděný doporučený OS RHEL a SLES) a máme s ním dobré zkušenosti. Ostatní je o něco větší riziko že někde zase bude problém.
