Blog Marcina Bojko

Linux,Windows,serwer, i tak dalej ;)

Archive for Czerwiec 2009

The Day The Music Died

Nie ulega wątpliwości że dzisiaj pożegnaliśmy znaczący fragment beztroskich lat 80-90. Rocznik 73 zachwycał się „Thrillerem‚ w szkole podstawowej, liceum przywitało nas przy dźwiękach ‚BAD„, dźwięki z ‚Dangerous‚ towarzyszyły nam na półmetku, matura bezdyskusyjnie związana jest z ‚HIStory: Past, Present and Future Book I‚.

Furda skandale, furda ‚Neverland’.

The Day The Music Died

Written by marcinbojko

26 czerwca, 2009 at 10:28

Napisane w Uncategorized

Ciekawa dyskusja projektowa

Przy okazji wątku dyskusji na GL przypomniała mi się krótka dyskusja w temacie wykorzystania nowszych kontrolerów macierzowych i redundancji jako takiej w pewnym projecie.

Warunki dyskusji były następujące: grupa świeżo upieczonych „projektowych” techników, workstacje pracujące pod kontrolą systemu Linux, wykorzystujące dwa identyczne (co do rozmiarów) dyski na których określone partycje systemowe (/) były zabezpieczone RAID 1, tzw. software’owym (mdraid) . Na tychże workstacjach kręciły się silniki bazodanowe PostgreSQL’a, niewielkie bazy, niewielka ilość operacji.

Argumentem z jakim wyskoczył któryś z techników było:

T – Technik

J- Ja

T: A dlaczego nie wykorzystać RAID’ów które wbite są w kontrolery nowoczesnych płyt głównych – prawie każda z nich posiada coś takiego na poziomie hardware’owym’?

J: No cóż, proszę sobie wyobrazić sytuację – pada płyta główna, automatycznie traci Pan dostęp do danych na dyskach.

T: Dlaczego?

J:Bo aby dostać się do danych musi Pan posiadać IDENTYCZNĄ płytę główną, z IDENTYCZNĄ konfiguracją oraz często z IDENTYCZNĄ wersją BIOS. Czyli, przy okazji dowolnej awarii płyty głównej traci Pan dostęp dysków, danych a także do backupów które to na tych dyskach istnieją na oddzielnych partycjach.

T:No tak, to rzeczywiście problem. Ale, w takim wypadku, dlaczego nie skorzystać ze śmiesznie tanich kontrolerów macierzowych sprzedawanych po klasyczne 30 zł, identycznych co do marki.

J: Jasne. Pomysł w istocie przedni, ale proszę policzyć. Ma pan 3000 workstacji, do każdej trzeba dokupić kontroler za 30 zł. Zakładając że średni czas życia workstacji to 3 lata, po 3 latach trzeba wymienić około połowy tychże kontrolerów, które należy zakupić na początku projektu – za 2 miesiące może ich nie być. Teraz pomnóżmy to przez siebie – w ciągu miesiąca musimy wydać 135,000 PLN, które  zamrozimy na czas trwania projektu.

T: No ale to się opłaca – wydajność takiej workstacji będzie o poziom wyższa niż na RAIDz’ie software’owym, warto zainwestować prawie 140 tysięcy w kontrolery.

J:Wie Pan, możemy to sobie bardzo łatwo sprawdzić za pomocą iozone, zawsze mnie jednak uczono że nie ma macierzy software’owych ani hardware’owych, wszystkie są software’owe, tylko pytanie na jak niskim poziomie operacji tenże software pracuje 😉

Tajemnicą bowiem poliszynela jest iż tanie, wbite w płyty główne kontrolery, do większości operacji przeliczania redundancji (RAID5) wykorzystują procesor systemowy. Cała idea takiego ‚przyspieszenia’  idzie wtedy w diabły. Bezpieczeństwo przechowywania danych na tak utworzonych macierzach, zależnych w 100% od typu płyty głównej (i wydajności CPU) jest bardzo kiepskim pomysłem.

Written by marcinbojko

25 czerwca, 2009 at 17:39

Napisane w Uncategorized

Tagged with , , , ,

Dzień Ojca – najlepsza pobudka o 6:37 jaką miałem w życiu.

Oczywiście po to aby wręczyć poniższe DZIEŁO. Niniejszym prezentuję społeczeństwu 😉

laurka

Written by marcinbojko

23 czerwca, 2009 at 18:25

Napisane w Uncategorized

Zmiana nastroju – Kimchi na pokładzie.

Zmieniając lekko nastrój i tematykę bloga – kimchi jest szalenie popularną potrawą/dodatkiem pochodzenia koreańskiego. Jest dla Korei bardziej narodowa od naszego schabowego, pierogów ruskich, francuskich żab i ślimaków razem wziętych 🙂 Serwowana jako dodatek do każdego nieomal dania, dostępna w licznych regionalnych odmianach (każdy region, baa każda wioska ma swoją strzeżoną recepturę) – niesamowicie pikantna, pyszna i zdrowa. Doczekała się swoich odmian: zupy z kimchi, oraz ryżu smażonego z kimchi

Historycznie – przygotowywana jako źródło witamin na długie koreańskie zimy – dzisiaj stała się po prostu całorocznym dodatkiem. W Polsce dostępna w miejscach nielicznych, przeważnie w restauracjach orientalnych, różniąca się smakiem (od przepysznych po zupełnie niejadalne). Bardzo łatwa do zrobienia, warunkiem jej smaku jest jednak długie „dojrzewanie” jak by powiedzieli niektórzy.

Przepisów w sieci jest mnóstwo, jeden z najpopularniejszych każe dam kapustę pekińską wymoczyć w solance (9 części wody/1 część soli), solidnie w niej ‚umyć’, odsączyć, natrzeć solą i odłożyć na ok. 2 godziny.

DSC01411DSC01418

W międzyczasie przygotowujemy drugą część: dwie długie białe rzodkiewki tniemy na wąskie paski. Do tego dodajemy solidny kawałek imbiru pokrojony w maleńkie kawałeczki. Dodajemy pokrojoną cebulę dymkę (szczypiorek z braku laku), jak na poniższym obrazku.

CDSC01413

Przygotowujemy pastę paprykową – dwie szklanki tejże solanki, dosypujemy do niej tyle słodkiej papryki w proszku aż zrobi się z tego gęstawa breja. Do tejże pasty dodajemy pół (słowo – nie więcej) torebki ostrej papryki chili  w proszku. Całość brei mieszamy z przygotowanymi wcześniej dodatkami tworząc coś takiego:

DSC01421

Ostatnim etapem jest przygotowanie do ‚kiszenia’. W dużym (sugeruję koniecznie niemetalowym) naczyniu układamy warstwami: warstwę odsączonej i opłukanej z soli kapusty pekińskiej, na to warstwę naszej ‚brei’. Warstwami aż do wypełnienia naczynia. Dociążamy talerzem i czymś ciężkim (jak widać, poniżej w sposób tradycyjnie staropolski 🙂

DSC01428

Teraz przychodzi czekanie – odstawiamy naszą zdobycz na minimum tydzień (tak, tak siedem dni) do chłodnego miejsca – lodówka może być. Po tygodniu wyjmujemy całe, przygotowane warstwowe ‚placki’, tniemy je na wąskie paseczki i w takiej formie do słoików i znowu do lodówki.

Jak to jeść? Kimchi jest nieco za ostre aby jeść je samo – genialnie jednak sprawdza się jako dodatek do ryżu z warzywami, mięskiem, makaronów, kanapek na zimno i tym podobnych zestawień – wszędzie gdzie występuje jako dodatek. Zdarzało mi się je jednak jeść z samym pieczywem – cóż mogę powiedzieć, smakuje rewelacyjnie 😉

Written by marcinbojko

21 czerwca, 2009 at 17:38

Napisane w Uncategorized

Tagged with ,

DRBL – z czym się to je, część II – instalacje OS

Jak działa to w praktyce ? Otóż bardzo fajnie. System jest wyposażony w odpowiedni skrypt który sam pobierze i zainstaluje mini-instalacje powyżej zebranych dystrybucji. Oznacza to – iż chcemy np. mieć możliwość instalacji Debiana (Etch i Lenny) zarówno w wersji 32 jak i 64 bitowej, uruchamiamy odpowiedni skrypt (net-install) z parametrem Debian i za chwilę możemy cieszyć się dodatkowymi opcjami dodanymi do menu PXE.

Dalsza część usprawniania instalacji to oczywiście parametry przekazywane do instalatora w trakcie jego uruchomienia. Możemy wybrać jedno z właściwych repozytoriów Debiana, przekazać parametry instalacji …. lub możemy skorzystać z w pełni zautomatyzowanych systemów instalujących (FAI dla Debiana, AutoYAST dla SuSE)

W czasie pracy najwięcej czasu poświęciłem projektowi AUTOYAST, który dostępny jest dla systemów SuSE (openSuSE, Novellowe SLED i SLES). Ten w pełni dojrzały projekt pozwala nam na totalną i pełną konfigurację instalowanego systemu przez zestaw dyrektyw i parametrów zapisywanych w składni XML. Mamy wpływ na każdy etap procesu instalacji – zaczynając od parametryzacji dysków, partycji, filesystemów, rozmiarów instalacji, wybranych pakietów, startujących usług, konfiguracji wszelakich usług, uruchamiania dodatkowych skryptów (zarówno w fazie PRE jak i POST instalacyjnej), na integracji z LDAP i wykorzystaniu informacji z tegoż systemu do parametryzacji wszelakich instalacji.

Ba, dzięki podziałowi na fazy PRE i POST możliwe są takie rzeczy jak przygotowywanie własnych modułów do obsługi sprzetu (np. nietypowych lub nieobsługiwanych standardowo kart sieciowych, dostarczenie ich w fazie PRE a następnie kontynuacja instalacji w fazie POST)

System posiada własny edytor, dla zaawansowanych zostaje wersja XML do edycji ręcznej. Narzędzie jest bardzo wygodnie – wynikiem procesu projektowania jest plik XML którego lokalizację przekazujemy za pomocą PXE i DRBL’a do instalatora. Przygotować możemy nieskończoną ilość takich profilowanych instalacji dołączając je kolejno do menu instalatora.

Przykładowa dyrektywa instalacji stosowanych przeze mnie:

label Instalacja
# MENU DEFAULT
# MENU HIDE
MENU LABEL Instalacja zaplecze v.2.xx
# MENU PASSWD
TEXT HELP
* Instalacja systemu operacyjnego SLED 10 SP1
ENDTEXT
kernel linux
append initrd=initrd.200902 ramdisk_size=128000 splash=silent showopts install=http://172.16.0.1:/sled server=172.16.0.1 serverdir=/sled autoyast=http://172.16.0.1/sled/autoyast-net-raid.xml language=pl_PL

Jak wygląda wydajność takiego rozwiązania? Systemy sprofilowane (SLED 10 SP1) na maszynach klasy Intel Celeron (1.8/2.0) z 1 GB RAM, z pełnym oprogramowaniem projektowym instalują się około 45 minut. Niesamowitym plusem takiego rozwiązania, przy zastosowaniu szybszych interfejsow Gigabitowych jest fakt, iż jednocześnie może trwać instalacja wielu maszyn. W testach przeprowadzanych przez nas do 5 maszyn jednocześnie spowolnienie instalacji było niewidoczne (sieć lokalna, interfejsy i switche gigabitowe).

Przy wzroście ilości maszyn do 10 na raz czas instalacji per wzrósł o ok.5 do 7 minut. Oznacza to, iż średniej klasy maszyna (desktop jako serwer) jest w stanie przeprowadzić około 80 instalacji dziennie w 8 godzinnym cyklu pracy. Zakładając możliwość dostawienie drugiego interfejsu – liczba wzrasta do 150 w cyklu 8 godzinnym.

Warto zaznaczyć iż instalacja jest totalnie bezobsługowa – można nawet nie wykorzystywać monitorów do obserwacji procesu. Prostym wpisem w autoyast całość instalacji kończymy shutdownem – oznacza to iż każda z maszyn które własnie go wykonały są gotowe do spakowania do pudełka lub wykorzystania w projekcie.

Rozwinięciem idei  instalacji bezdotykowej jest zastosowanie sieci serwerów DRBL jak na poniższej ilustracji:

Slajd18

Poszczególne serwery rozproszone w innych lokalizacjach (inny budynek, inne miasto, inny kraj) pozwalają na wykonywanie dokladnie tych samych czynności w oddziałach, używając tych samych (lub odpowiednio zmodyfikowanych korzystając z LDAP/AD) parametrów.

Za całość procesu synchronizacji odpowiadać może subsystem RSYNC skonfigurowany tak aby weryfikować i naprawiać ewentualne błędy za pomocą weryfikacji sum kontrolnych MD5.

Najciekawiej wygląda zarządzanie zmianą w tego typu projekcie – z racji niewielkich rozmiarów zarówno samego autoyast.xml , jak i poszczególnych pakietów wchodzących w sklad instalacji, aktualizację założeń instalacji, aktualizację pakietów instalacyjnych można przeprowadzić dosłownie w kilka minut.

W praktyce przesłanie samych założeń instalacji trwa około 2 minut w przypadku 6 dodatkowych rozproszonych lokalizacji. Gdy w grę wchodzą pakiety dodatkowe wykorzystujemy przetwarzanie równoległe – wiele jednoczesnych procesów synchronizacji (wykorzystujących fakt iż łacze serwera centralnego jest wielokrotnie bardziej wydajne niż łącza poszczególnych serwerów oddziałowych.

Ponieważ jednocześnie, oprócz samych opisow instalacji przesyłać można obraz wykonane za pomocą systemu Clonezilla sam DRBL okazał się doskonałym uzupełnieniem codziennej pracy systemowo-projektowej.

Wyobraśmy sobie projekt w którym z częstotliwością np. miesięczną zmieniają się obrazy instalacyjne stacji roboczych i nośników. Dystrybucja tychże na nośnikach DVD/USB okazywała się koszmarem – zawsze zdarzało się iż wersja jak została zainstalowana różni sie od wersji obowiązujacej. Dokładając do tego czas rozproszenie i przygotowania nośników okazało się to sporym problemem.

Rozwiązanie przyszło w postacji maszyny DRBL – zawsze dostępnej z tym samym menu co ostatnio. Zawartość obrazów mogła zostać zaktualizowana, instalator mógł wykonywać zupełnie nowe czynności, jednakże z punktu widzenia instalującego NIC się nie zmieniało. Zawsze witał go ten sam, widziany ostatnio obrazek 😉

Written by marcinbojko

20 czerwca, 2009 at 12:21

Amigowy dzień…

Ehhhh …. Za każdym razem jak szlag człowieka trafia warto wrócić w lata 80-90, dla bezpieczeństwa zdrowia psychicznego 😉

Written by marcinbojko

16 czerwca, 2009 at 19:43

Napisane w Uncategorized

Tagged with , , ,

Na miętowo…

Zawsze wydawało mi się że kolejność Linuxowa to: Debian …… dłuugo, dłuuuugo nic ……OpenSuse…….dłuuuuugo nic …. RedHat …… dziuuuura…… koniec 🙂

Zawsze wydawało mi się także że staroafrykańskie „Ubuntu” można przetłumaczyć jako ‚bo nie umiem zainstalować Debiana’ 😉 Zawsze wydawało mi się iż openSUSE na desktopy (zwłaszcza produkcyjne, korporacyjne, projektowe) z racji niemalże genialnego systemu autoyast, bardzo dobrego narzędzia do update’ów (libzypp i zypper), genialnej konsoli do zarządzania (YAST). Zawsze wydawało mi się że jest nieco przyciężkawy ale … trudno.

Do czasu aż odkryłem Mintahttp://linuxmint.pl/

Miętówka, w wersji 7 będąc zmodyfikowana wersją Ubuntu spowodowała mój opad szczęki i jęk zachwytu ‚To TAK miało wyglądać!”. Ktoś doprawdy w porządny sposób zadbał o renowację przyciężkawych motywów graficznych, ktoś spowodował że obsługa Minta jest niemalże tak prosta i banalna jak systemów Windowsowych. Intuicyjny installer, świetne zarządzanie pakietami (w wersji dla opornych, synaptic w wersji dla geeków), wykrywanie i obsługa hardware’u. Finalny jęk radości wywołało odnalezienie mojego modemu Iplusowego, propozycja wyboru sieci (PlusGSM/iPlus) i prośba o podanie PIN’u.

No zobaczcie sami:

Screenshot-3

Screenshot-4

Od paru dni Miętówka jest zainstalowana dosłownie wszędzie: na laptopie służbowym, na laptopie żony, na maszynie wirtualnej. To chyba będzie długa znajomość 😉

Written by marcinbojko

15 czerwca, 2009 at 20:58

Napisane w Uncategorized

Tagged with , ,

Walk ciąg dalszy.

Niestety, po 12 godzinach kernel wpadł w sidła błędu ksoftirqd – zajeżdzając pierwszy CPU prawie do 100%.  Rekompilacja kernela z wyłączeniem opcji kernel software interrupt ani ze zmianą częstotliwości zegara na 100Hz nic nie dała – procek zapchany, wszystko wykonuje się w dziwnie wolnym trybie.

Pozostaje jeszcze zabawa z samym vmwaretool – rekompilacja i zapychanie do kernela w trakcie.

Może ktoś ma jakieś pomysły?

Update 1: czwartek, 09:34

Z niewiadomych przyczyn ksoftirqd przestał zabijać jeden z procesorów, utylizacja spadła do 10 %.  Niestety, kernel 2.6.28.10 oraz cała rodzina 2.6.29.x ma jakieś problemy z kolejką esfq, co wyklucza je na razie z zastosowań produkcyjnych. Klasyczny impas 😉

Update 2 czwartek 16:43

Przygotowanie kernela 2.6.29.1 z łatą na esfq/imq/layer7/conntrack i paroma innymi rzeczami (reiserfs4), iptables 1.4.1.iproute powiodło się w końcu. Rzutem na taśmę pomocny okazał sie pakiet xtables-addons w wersji prehistorycznej (od 1.08 w górę iptables 1.4.1 nie jest obsługiwane).

Kernel skompilowany, paczki przesyłają się na wirtualkę testową. Na produkcyjną to chyba ze dwie doby później, jak poświateczny szał opadnie 😉

Update 3 czwartek 23:09

Walka z iptables zakończona, maszyna wydaje się chodzić stabilnie. 12 godzin testów co najmniej 😉

Update 4 piątek 9:30

Przeniesienie ruchu na maszynę z kernelem 2.6.29.1 od razu powoduje uaktywnienie ksoftirqd na 100%.

Written by marcinbojko

9 czerwca, 2009 at 20:26

Napisane w Uncategorized

Hop siup – ESXi to nie przelewki.

A zaczęło się niewinnie – od przeniesienia P2V (Physical to Virtual) jednego z głównych serwerów na ESXi 3.5 – patrz poprzedni post. W zachwycie i bielmie na oczach zlekceważyliśmy fakt iż podnoszenie wirtualki nieco trwało, a i sam skrypt od regułek ładował się prawie 4 minuty. Drugim sygnałem było zużycie prawie 100% 4 wirtualnych rdzeni procesora w maszynie-gościu.

Krótki test hdparm -t pokazał wstrząsającą prawdę – 14 MB/s. Transfer na poziomie zombie.

Co jest nie tak? Podejrzewaliśmy (i słusznie) poprzednią wersję VMware Tools – która to lekceważąc nas całkowicie odinstalować się nie dała. Nowa wersja zasugerowała źle przygotowany kernel (PIII max, a tu Xeony na pokładzie) i rozłożyła wirtualne kopytka. Jako że czasu już najwyższy przejść na kolejnego customa – wyrok padł na 2.6.25.13 z projektu Linuxbox.

Pierwotna wersja (bez przygotowanych IMQ, z schedulerem deadline, bez iptables i iproute) pokazała na hdparmie 54 MB/s. Sukces jest – ponad czterokrotne przyspieszenie operacji dyskowych. W tej chwili leci wersja właściwa (ze 30 minut kompilowania zostało), później iptables i iproute.

Zdam relacje na żywo 😉

Update 1 – 21:30

Kernel 2.6.25.13 custom edition przygotowany, iptables+iproute2 skompilowane. Maszyna po restarcie na 2 rdzeniach wyciaga już 74 MB/s i 456 MB/S dla cached readings.

To już pozwala przenieść z powrotem usługi z fizycznej na wirtualną. Jutro na wykresie performance zobaczymy jak je minął dzień z luserami 🙂

Written by marcinbojko

8 czerwca, 2009 at 20:14

Napisane w Uncategorized

Tagged with , , ,

Z cyklu – u nas na Allegro ;)

Zadziwiające jakie okazje czasami (a nawet często) można trafić na naszym wszędobylskim portalu aukcyjnym. Jak widać poniżej – całkiem fajna konfiguracja:

  • dwa procesory (Xeon 3.0 Mhz 512MB cache)
  • dwa zasilacze (redundantne)
  • Dwie karty sieciowe (100 Mbit i 1 Gbit)
  • 6 dysków 72GB UW320 SCSI
  • kontroler macierzowy SmartArray 6400+BBWC
  • 4096 MB RAM z ECC, hot spare i RAID ON MEMORY
  • redundantne wiatraki 🙂

200906055672009060556320090605564

Uwierzycie – 810 zł? VMware ESXi 3.5 hula pięknie, już jedna z maszyn przeniesiona na wirtualkę. Jestem pełen podziwu … sam dla siebie 😉 A waży skubaniec coś ponad 45 kg 😉

#########################

Daily Coffee Show 😉

DSC01345

Written by marcinbojko

6 czerwca, 2009 at 17:02

Napisane w Uncategorized

Tagged with , , ,

%d blogerów lubi to: