Wojciech Błaszkowski

Urzywanie macierzy dyskowych nie jest czymś niecodziennym. Obecnie, nawet w laptopach spotykane są miejsca na 2 dyski.

O ile przepisów na stworzenie macierzy z użyciem mdadm są w sieci tysiące, o tyle chciałbym zwrócić uwagę na 3 istotne fakty. W tej chwili mam do zagospodarowania 4 dyski SATA 1TB w serwerze 1U. Postanowiono, że wykorzystane to będzie pod swap (4GB), /boot (500 MB), / (50GB) oraz /home (reszta). Zabawmy się zatem.

1. Tworzenie partycji.

Warto, aby każda z patrycji miała ustawiony typ “raid autodetect”. Pomaga to przy późniejszej identyfikacji i składaniu macierzy.

# fdisk -l /dev/sda

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0×30f6ea17

Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         249     2000061   fd  Linux raid autodetect
/dev/sda2   *         250         312      506047+  fd  Linux raid autodetect
/dev/sda3             313        3473    25390732+  fd  Linux raid autodetect
/dev/sda4            3474      121601   948863160   fd  Linux raid autodetect

2. Jak najwięcej danych dotyczących samej macierzy powinno zostać zduplikowanych.

Pamiętajcie o opcji bitmap, dobrze jest ustawić ją na internal. Wówczas dane odnośnie samej macierzy uywane przy jej składaniu są przechowywane w metadanych tej macierzy i zreplikowane na wszystkie urządzenia wchodzące w skład macierzy.

mdadm -C /dev/md1 –level=10 –bitmap=internal -n 4 /dev/sd{a,b,c,d}1
mdadm -C /dev/md2 –level=1 –bitmap=internal -n 4 /dev/sd{a,b,c,d}2
mdadm -C /dev/md3 –level=10 –bitmap=internal -n 4 /dev/sd{a,b,c,d}3
mdadm -C /dev/md4 –level=10 –bitmap=internal -n 4 /dev/sd{a,b,c,d}4

3. RAID 5 czy RAID 10 ?

Dotychczas mając do dyspozycji 3 lub 4 dyski wybierałem RAID 5. Więcej miejsca niż w 10, ale też i o wiele dłuższy czas ewentualnego rebuildu macierzy po padzie zasilania w stosunku do RAID10. Dlatego też dziś chętnie wybieram ten drugi wariant. Dyski są duże i tanie, a więc nie żal jest miejsca, jeśli chodzi o bezpieczeństwo danych. No i oczywiście prętkość :) Ta macierz będzie składać się do końca z prętkoscią rzędu 200000K/sec.

# cat /proc/mdstat
Personalities : [raid10] [raid1]
md4 : active raid10 sdd4[3] sdc4[2] sdb4[1] sda4[0]
1897726080 blocks 64K chunks 2 near-copies [4/4] [UUUU]
[>....................]  resync =  1.6% (31655168/1897726080) finish=153.5min speed=202512K/sec
bitmap: 224/227 pages [896KB], 4096KB chunk

md3 : active raid10 sdd3[3] sdc3[2] sdb3[1] sda3[0]
50781312 blocks 64K chunks 2 near-copies [4/4] [UUUU]
bitmap: 5/194 pages [20KB], 128KB chunk

md2 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
505920 blocks [4/4] [UUUU]
bitmap: 0/62 pages [0KB], 4KB chunk

md1 : active raid10 sdd1[3] sdc1[2] sdb1[1] sda1[0]
3999872 blocks 64K chunks 2 near-copies [4/4] [UUUU]
bitmap: 0/123 pages [0KB], 16KB chunk

unused devices: <none>

Od ponad miesiąca dostępna jest wersja OpenSSL 1.0. Administratorów czeka zatem przeinstalowanie lwiej części oprogramowania, o ile deweloperom udało się już je przekompilować.

Dla PLD Linux samo OpenSSL w nowej wersji jak i przekompilowane paczki są już dostępne, a zabawę zapewnią nam:

links, ekg, tcpdump, rdesktop, squid, wget, syslog-ng, lynx, net-snmp(-libs), rsync, openldap-libs, exim, nagios-nrpe, pure-ftpd, poldek-libs, bind-libs, apache(-tools),  mysql(-libs),  i inne,

libcap i korzystające z niej: tcpflow, dsniff, arpwatch, trafshow, nmap, iftop, i inne,

heimdal-libs i reszta zależnych od Kerberosa paczek; postgresql-libs, cups-lib, openssh-server, i inne.

Dla posiadaczy desktopów (z kartą nVidia) możemy upgradnąć serwer X’ów do wersji xorg-xserver-server-1.8.0 wraz z xorg-driver-video-nvidia-195.36.24. Driver ten wspiera już OpenSSL 1.0.

Majowy weekend zapowiadany jest jako deszczowy, więc bez żalu można będzie przysiąść i upgradnąć to i owo. Have fun.

Próbowałem ostatnio utworzyć patrycję nieco większą niż zwykle, 2,3TB. Tradycyjnie do pracy został zagoniony cfdisk, w końcu od tego jest – pomyślałem. Z jakichś przyczyn jednak cfdisk w wersji z paczki util-linux-ng-2.16 zamiast utworzyć rządaną przezemnie partycję, utworzył ją w wielkości 300GB. Doczytałem, że cfdisk nie obsłuży patrycji powyżej 2TB, co nie zmienia faktu, że powinien zakrzyczeć o tym fakcie. Użyłem parted który poradził sobie z problemem wyśmienicie.

Zrobienie patrycji na całej dostępnej przestrzeni dysku:

# mkpart primary 0 -0

Warto zaznaczyć, że parted nie jest programem do zabawy – zmiany zapisywane są na dysk bez zatwierdzania, zaraz po ich “nakazaniu”.

Last week I have to import a large (above 4 GB) MySQL dump, wich includes InnoDB tables. The dump was made with –extended-insert=false, so we have many single operations to do. It takes me above 50 hours (sic !) by doing a simple source datadump.sql in the MySQL console. Load on the machine was near 1,02.

Next time I will do it like that:

create database DATABASE charset=CHARSET;
use DATABASE;
set names CHARSET;
set FOREIGN_KEY_CHECKS=0;
set AUTOCOMMIT=0;
source datadump.sql;
COMMIT;

While inserting data with above example, the load skips up to 4,90 – 5,30, so the 2-core machine was not boring.
It is realy fast :)

Having a simple LAMP guest Linux Vserver Debian etch we can do a dist-upgrade in minutes.
1. Stop the guest vserver, and make a copy of it. Just in case if something goes wrong.
2. Start the guest vserver, and enter it. Type as root:

# sed -i -e “s#etch#lenny#g” /etc/apt/sources.list

your file will look some like this:

deb http://ftp.pl.debian.org/debian/ lenny main
deb-src http://ftp.pl.debian.org/debian/ lenny main
deb http://security.debian.org lenny/updates main

3. Do: apt-get update
4. Start praying ;-) and type: apt-get dist-upgrade
5. Done ?

You probably have a syslog-ng daemon, and if it wouldn’t run, chceck the config files. In a Linux guest vserver you should comment line:

file(”/proc/kmsg” log_prefix(”kernel: “));

and then start your syslog-ng daemon.
It take me 10 minutes to upgrade my Debian guest vserver on my notebook :)