Nie jest tajemnicą, iż uważam Microsoft za firmę, w której myśl inżynieryjna jest tłamszona przez część schizofreniczno-marketoidalną, co widać w ich kolejnych posunięciach. Brak jakiejkolwiek możliwości wpływania przez inżynierów na swoje produkty, częste zmiany zasad gry w połowie rozgrywki, paranoidalne trzymane się jedynie rynku USA (nie chcę nawet komentować wykastrowanego XBL w PL). Po kolejnej konferencji, na której widzę te same twarze „celebrytów-evangelistów” wiem, że nic się w tej sytuacji nie zmieni na dobre.

Tym, którzy nie widzieli – polecam, to niezły otwieracz oczu:

Rynek i chęć współpracy z produktami Microsoftu ratują dla mnie REALNI (nie ewangeliczni) MVP – ludzie zatrudnieni na co dzień w przeróżnych firmach, zajmujący się realnymi problemami, rozwiązującymi je i dzielącymi się tym z całym światem.

Swoją przygodę z Hyper-V zaczynałem od próby weryfikacji różnic pomiędzy produktami konkurencji – język Technetu to beznadziejna maszynowa nowomowa, która w żaden sposób nie wyjaśnia jak osiagnąć to co próbujesz. Śmiało moge powiedzieć iż siedziałbym jeszcze w epoce IT łupanego, gdyby nie kontakt z MVP – ludzmi, którzy częściowo bezinteresownie przeprowadzali nas przez meandry korporacyjnych zawiłości.

Obecnie, aby pozostać w obiegu (na bełkot Microsoftu szkoda mi czasu) sledzę:

• Mało przydatne:

System Center: Virtual Machine Manager – http://blogs.technet.com/b/scvmm/

W zasadzie tylko komunikaty o poprawkach i opisy rozwiązań problemów, już dawno przez społeczność rozwiązanych.

Virtualisation Blog – http://blogs.technet.com/b/virtualization/default.aspx

Jak wyżej.Niestety.

• Obowiązkowe (Microsoft, Hyper-V, File Server)

Łukasz Kałużny – http://blog.kaluzny.pro/ – Blog Łukasza był dla mnie początkiem próby zrozumienia działania i przewagi HyperV. Chociaż ostatnio pisze rzadziej, sposób w jaki przekazywał powodował iż na początkowym etapie bywał po prostu niezastąpiony.

Aidan Finn – http://www.aidanfinn.com/ – wyszczekany, niepoprawny politycznie, hejter Linuksów i VMWare. Wrzuca zarówno rozwiązania swoje, jak i w formie agregatora newsów rzeczy związane z Hyper-V, Azure. Nie boi się w mało delikatny sposób zaznaczyć kto w Microsofcie ma problemy z głową przy wprowadzaniu (tak, tak! więcej zamieszania w licencjonowaniu i supporcie) nowości.

Ben Armstrong – http://blogs.msdn.com/b/virtual_pc_guy/ – Manager programu Hyper-V. Gość z niesamowitą wiedzą, dzielący się DZIAŁAJĄCYMI rozwiązaniami w ramach oficjalnego uczestnictwa w programie Microsoftu.

Jose Barreto’s Blog – http://blogs.technet.com/b/josebda/default.aspx – kolejny uczestnik programu Microsoftu (FIle Server Team). Jego posty z kolei skupiają się na rozwiązaniach z zakresu Storage. Nie ma co jednak zapominać iż Storage to SILNY i KLUCZOWY parametr dobrego hypervisora.

Didier Van Hoye ‚Working Hard in IT’ – http://workinghardinit.wordpress.com/ tam gdzie zawiodą oficjalne sposoby Microsoftu, lub osoby powyżej mają związane ręce z powodów oficjalnych, tam wkracza Didier. Jego artykuły mogą uratować Ci życie (lub karierę) w przypadku kolejnego świetnego pomysłu marketingu czy kierownictwa Microsoftu. Dobrze Wam radzę – wrzucać jego notki do Evernota czy Pocketa bo w chwili kryzysu mamy rozwiązanie podane jak na tacy.

Michael Rueefli AKA Dr.MIRU – http://www.miru.ch/ Michael skupia się na najbardziej niedocenionym obecnie pomyśle Microsoftu czyli HyperV Replica. Z tym rozwiązaniem jest świetnie jak działa – jak nie działa, to na 99% Michael JUŻ wie dlaczego i co zrobić.

Kristian Nese – http://kristiannese.blogspot.com/ – Azure i HyperV

• Obowiązkowe – sensowni ludzie w PL

Agregator Ziembora – http://ziembor.pl/plitproblogs/ – Skupia wpisy profesjonalistów w PL piszących dla innych, celem pomocy. Nieopatrznie powiem, iż poniższy blog jest w nim obecny.

Chociaż w żaden sposób nie pretenduję do powyższej czołówki (charakter mojej pracy nie pozwoli mi specjalizować się tylko w kilku wybranych technologiach) chciałbym wierzyć (i wierzę, patrząc na statystyki i maile ze swojego bloga) iż komuś tak sprezentowane rozwiązanie przyda się w krytycznej chwili.

Serdeczne podziękowania dla Michała Panasiewicza (z którym sprzeczam się równie często, co namiętnie) jako inspiracji dla powyższego wpisu.

I jak wyżej – szanowni Microsoftowicze – MVP są naprawdę jedynym powodem, który przepycha mnie przez codzienne obcowanie z waszymi technologiami.

As we all know – disk space isn’t free. If you allocate disk space to your virtual machine, you always want to allocate proper, well-balanced size to shorten future downtimes. But what is proper and balanced you ask?  There is no short answer to this, but if you’re  IT person, you always will try to allocate more than is needed right at the moment.  The decision is : should I use static or dynamic disks?

For me, there is no really need to use static disks anymore as there is no real speed difference. So, the real pro using dynamic disk is their smaller size.

In production environment, using Microsoft’s hypervisor, we can expect our VM to grow over time. During the nature of virtual machines and virtual disks, the real data machine uses are not the same numbers as virtual disk sizes. It is happening due to hypervisor behaviour – deleting all data from OS in virtual machine is no more than throwing away and index card from your book. The written data are still there, so there is no easy, automated way to compact a virtual disk.

Hypervisor however, tries to allocate in a first place, blocks marked as used. So the real expanding is happening when you’re constantly changing your data, without deleting them first. The great example is with databases, log and temporary trash disks and just plain and simple oversizing. I’ve had a case when relativly small machine (20 GB CentOS with a 600 GB VD) just grew over few days filling whole 600 GB of data because of logs set to DEBUG.

So what will be the cons and of virtual disk growing overtime?

• obviously, more space allocated at expensive storage for VMs
• more obviously, when you’re using any kind of backup software, you’re forced to write and store in multiple copies the data you really doesn’t need
• CBT (Change Block Tracking) Table is bigger to process, with every move
• more network traffic with every backup job you have
• live ‚shared nothing’ migration times grows just out of proportions. If you have a small machine with 20GB data on 600 GB sized disk, you will have to transfer this whole fatso over you network to other machine. Even with compression set at live migration, it is just really unwanted.

So what can we do? We can just zero the data you’re not using and Hyper-v cmdlets  will take the rest.

You have to plan downtime for the machine, but according to my tests, zeroing machines with 600 GB took 15 to 30 minutes. With smaller sizes it is just matter of single minutes.

Before you go:
– plan your downtime, compacting should not to be interrupted
– take extra caution. Zeroing important data or uneeded data it’s just a matter of mistake.
– delete all snapshots/checkpoints
– make sure you converted VHD to VHDX (optional)
– make sure your disk is set as dynamic disk
– make sure you have enough room for compacting or resizing. Remember – if you have 600 GB virtual disk, during this process it may grow to this size.
– remember that compacting deletes CBT table for backup software – next backup will be a Full Backup.

The most usable zeroing ways I found was:

Offline methods

Cons
– longer downtime
Pros
– more accurate (no more background write)
– faster (no more background write)
– smaller risk of processes failure due to ‚out of space’ event

• zerofree for Linux ext2/ext3/ext4 disks
• ntfswipe for Windows based disks
• dd for both Linux and Windows based disks or exotic fs (btrfs/xfs)

Online methods
Cons
– less accurate (background write  is still happening)
– machines became slower or unresponsible
– slower process
– risk of applications failing due to ‚out of space’ events
Pros
– smaller downtime

– SDelete or CCleaner for Windows based disks
– dd for Linux based disks

Phase I – Zeroing Offline

Offline zeroing (done with System Rescue CD 4.x)

• Delete all uneeded data (logs, temps, bigfiles, dowloads, caches)
• Umount all ext2/3/4/ntfs volumes
• for NTFS volume: ntfswipe -av /dev/volume_name
• for ext2/3/4 volume: zerofree -v /dev/volume-name
• for LVM: vgchange -a y;zerofree -v /dev/mapper/volume_name

Zeroing swap space:

# swapoff -a

# free
total used free shared buffers cached
Mem: 8056340 2643132 5413208 155072 606916 914796
-/+ buffers/cache: 1121420 6934920
Swap: 0 0 0

# blkid |grep swap
/dev/sdb2: UUID="adad0488-3b67-4444-b792-6a1a775b8821" TYPE="swap"

# dd if=/dev/zero|pv -treb|dd of=/dev/sdb2 bs=8192
dd: error writing ‘/dev/sdb2’: No space left on device
1,91GB 0:01:04 [30,3MB/s]
249981+4 records in
249980+4 records out
2047868928 bytes (2,0 GB) copied, 67,931 s, 30,1 MB/s

#mkswap /dev/sdb2 -U "adad0488-3b67-4444-b792-6a1a775b8821"
Setting up swapspace version 1, size = 1999868 KiB
no label, UUID=adad0488-3b67-4444-b792-6a1a775b8821

# swapon -a

# free
 total used free shared buffers cached
Mem: 8056340 3309648 4746692 159844 1112232 919708
-/+ buffers/cache: 1277708 6778632
Swap: 1999868 0 1999868

Phase I – Online zeroing

1. Delete all uneeded data (logs, temps, bigfiles, dowloads, caches)

for Windows machine
sdelete -z letter:

Linux machine
#dd if=/dev/zero|pv -treb|dd of=/file.zero bs=4096;sync;sync;rm -rfv /file.zero;sync

Phase II – Compacting

1. Shutdown the machine

For System Center VMM 2012 R1/R2

👁 Workspace 1_107

For Hyper-V powershell

Optimize-VHD -Path path_to_vhdx_file.vhdx -Mode Full

👁 Workspace 1_108

——-
System Rescue CD – http://www.sysresccd.org/Download
SDelete – http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx
CCleaner Portable – https://www.piriform.com/ccleaner/builds
zerofree – http://manned.org/zerofree/00be91ab

Od pewnego czasu (czytaj od przenosin na nowy HDD – jak w tytule) zastanawiała mnie ślamazarna wydajność mojego OS (W7 Pro). Niby wszystkie testy ok, partycje, odchudzone dane, kopiowanie dużych plików leciutko poniżej normy, kopiowanie malych plików = tragedia. Start systemu – 15-20 sekund, oraz przynajmniej kilka minut po logowaniu, podczas których system dosłownie stawał się nieresponsywny. Jako iż drażnił mnie ten temat, po ostatnich doświadczeniach z ZFS (NAS4FREE FTW) i 4k drives, postanowiłem sprawdzić w czym zacz.

Zaczynając od artykułu w KB 2510009 Microsoftu: http://support.microsoft.com/kb/2510009

Podstawowy fsutil zwrócił mi:

C:\Users\mbojko>fsutil fsinfo ntfsinfo c:
Numer seryjny woluminu NTFS: 0x38ccb5dbccb5941a
Wersja: 3.1
Liczba sektorów: 0x0000000012bef4f9
Całkowita liczba klastrów: 0x000000000257de9f
Klastrów wolnych: 0x0000000001227e24
Całkowita liczba zarezerwowanych: 0x00000000000005c0
Bajtów na sektor: 512
Bajtów na sektor fizyczny: 4096
Bajtów na klaster: 4096
Bajtów na segment rekordów pliku: 1024
Klastrów na segment rekordów pliku: 0
Prawidłowa długość danych tabeli MFT: 0x000000000e940000
Początkowa wartość LCN tabeli MFT: 0x00000000000c0000
Początkowa wartość LCN drugiej tabeli MFT: 0x0000000000000002
Początek strefy tabeli MFT: 0x000000000060e460
Koniec strefy tabeli MFT: 0x000000000060e5e0
Identyfikator menedżera zasobów: C66A7F5D-EF4B-19E2-9CE9-FDD9CB10E836

Zgodnie z tabelą z powyższego artykułu oznacza to Advanced Format.

Dalej, sprawdziłem obecność hotfixa: 2553708 – był zainstalowany.

Grzebiąc odrobinę niżej, znalazłem prehistoryczny firmware w swoim HDD

Rozwiązaniem był upgrade fw do wersji CC4H – dostępny tutaj: http://knowledge.seagate.com/articles/en_US/FAQ/223651en

Mniej więcej 10 sekund po wpisaniu hasła, system jest responsywny i gotowy do pracy 😉

http://blog.avg.pl/2013/07/co-musisz-wiedziec-o-backupie-danych-czesc-3/

http://blog.avg.pl/2013/06/co-musisz-wiedziec-o-backupie-danych-czesc-2/

Część I – http://blog.avg.pl/?p=2320

W poniższym wpisie chciałbym pokazać Wam jak w krótki sposób zamienić sobie usługę box.com w dosyć wydajne archiwum danych (dla klienta Windowsowego)

Ten sam sposób działa także z popularnym Dropboxem (nie testowałem ze Skydrive i GoogleDrive) – zarówno w kliencie dla systemów Windows jak i Linux.

Dlaczego box.com a nie pozostałe wymienione usługi? W zasadzie z bardzo prostej przyczyny – wrodzonego skąpstwa 😉 Otóż udało mi się trafić na Happy Hours w box.com, gdzie zakładając konto i logując się na nie z dowolnego urządzenia z Androidem dostawaliśmy 50GB przestrzeni gratis.

Powtórzę: 50GB GRATIS a nie 2 GB/5GB jak u konkurecji. Wykorzystując więc Dropboxa do synchronizacji plików pomiędzy urządzeniami, mając 50 GB chmury wolne, aż prosi się to o wykorzystanie tej przestrzeni do backupu ważnych plików posiadanych w sporych ilościach. Dla mnie na pewno są to pliki książek, zdjęć i filmów rodzinnych.

Na początek trochę teorii. Klient pod Windows zakłada domyślnie katalog (można to zmienić) w „%userprofile%\documents\my box files” – po ludzku, w katalogu użytkownika, w ‚Moich dokumentach’ pojawia się „My Box Files”. Wszystko co wrzucimy do tego katalogu zostanie zsynchronizowane z chmurą box.com – identycznie jak w przypadku Droboxa. Co jednak w sytuacji gdy pliki te mamy rozsiane na innych volumenach/dyskach i nie zamierzamy tego zmieniać? Wykorzystamy zjawisko (wspólne dla Win/Linux) linków symbolicznych.

Odrobina teorii dla chcących: http://pl.wikipedia.org/wiki/Dowi%C4%85zanie_symboliczne

Co chcemy osiągnąć?

1. W katalogu „%userprofile%\documents\my box files”  pojawią się podkatalogi, które chcemy synchronizować z chmurą.

2. Na dysku systemowym nie ubędzie nam miejsca – nawet jeżeli wykonamy linki do katalogów zbliżonych pojemnością do magicznych 50GB

3. Każda zmiana w katalogach rozsianych po innych dyskach/partycjach zostanie uwzględniona w procesie synchronizacji z box.com (z opcją: pozostawić te skasowane czy też synchronizować zmiany)

👁 boxsync

Jak miałoby to wyglądać u mnie ?

👁 boxsync3

Uruchamiamy ‚CMD’ jako administrator

mklink /D „C:\Users\mbojko\Documents\My Box Files\WinUAE” „L:\WINUAE”

mklink /D „C:\Users\mbojko\Documents\My Box Files\Books” „F:\Media\Books\GoodBooks\Sorted”

mklink /D „C:\Users\mbojko\Documents\My Box Files\Zdjęcia” „E:\Images\Zdjęcia”

mklink /D „C:\Users\mbojko\Documents\My Box Files\Videos” „D:\Video”

Efekt:

łącze symboliczne utworzone dla C:\Users\mbojko\Documents\My Box Files\WinUAE <<===>> L:\WINUAE

łącze symboliczne utworzone dla C:\Users\mbojko\Documents\My Box Files\Books <<===>> F:\Media\Books\GoodBooks\Sorted

łącze symboliczne utworzone dla C:\Users\mbojko\Documents\My Box Files\Zdjęcia <<===>> E:\Images\Zdjęcia

łącze symboliczne utworzone dla C:\Users\mbojko\Documents\My Box Files\Videos <<===>> D:\Video

2013-04-13 19:00 <DIR> .
2013-04-13 19:00 <DIR> ..
2013-04-13 18:59 <SYMLINKD> Books [F:\Media\Books\GoodBooks\Sorted]
2013-04-13 18:45 491 781 Box Sync ReadMe.pdf
2013-04-13 19:00 <SYMLINKD> Video [D:\Video]
2013-04-13 18:58 <SYMLINKD> WinUAE [L:\WINUAE]
2013-04-13 19:00 <SYMLINKD> Zdjęcia [E:\Images\Zdjęcia]

👁 boxsync2

Korzystając z zaległego urlopu postanowiłem wykonać dawno odkładaną aktualizację domowego labu z VSphere 5.0 do 5.1.  Jeden z serwerów zaopatrzony jest w kartę sieciową Realtek 8168, drugi w kartę Intela. O ile sam upgrade przebiegł bez żadnych większych zarzutów o tyle maszyna zaopatrzona w (on-board) 8168 wszelakie operacje sieciowe zaczęła po prostu … ignorować.

W logach serwera DHCP widać było poprawne uwierzytelnienie, cały cykl DORA zakończony sukcesem, interfejs po stronie VSphere uparcie pokazywał 0.0.0.0, po pewnym czasie przechodząc na adresację APIPA, nadanie adresu statycznego kończyło się podobnym efektem.

Na szybko szukając rozwiązania problemu (zostałem bowiem z hostem bez sieci) zauważyłem iż jest to popularna bolączka, na którą tak naprawdę nie ma porządnego rozwiązania. Podmiana sterowników z wersji 5.0 nie załatwiała sprawy – do wyboru zostało mi poszukiwanie oficjalnie wspieranego interfejsu lub nieoficjalnie acz działającego.

Padło na poniewierające się i w miarę uniwersalne Realteki 8139 (C/D), których zawsze mam kilka w odwodzie.

W jaki jednak sposób dorzucić nowe sterowniki nie posiadając sieci? Możemy wypalić je na płycie CD (o ile nasz host takowy napęd posiada), możemy skorzystać z USB – co raczej w maszynie zdarza się zawsze. Musimy jednak się odpowiednio przygotować.

1. Pendrive z jakiego skorzystamy powinien mieć partycję sformatowaną w FAT16, nie większą niż 2GB (moja była na poziomie 1.5). Plik vib możemy pobrać z tego miejsca: net-8139-1.0.0.x86_64

2. Po zalogowaniu,  z konsoli hosta wydajemy polecenie:

# /etc/init.d/usbarbitrator stop

ew. wyciagamy i wsadzamy nasz napęd.

3.W katalogu /vmfs/volumes powinien pojawić się nasz zamontowany napęd jako NO NAME.

Przechodzimy do niego i kopiujemy vib do datastore: (sprawdzcie tylko nazwę Waszego datastore)

# cp net-8139-1.0.0.x86_64 /vmfs/volumes/datastore1

4. Wchodzimy do Maintenance Mode i pozwalamy na dorzucanie sterowników:

# esxcli system maintenanceMode set -e true -t 0
# esxcli software acceptance set --level=CommunitySupported    [OPCJA]

5. Dorzucamy sterownik:

#esxcli software vib install -v /vmfs/volumes/datastore1/net-8139-1.0.0.x86_64

6. Opuszczamy Maintenance Mode

#esxcli system maintenanceMode set -e false -t 0

Reboot.

Gwoli wyjaśnienia: w systemach produkcyjnych szczerze nie polecam dorzucania plików z nieznanego źródła, w home labie – gdzie do tego nie chcę wydawać majątku na wspierane karty – mogę sobie na to pozwolić.

Prezentacja tradycyjnie dostepna w formie slajdów:

👁 2012-04-25 21.09.44

Jak zapewne wiadomo tym, którzy przebrnęli przez poprzednie wpisy o DRBL, system ten dostarcza ciekawy mechanizm umożliwiający dostarczanie kilku pożytecznych narzędzi za pomoca  PXE bezpośrednio do komputera na którym je potrzebujemy. Iż jest to czasem błogosławieństwo chyba nie muszę opowiadać: brak dyskietki, dysku USB, CDROMU, uszkodzenie tychże i tak dalej i tak dalej.

Przykład? Konieczność wykonania akcji ratunkowej/maintenance na badanym systemie – ot klasyczny uszkodzony Windows/Linux do spacyfikowania. Zazwyczaj wykonujemy opcję startu z CD/DVD, czasem klucza USB (bez angażowania dysku twardego), a tu pokażę jak możemy to zrobić łatwiej i przyjemniej: via network. Dzisiaj zajmiemy się dostarczeniem jednego z ciekawszych systemów ratunkowych: System Rescue CD, dostępnego tu: http://www.sysresccd.org

Kilka aksjomatów:

– pokaz przeprowadzam na openSUSE 11.3 z zainstalowanym systemem i prekonfigurowanym DRBL’em w wersji 1.10.31_1

– interfejs dla podsieci DRBL to 172.16.0.1, podsieć 172.16.0.0/24

– obrazy systemów dostarczamy za pomocą http – można to zrealizować poprzez tftp, nfs, nbd – http pozostaje jednak najbardziej uniwersalny dla dodatkowych systemów podpinanych do DRBL’a, jak również stosunkowo najłatwiejszy w konfiguracji.

– zawartość serwera HTTP domyślnie znajduje się w /srv/www/htdocs

– zawartość DRBL/Tftpd domyślnie znajduje się w /tftpboot/nbi_img

– plik konfiguracyjny drbla znajduje się w /tftpboot/nbi_img/pxelinux.cfg/default

– wszystkie operacje wykonujemy jako root/sudo su

Zaczynamy od pobrania ostatniej wersji System Rescue CD – na potrzeby manuala jest to 2.3.1, ale oczywiście powinno działać z wersjami wcześniejszymi i późniejszymi, bez dokonywania zmian innych niż nazewnictwo plików i ich wersje:

# pobieramy i montujemy ISO jako filesystem
wget http://downloads.sourceforge.net/project/systemrescuecd/sysresccd-x86/2.3.1/systemrescuecd-x86-2.3.1.iso
mkdir -p /media/system
mount systemrescuecd-x86-2.3.1.iso /media/system -o loop

# zawartość pliku ISO jest dostępna w /media/system # kopiujemy z System Rescue CD jego kernel i initrd
cp /media/system/isolinux/rescuecd /tftpboot/nbi_img/rescuecd
cp /media/system/isolinux/rescue64 /tftpboot/nbi_img/rescue64
cp /media/system/isolinux/initram.igz /tftpboot/nbi_img/initram.igz.systemrescue

#Kopiujemy plik obrazu systemu do naszego domyślnego serwera http.
cp /media/system/sysrcd.dat /srv/www/htdocs/sysrcd.dat
cp /media/system/sysrcd.md5 /srv/www/htdocs/sysrcd.md5

# sprawdzamy czy mamy uruchomiony serwer http:
chkconfig -l apache2
apache2 0:off 1:off 2:off 3:on 4:off 5:on 6:off
 
# Uwaga, - krok opcjonalny jeżeli poprzedni krok zwrócił nam same 'off'
yast2 -i apache2
chkconfig --add apache2

# testujemy nasz serwer http
wget http://172.16.0.1/index.html

--2011-10-14 18:04:49-- http://172.16.0.1/index.html
Connecting to 172.16.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 44 [text/html]
Saving to: `index.html'

100%[=====================================================================================================================================>] 
44 --.-K/s in 0s 

2011-10-14 18:04:50 (2.19 MB/s) - `index.html' saved [44/44]
# Wygląda na to iż wszystko działa ;) # Robimy kopię ustawień DRBL'a
cp -p /tftpboot/nbi_img/pxelinux.cfg/default /tftpboot/nbi_img/pxelinux.cfg/default.old
# Swoim ulubionym edytorem (gedit/mcedit/vi/ed) dokonujemy edycji pliku: 
/tftpboot/nbi_img/pxelinux.cfg/default

mcedit /tftpboot/nbi_img/pxelinux.cfg/default
# Na końcu pliku dodajemy linie:

label System Rescue CD 2.3.1
# MENU DEFAULT
# MENU HIDE
 MENU LABEL System Rescue CD 2.3.1
# MENU PASSWD
 kernel rescuecd
 append initrd=initram.igz.systemrescue netboot=http://172.16.0.1/sysrcd.dat setkmap=pl 
 nomodeset dostartx
# TEXT HELP
# Boot System Rescue CD via network
# ENDTEXT

label System Rescue CD 2.3.1 64bit (required 400 MB or more)
# MENU DEFAULT
# MENU HIDE
 MENU LABEL System Rescue CD 2.3.1 64bit (required 400 MB or more)
# MENU PASSWD
 kernel rescue64
 append initrd=initram.igz.systemrescue netboot=http://172.16.0.1/sysrcd.dat docache 
 setkmap=pl nomodeset dostartx
# TEXT HELP
# Boot System Rescue CD 64bit via network
# ENDTEXT

I efekt:
👁 1

👁 2
W następnym odcinku: GParted, PartedMagic, i Hiren's Boot CD ;)

Kiedyś trafiłem na denerwujący problem – mając dostęp tylko do konsoli serwera opartego na Debianie, musiałem zbadać jaki RAID  działa na nim. Serwer oczywiście HP – co niejako pod Linuxem inklinuje użycie drivera CCISS – http://cciss.sourceforge.net/. Dodam że driver zaszyty jest we wszystkich supportowanych przez ejczpi dystrybucjach, oraz wielu nie supportowanych (Debian 5.0 bez żadnego problemu obsługuje starsze SmartArray’e).

Z pomocą przychodzi narzędzie array-info – http://sourceforge.net/projects/array-info/ dostępne razem z driverem cciss – a więc dostępne również w systemie po instalacji tegoż.

Wynik ?

serwer:/dev/cciss# array-info -d /dev/cciss/c0d0 -A
Unknown Controller id 0x409c0e11
Firmware revision : 2.84
Rom revision : 2.84
1 logical drive configured.

Logical drive 0 :
Fault tolerance : RAID 5
Size : 271.33 GiB (569018880 blocks of 512 bytes)
Status : Logical drive is ok
Spare : Not configured

Przezwyciężając lenistwo:

Część I

Część II

Część III

Część IV

Część V

Część VI

Spotkanie odbyło się planowo – poniżej snapshot prezentacji.

Filmy mam nadzieję dam radę później 😉

Zapewne Ci z was, którzy aktywnie używają DRBL’a w swojej pracy mieli juz okazję wykorzystać pakiet DRBL-Winroll. Ci z Was, którzy realizowali już rollouty, masowe migracje czy deploymentu, wiedzą też o konieczności zmiany SID’a maszyn – często wykorzystując narzędzie Marka Russinovicha ‚NewSID‚

No właśnie – czy zmiana SID‚a jest konieczna? Dużo się bowiem zmieniło od czasu Windows 98 😉
Pod koniec roku 2009, Mark Russinovich, twórca (między innymi) świetnego narzędzia NewSid,  opublikował wpis na swoim blogu: http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx w którym dosyć autorytatywnie rozprawia się z mitem ‚konieczności zmiany SID‚a’ w klonowanych systemach.

Podsumowując artykuł – dla tych, którzy klonują stacje robocze oparte na systemach Windows, zabawa w zmianę SID przyda się tylko i wyłącznie gdy … stawiacie kontrolery domen Active Directory 😉 Pozostali mogą spać spokojnie, sytuacja gdy maszyny z tym samym SID’em zbuntują się i zaczną dzielić się tajnymi plikami jest praktycznie niemożliwa 😉

Dla tych którzy chcą jednak i te rzeczy w swojej sieci miec pod kontrolą pozostają minimum 3 rozwiązania.

1. Użyj Microsoftowego programu SysPREP.

Zaletą tego rozwiązania jest dosyć dokładne przygotowanie unikalnego systemu dla identycznych stacji roboczych, jak również szybkość i prostota działania.
Wadą jednak pozostaje konieczność ponownej ręcznej rejestracji/aktywacji systemu, z jego nużącym wpisywaniem klucza oraz przechodzenie przez etap ‚wykrywam/wykrywam/wykrywam/chyba instaluję’.

O ile w przypadku instalacji wersji OEM’owych – wydaje się to być jedynie słuszną drogą (jak również przygotowywanie wersji dla klienta końcowego do samodzielnej rejestracji), o tyle w przypadku korzystania z licencji typu MOLP/Select/VLK dokładanie roboty jest zupełnie niepotrzebne.

2. Użyj narzędzia NewSID
Chociaż narzędzie to zostało wycofane pod koniec 2009 roku z witryny SysInternals, wciąż jeszcze można je znaleźć na dzisiątkach stron z przydatnymi programami.
Zaletą tego pakietu jest doskonała zgodność z przeszłymi wersjami systemów oraz prostota działania.

Z racji wycofania wsparcia dla tego narzędzia, niewiadomym jest jak będzie się ono zachowywac po wydaniu kolejnych poprawek do systemów Vista/Windows 7, jak i przyszłych edycji Windowsowej familii. W niektórych przypadkach problemy sprawiać moga próby wykorzystania tego narzędzia w zautomatyzowanej formie – na przykład wygenerowaniu nowych nazw dla hosta opartych o przewidywalny schemat.

3. Uzyj narzędzia DRBL-Winroll
Zaletą narzędzia jest jego wszechstronność – nie tylko możemy zmienić SID (nazwę) stacji roboczej, ale również jego przyszłe ustawienia sieciowe, nazwę grupy roboczej i dostępność usługi sshd.

Wadą rozwiązanie jest: konieczność przygotowywania domyślnych konfigów na określonej grupy maszyn (np. kojarzenie IP/grupy roboczej z MAC okreslonych stacji roboczych) i automatyczna instalacja pakietu CygWin. W przypadku chęci kozrystania z setupów automatycznych z serwera DRBL niezbędne jest skonfigurowanie kluczy ssh.

Dla tych którzy szukają wciąż NewSID’a – link: TU

Wspominałem wcześniej o jednej z podstawowych funkcjonalności serwerów DRBL – mechaniźmie klonowania stacji roboczych z wykorzystaniem wspólnej pracy Clonezilli i PXE. W skrócie – serwer DRBL zapewnia nam możliwość startu źródłowej stacji roboczej za pomocą PXE, Clonezilla wraz z pakietami towarzyszącymi klonuje zawartość dysków stacji roboczych do plików. Pliki mogą być zapisywane (używając kilku wskazanych metod kompresji) za pomocą SMB/FTP/SSH/NFS lub na lokalnych dyskach. Wspierane filesystemy to min:

• ext2,
• ext3,
• reiserfs,
• xfs,
• Jfs
• FAT16/32,
• NTFS 3 i 5(streams),
• HFS+
• Praca blokowa (block-by-block, sector-by-sector)

Idea ta pozwala na wykonanie jednoczesnych operacji na dowolnej ilości stacji roboczych – co więcej, w zależności od ilości danych i szybkości sieci, samo odtwarzanie/zapisywanie trwa od kilkunastu sekund, do kilkunastu minut.
Wyobrażcie sobie następujące zastosowanie: organizacja, w której wystepuje kilka modeli stacji roboczych. Każda z nich może spełniać inną rolę – od stacji użytkownika wprowadzającego dane po stacje księgujące, graficzne, administracyjne, techniczne – wszystko zależy od zastosowanego profilu oprogramowania lub ustawień systemowych.
Przy każdej awarii lub standaryzacji czeka nas nie lada wyzwanie:

– instalacja OS (często aktywacja ponowna – a więc wyjaśnianie dlaczego właściwie aktywuje się ta kopię po raz kolejny)
– instalacja wszystkich możliwych poprawek, service packów, Support Packów danego producenta itp.
– instalacja niezbędnego oprogramowania
– konfiguracja pod użytkownika

Każdy pracownik działu IT doskonale zna ten schemat. Aby ułatwić sobie życie: wykorzystując DRBL, na jednej ze wskazanych maszyn tworzymy instalację wzorcową (np. OS+poprawki+w miarę stałe ustawienia), resztę doinstalowując za pomocą skryptu z wykorzystaniem wolumenów sieciowych.

Z małą ilością użytkowników (stacje profilowane pod konkretnych userów a nie role) możemy pójśc o krok dalej – przygotowujemy pełny obraz: OS+poprawki+aplikacje+ustawienia charakterystyczne. Czas kompresji i rozmiar pliku wynikowego zależą ściśle od ilościu materiału do kompresji oraz maszyny na jakiej to wykonujemy.

Na szczęście sama dekompresja jest błyskawiczna – mam przygotowane obrazy pod różnych klientów w różnych instytucjach – przeciętny czas odtworzenia stacji roboczej po awarii to około 6 minut (obraz), 2-3 minuty na restart maszyny i dalsza konfiguracja za pomocą skryptu sieciowego – kolejne 3 minuty.

Idąc dalej tym sposobem – o ile jest taka potrzeba, za pomocą mechanizmu WoL możemy zaplanować wykonywanie kopii wskazanych maszyn np. co weekend.

Jak widać w czasie poniżej 15 minut można mieć pełne Disaster Recovery 😉

Co z serwerami zapytacie?
Rewelacyjnie. Wiemy bowiem, iż bez pełnego DR, w środowiskach które nie pracują jako HA – przeważnie posiadając jedną/dwie nie zwirtualizowane maszyny spełniające swoją rolę – metoda ta sprawdza się bardzo dobrze.
Zarówno w środowisku serwerów HP/DELL/IBM oraz innych firm trzecich, przy znikomym nakładzie środków i pracy możemy spokojnie wykonywać kopie OS umieszczane na dyskach macierzowych (SmartArray w HP, ServeRaid w IBM i PERC-H w Dell’u).
Minimalistyczny DR w tego typu maszynach obejmuje:
– konfigurację RAID HW
– odtworzenie OS za pomocą DRBL
– odtworzenie danych dla aplikacji/systemu z backupu.

Dla przykładu: DR zaprojektowany przeze mnie dla 200 maszyn HP DL 380 G4/G5, z Windows 2003, trzema różnymi wolumenami logicznymi (recovery OS), zajmujący około 20GB, odtwarzał się w około 8-9 minut (sieć 1Gb). Synchronizacja partycji z danymi – kolejne 10 minut.

👁 hp9000

Historia zaczyna się jak wszystkie – był sobie serwer HP 9000. W radosnym roku 1995 został uruchomiony w jednej z państwowych instytucji obsługując cały oddział i zapewniając niezbędne aplikacje, pod kontrolą systemu HP-UX. Chociaż dookoła tejże maszyny jak grzyby po deszczu wyrastały nowe maszyny, nowe szafy, nowe zwirtualizowane środowiska, maszyna wciąż okazywała się potrzebna zapewniając odpowiednie konektory do pracujących baz danych.

W tymże roku 1995 został opracowany podstawowy scenariusz DR (Disaster Recovery) odtwarzania pełnego systemu z napędów taśmowych. Procedura przetrwała, same napędy jak i taśmy niekoniecznie 😉 W związku ze zbliżającym się widmem awarii zostałem poproszony o przygotowanie planu ratunkowego pozwalającego na pełne odtworzenie systemu wraz z bieżącymi runetime’ami.

Dłuższą chwilę zajęło wyszukiwanie informacji o maszynie w części ‚Discontinued’ na stronie HP. WIzja lokalna potwierdziła założenia – magistrala SCSI (FAST), złącza wewnętrzne w standardzie HS50, wraz z dyskiem na taśmie znajdują się CDROM SCSI oraz napęd taśmowy – jeden z pierwszych DDS’ów 😉

Szatański plan ewoluował w następujące formie

Wariant A

Odszukujemy dystrybucję Linuxa wydaną dla PA-RISC (koniecznie live) i zmuszamy IPL’a maszyny do startu z tejże. Mają uruchomionego Linuxa możemy dostarczyć odpowiednie narzędzie do wykonania snapshotu sektorów startowych, tablicy partycji oraz samego systemu. Przygotowujemy procedurę odzysku – operację odwrotną dla procedury zabezpieczenia danych, również opartą o dystrybucję Linux wydaną dla PA-RISC.

Wariant B

Wykorzystując sytuację iż cały system pracuje na pojedynczym dysku SCSI  2.1 GB w standardzie Fast-SCSI HS50 – patrz poniżej – odnajdujemy odpowiedni kontroler SCSI, uruchamiamy maszynę pod kontrolą systemu Linux, odnajdujemy informację o możliwościach odczytu tablicy partycji systemu HP-UX i za pomocą odpowiedniego narzędzia wykonujemy kopię wskazanego dysku do obrazu a następnie na dysk ‚awaryjny’. Dodam iż odszukanie kontrolera ze złączem Fast nie sprawiło większego problemu, natomiast dysku o pojemności większej niż 2.1 GB już tak 😉

👁 HS50

Wariant C

Idziemy na żywioł 😉

Wariant A odpadł bardzo szybko – brak odpowiedniej dystrybucji live

Wariant B wykrzaczył się w połowie – OpenSuse w wersji 11.0 i 11.1 nie były w stanie odnaleźć na wskazanym dysku żadnych partycji. Ponieważ – czysto teoretycznie – powinny to zrobić, musieliśmy założyć iż kontroler HP 9000 nieco inaczej odczytuję geometrię dysku, stąd niepowodzenie w odczycie tejże dla kontrolera Tekram i systemu Linux.

Ostatnią deską ratunku okazało się banalne skopiowanie zawartości dysku za pomocą dd – ten soft nigdy nie przestanie mnie zadziwiać oraz przerzucenie obrazu również za pomocą dd na dysk awaryjny. W tymże dysku (jako że kontroler HP9000 należał do nieco prehistorycznych) należało jeszcze upewnić się iż auto-spinning jest zapewniony a ID i LUN ustawione właściwie. Dodam że cała operacja odczytu dysku zakończyła się w ok. 15 minut, drugie tyle zajęło skopiowanie obrazu dd.

Dysk zapasowy włożony w czeluści serwera został prawidłowo rozpoznany i obsłużony przez IPL, system wystartował poprawnie, konektory się podniosły. Hurra dla Linuxa ? 😉

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.

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 😉

Ponieważ jak słusznie zauważył jeden z moich szanownych projektowych kolegów:  ‚ Wpisanie hasła ‚drbl’ do Googla już od 3 pozycji zaczyna wypluwać Twoje nazwisko‚ 🙂  warto by było, aby wykorzystując materiały które tak pięknie udało mi się zebrać, przekazać kilka dobrych słów w temacie tegoż produktu – którego zastosowanie mogę wyobrazić sobie prawie wszędzie. Samo ‚wygooglanie’ ma związek z wykładem jaki miałem przyjemność przekazywać dla studentów AGH w Krakowie, z racji inicjatywy LUMD, szerzej tutaj: https://marcinbojko.wordpress.com/2009/05/04/lumd-linux-u-mnie-dziala/

Spróbujmy. Sam akronim DRBL rozwija się w skrót Diskless Remote Boot Linux, co oznaczając możliwość uruchomienia dowolnej dystrybucji Linuxa, za pomocą sieci na bezdyskowych końcówkach (workstacjach) było jednym z pierwszych zastosowań tego systemu.

W praktyce ewoluował on do takiego stopnia (min. przez różne dziwne pomysły które udało nam się zastosować) iż stał się mechanizmem dostarczania dowolnych usług/aplikacji za pośrednictwem protokołów PXE. Wyjaśniając bardziej: pozwala nam za pomocą bootowania z wykorzystaniem interfejsów sieciowych uruchomić prawie że dowolną usługę lub aplikację system.

Przykłady? Przykłady poniżej.

Co w tym nowego zapytacie? Nowego – nic.  Ale jeżeli zbierze się w całość wszystkie systemu które do tej pory trzeba było instalować oddzielnie aby uzyskać podobny efekt (poświęcając temu spore ilości godzin) to własnie uzyskamy naszego DRBL’a.

Mechanizm działania jest prosty – dowolna workstacja, która posiada możliwość bootowania z karty sieciowej (w praktyce wszystkie produkowane po 2002/2003 roku) – za pomocą protokołu PXE otrzymuje od serwera DRBL możliwość uruchomienia menu startowego, z którego możemy uruchamiać dalsze dowolne podsystemy. Ponieważ system jest skonstruowany tak aby nie wykorzystywać przestrzeni dyskowej na workstacji klienckiej, jedynym ograniczeniem w uruchamianiu bardziej rozbudowanych subsystemów staje się pamięć RAM. Oczywiście sama ilość pamięci jest ściśle określana przez subsystem który chcemy uruchomić – dla zdalnego uruchomienia np. FREEDOS‚a wystarczy nawet 640kb 😉

Oznacza to iż dla uruchomienia prostego zestawu serwer-klient potrzebujemy sprzętu który spełnia naprawdę minimalne wymagania, co za tym idzie jest tani, łatwo dostępny i …. wspomniałem już tani ?

Zobaczcie sami jak pięknie może to wyglądać.

Sieć korzystająca z zasobów serwera DRBL może wyglądać na przykład tak:

👁 Image
👁 Slajd6

– za pomocą jednego serwera i 4 interfejsów sieciowych (jeden WAN) oferujemy 3 różne usługi.

Wiemy, w wielkim skrócie jak, teraz pytanie CO można dostarczyć w ten sposób. Proszę bardzo: standardowe przykłady:

👁 Slajd8

Instalacja wspieranych systemów:

• Instalacja wielu stacji roboczych jednocześnie (do 40 na interfejsach gigabitowych) bez wyraźnego spowolnienia działania.
• Wykorzystanie mechanizmu unicast i multicast
• Wykorzystanie mechanizmów PXE, TFTP, HTTP (lokalny i z repozytoriów), FTP, NFS
• Możliwość instalacji skryptowej (min. autoyast w SUSE), instalacja dodatkowych aplikacji i pakietów
• Możliwość wykonywania aktualizacji ze wskazanych repozytoriów lub cache’u lokalnego
• Wspiera mini-dystrybucje lub wersje net-install

Uruchamianie OS na maszynach klienckich za pomocą PXE

Klonowanie i utrzymanie dysków i wolumenów (Clonezilla)

Na dzisiaj tyle danych do przełknięcia 😉  O ile wskoczę na pozycję numer jeden w Google – będę kontynuował temat.

Mam ci ja jeden z serwerów produkcyjnych postawionych na etchu, z kernelem 2.6.18-6. Co pewien czas przychodzi potrzeba skopiowania kilku plików z niego i na niego – z racji sztywnego podziału przez HTB łatwiej i dosłownie szybciej jest zrobić to za pomocą pendrive USB. 8GB Kingston Data Traveler którego posiadam, używa NTFS’a , którego to etch obsługuje wyłącznie w trybie READ ONLY.

Jest co prawda świetny projekt NTFS-3G jednak w repozytoriach stable go nie ma, testing i unstable dodawać nie chciałem (biblioteki i zależności – nie za bardzo zależało mi na rozwalaniu maszyny produkcyjnej), dokompilowywać ręcznie równiez nie za bardzo. Z pomocą przyszła idea Debianowych backportów.

Zaczynamy od edycji /etc/apt/sources.list – dodajemy np. na jej końcu

http://backports.cisbg.com/ etch-backports main

Aby odświeżyć listę dostępnych pakietów wydajemy polecenie:

#aptitude update

Nie przejmować się komunikatem o braku klucza PGP, tak to już jest z backportami. Następnie instalujemy niezbędne pakiety:

#aptitude install ntfs-3g libntfs-3g31 libntfgs-3g-dev

W przypadku komunikatu o zbyt starym kernelu (wymagany 2.6.20) – cóz, polecam zignorowac 🙂

Montowanie wolumenów odbywa się na zasadzie wskazania właściwego filesystemu – opcja: -t ntfs-3g

#mount /dev/wolumen /mnt/wolumen -t ntfs-3g

W przypadku problemów dodajemy opcje -o force na końcu. I wszystko.