Server pro domácí síť, zabezpečení proti výpadku

7.4.2011 13:34 | Přečteno: 2472× | Linux | | poslední úprava: 7.4.2011 13:36

Tento díl volného seriálu věnuji zabezpečení proti výpadkům. Především je to mirror systémového disku pro případ jeho selhání, UPS pro případ výpadku napájení a sériová konzole přes HP LO100 pro případ ztráty ssh spojení.

Disk

Asi po měsíci od základní instalace jsem přidal další disk konkrétně 2TB Seagate ST32000641AS. Jde podle mne o určitý kompromis disku pro trvalý chod za rozumnou cenu. Možnost bootování mne limitovala na velikosti 2TB.

Protože už základní instalace počítala s RAID1, bylo jeho vytvoření poměrně snadné. Nový disk jsem rozdělil stejně jako první - kde jsem se nemohl trefit přesně do stejné velikosti, zvolil jsem o kousíček větší.

fdisk -l /dev/sdb

Disk /dev/sdb: 2 000,4 GB, 2 000 398 934 016 bajtů
hlav: 255, sektorů na stopu: 63, cylindrů: 243 201, celkem 3 907 029 168 sektorů
Jednotky = sektory po 1 * 512 = 512 bajtech
Velikost sektoru (logického/fyzického): 512 bajtů / 512 bajtů
Velikost I/O (minimální/optimální): 512 bajtů / 512 bajtů
Identifikátor disku: 0x88fc74e2

Zařízení Zavádět   Začátek       Konec    Bloky    Id  Systém
/dev/sdb1   *          63      321299      160618+  fd  Linux RAID samorozpoznatelný
/dev/sdb2          321300     4530329     2104515   82  Linux swap/Solaris
/dev/sdb3         4530330     8739359     2104515   fd  Linux RAID samorozpoznatelný
/dev/sdb4         8739360  3907024064  1949142352+   5  Rozšířený
/dev/sdb5         8739423   488408129   239834353+  fd  Linux RAID samorozpoznatelný
/dev/sdb6       488408193  3907024064  1709307936   83  Linux

Potom už přišel příkaz pro vytvoření RAID1:

mdadm /dev/md1 -a /dev/hdb1
mdadm /dev/md3 -a /dev/hdb3
mdadm /dev/md4 -a /dev/hdb5

Dále bylo potřeba nakonfigurovat grub, zde podle pravidla zápisu do MBR každého disku tak, jakoby byl první a samostatný. Při výpadku druhého disku a startu musí ukazovat sám na sebe, protože druhý disk v tu chvíli není.

Následovalo samozřejmě otestování startu z prvního disku, fyzické přepojení SATA a start z druhého disku.

Jelikož server má sloužit primárně jako souborový server, je zdraví disků klíčové. Proto je pravidelně monitoruji přes SMART:

/etc/smartd.conf
/dev/sda -a -I 194 -W 4,45,55 -R 5 -m můj@mail.com
/dev/sdb -a -I 194 -W 4,45,55 -R 5 -m můj@mail.com

Souběžně s tím spouštím automatické testy přes crontab:

# Scrubbing diskového pole (každou neděli ráno)
# pro md4 trvá 50min, ostatní do 30sec
50  5  * * sun  echo "check" > /sys/block/md1/md/sync_action
55  5  * * sun  echo "check" > /sys/block/md3/md/sync_action
00  6  * * sun  echo "check" > /sys/block/md4/md/sync_action

# SMART self-test
00  1  * * 0-5  /usr/sbin/smartctl -t short /dev/sda
05  1  * * 1-6  /usr/sbin/smartctl -t short /dev/sdb
00  2  * * sat  /usr/sbin/smartctl -t long /dev/sda     # sobota, trvá cca  45 min
00  0  * * sun  /usr/sbin/smartctl -t long /dev/sdb     # neděle, trvá cca 255 min

UPS

Občas i u nás vypadne elektřina a tak jsem k serveru přikoupil UPS. Vybral jsem APC Back-UPS Pro 900, která server udrží v provozu přes 2hod od začátku výpadku.

K ní jsem instaloval apcupsd; nastavení apcupsd.conf uvádím níže. UPS je konfigurovaná udržet server v provozu co možná nejdéle, server vypíná při vybití na 10% celkové kapacity nebo 10min před vybitím, podle toho, co přijde dříve. Slouží pouze lokálnímu serveru a jednou za dva týdny provede self-test.

UPSCABLE usb
UPSTYPE usb
DEVICE 
LOCKFILE /var/lock
SCRIPTDIR /etc/apcupsd
PWRFAILDIR /etc/apcupsd
NOLOGINDIR /etc
ONBATTERYDELAY 6
BATTERYLEVEL 10
MINUTES 10
TIMEOUT 0
ANNOY 300
ANNOYDELAY 60
NOLOGON disable
KILLDELAY 0
NETSERVER off
EVENTSFILE /var/log/apcupsd.events
EVENTSFILEMAX 10
UPSCLASS standalone
UPSMODE disable
STATTIME 0
STATFILE /var/log/apcupsd.status
LOGSTATS off
DATATIME 0
UPSNAME Back-900
BATTDATE 02/10/11
BEEPSTATE N
SELFTEST 336

Sériová konsole

Kdysi dávno jsem začínal s UNIXem u klasického znakového terminálu a dodnes na to rád vzpomínám. Byla to zajímavá doba a dobrá zkušenost. Přesto všechno jsem původně neplánoval využívat sériovou konsoli, ačkoli to server podle dokumentace umožňuje.

Názor mi pomohl změnit kamarád, který se mi pochlubil, že na svém serveru vzdálenou sériovou konsoli používá a pomohla mu už několikrát ušetřit výjezd do datacentra. Já mám sice server v kumbálu, ale i tak to byla výzva.

Přiznám se, že jsem se s tím docela nadřel, ale povedlo se. Bylo potřeba nastavit BIOS, do grub.conf přidat parametr jádra console=ttyS0 115200, do inittab doplnit S0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102 a povolit ttyS0 v securetty.

Přihlášení přes sériovou konsoli se pak dělá přes klasické OpenSSH na IP adresu management konsole serveru:

ssh user@192.168.1.100
user@192.168.1.100's password: 

Lights-Out 100 Management
Copyright 2005-2007 ServerEngines Corporation
Copyright 2006-2007 Hewlett-Packard Development Company, L.P.

/./-> cd /system1/console1
/./system1/console1/-> start


root@ProLiant ~ # 

S defaultním nastavením je však přístup jen read-only. Nepomohl ani Google a už jsem téměř rezignoval, že asi nemám koupenou licenci. Když jsem však později server zabezpečil a změnil defaultní uživatele management konsole LO100, změnila se rovněž úroveň přístupu na write.

Sériovou konsoli rozhodně nepoužívám denně, rychlostí mi připomíná staré časy BBS, ale musím uznat, že je to věc opravdu šikovná. Když jsem třeba později nastavoval VDE pro KVM, byl jsem vážně rád, že ji mám.

Server potřebuje ještě ssmtp, aby si mohl postěžovat přes e-mail a ntp pro přesný čas.

Benchmarky

Pro dnešek na samý závěr přidám ještě pár benchmarků práce se soubory na jednom disku, tak jak jsem si je poznamenal dříve a srovnání s RAID1, kdy jsem stejné testy zopakoval následně.

Samostatný disk:

time dd if=/dev/urandom of=reallylargefile count=4M
4194304+0 vstoupivších záznamů
4194304+0 vystoupivších záznamů
2 147 483 648 bajtů (2,1 GB) zkopírováno, 272,936 s, 7,9 MB/s

real    4m33.005s
user    0m0.664s
sys     4m31.374s

V RAID1:

time dd if=/dev/urandom of=reallylargefile count=4M
4194304+0 vstoupivších záznamů
4194304+0 vystoupivších záznamů
2 147 483 648 bajtů (2,1 GB) zkopírováno, 269,483 s, 8,0 MB/s

real    4m29.501s
user    0m0.452s
sys     4m16.197s

V tomto srovnání jsou výsledky prakticky stejné, rozhodující vliv zde bude mít rychlost generátoru /dev/urandom

Samostatný disk:

time rsync -v reallylargefile /home
reallylargefile

sent 2147745869 bytes  received 31 bytes  49373468.97 bytes/sec
total size is 2147483648  speedup is 1.00

real    0m43.307s
user    0m12.067s
sys     0m7.362s


RAID1:

time rsync -v reallylargefile /home/
reallylargefile

sent 2147745869 bytes  received 31 bytes  27015671.70 bytes/sec
total size is 2147483648  speedup is 1.00

real    1m19.348s
user    0m11.887s
sys     0m7.768s

V tomto testu se ukazuje, že rychlost zápisu na RAID1 je nižší než na samostatném disku.

Samostatný disk:

time rsync -v reallylargefile reallylargefile2
reallylargefile

sent 2147745869 bytes  received 31 bytes  43388806.06 bytes/sec
total size is 2147483648  speedup is 1.00

real    0m48.725s
user    0m11.182s
sys     0m6.416s

RAID1:

time rsync -v reallylargefile reallylargefile2
reallylargefile

sent 2147745869 bytes  received 31 bytes  49373468.97 bytes/sec
total size is 2147483648  speedup is 1.00

real    0m43.068s
user    0m11.809s
sys     0m7.571s

Ve srovnání s předchozím testem dopadlo kopírování velkého souboru v rámci stejného filesystému překvapivě dobře.

Samostatný disk:

time bunzip2 linux-2.6.36.tar.bz2 

real    0m18.008s
user    0m17.461s
sys     0m0.482s

RAID1:

time bunzip2 linux-2.6.36.tar.bz2

real    0m18.376s
user    0m17.815s
sys     0m0.477s

Při rozbalení jádra jsou výsledky na samostatném disku a RAID1 prakticky stejné.

Samostatný disk:

time tar xf linux-2.6.36.tar.bz2 

real    0m42.401s
user    0m19.239s
sys     0m1.659s

RAID1:

time tar xf linux-2.6.36.tar.bz2 

real    0m44.432s
user    0m19.536s
sys     0m1.878s

Rozbalení jádra s vytvářením souborů a adresářů vychází na RAID1 o něco pomaleji než na samostatném disku.

Pokud bych to měl nějak shrnout, pak RAID1 je pro zápis pomalejší než samostatný disk. Asi nejhorší je to v případě kopírování velkých souborů mezi různými filesystémy, jinde je to však skoro nastejno. RAID1 však používám hlavně pro zajištění proti havárii disku a ještě navíc primárně v systémové oblasti, takže je to v pořádku.

Dnešní zápisek je shrnutím nejzásadnějších věcí za několik měsíců, někdy příště bychom se mohli podívat na KVM.        

Komentáře

[ahoj]

2TB nejsou limitem ani pro BIOS.

[hufhendr]

Ale nějaké problémy s tím být mohou (?) Vím, že jsem četl pár článků snad na Živě a možná i jinde; před většími disky mne varoval i bývalý kolega (specialista na Windows).
Je mi jasné, že další disk mohu přidat klidně 5TB, u toho systémového jsem se raději držel při zemi.

[Sten]

Možná Windows s tím problémy mají, ale pokud jsou bootovací data uložena na začátku disku (tj. samostatný oddíl /boot), tak je to BIOSu úplně jedno.

[Petr Tomášek]

A kolik ti to s tím RAIDem žere?

[hufhendr]

Aktuální spotřeba celého serveru je 35W, teplota v kumbálu 26°C.

apcaccess status
APC      : 001,037,0937
DATE     : Thu Apr 07 22:36:38 CEST 2011
HOSTNAME : ProLiant
VERSION  : 3.14.7 (1 August 2009) gentoo
UPSNAME  : Back-900
CABLE    : USB Cable
MODEL    : Back-UPS BR 900GI 
UPSMODE  : Stand Alone
STARTTIME: Thu Apr 07 22:36:37 CEST 2011
STATUS   : ONLINE 
LINEV    : 237.0 Volts
LOADPCT  :   6.0 Percent Load Capacity
BCHARGE  : 100.0 Percent
TIMELEFT : 188.8 Minutes
MBATTCHG : 10 Percent
MINTIMEL : 10 Minutes
MAXTIME  : 0 Seconds
SENSE    : Medium
LOTRANS  : 176.0 Volts
HITRANS  : 288.0 Volts
ALARMDEL : No alarm
BATTV    : 27.2 Volts
LASTXFER : Automatic or explicit self test
NUMXFERS : 0
TONBATT  : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
SELFTEST : NO
STATFLAG : 0x07000008 Status Flag
MANDATE  : 2010-09-09
SERIALNO : 3B1037X27963  
BATTDATE : 2010-09-09
NOMINV   : 230 Volts
NOMBATTV :  24.0 Volts
NOMPOWER : 540 Watts
FIRMWARE : 879.L1d.I USB FW:L1
APCMODEL : Back-UPS BR 900GI 
END APC  : Thu Apr 07 22:36:39 CEST 2011

ipmiutil sensor
05c0 SDR Full 01 01 20 a 01 snum 0f SYS Ambient Temp = 34 OK*  26.00 degrees C

[xHire]

Nový disk jsem rozdělil stejně jako první - kde jsem se nemohl trefit přesně do stejné velikosti, zvolil jsem o kousíček větší.

:c) Příště doporučuji použít příkaz sfdisk, konkrétně lze takto pěkně:

sfdisk -d /dev/sda | sfdisk /dev/sdb

Je paráda, že se pak člověk vůbec nemusí s rozdělením párat, ale má to defakto zadarmo a naprosto přesně.

U benchmarků mi chybí i nějaké srovnání čtení větších souborů, ale to jen pro úplnost.

Jinak hezký článek. :c) Zvlášť zajímavé pro mě bylo to o té sériové konzoli -- o tom se člověk dneska už moc nedočte.

[hufhendr]

Přes ten sfdisk by to bylo přesně stejné, ale první disk má 250GB a druhý 2TB. U prvního vystačím se 4 oddíly, druhý už jich má 6 včetně rozšířeného. Nevyšlo mi to právě u 3. RAID, který je na druhém disku až v rozšířeném oddílu.