Kritická zranitelnost v procesorech Intel a nejen tam

převzato z https://www.deviantart.com/art/with-speedpaint-Intel-Inside-Logo-Vector-586811036

Sjedem si to rychle. V procesorech Intel i AMD se objevily hned 3 kritické zranitelnosti.

  1.  Bounds Check Bypass
  2.  Branch Target Injection
  3.  Rogue Data Cache Load

AMD je údajně imunní proti Rogue Data Cache Load, Branch Target Injection útok se doposud nikomu nikdy nepodařil a reálně lze napadnout pouze útokem Bounds Check Bypass, který je opravitelný, bez nutnosti provádět hardwarové změny procesoru.

Intel je napadnutelný všemi třemi typy útoků. Z toho co jsem vyčetl různě po internetu jsem pochopil, že pokud provozujete virtualizační služby, cloudové služby, tak jeden zákazník na jedné virtuálce, je schopen sáhnout do paměti jiné virtuálky jinému zákazníkovi. Takže všichni velcí cloudoví poskytovatelé (azure, amazon a další) teď na rychlo upgradují, zaplátovávají a restartují své servery i za cenu toho, že na serverových procesorech v některých případech rapidně, v jiných jen lehce, ubude výkon. Výkonnostní výhoda Intelu je, že jsou například L3 paměti procesoru pro každé jádro sdílené s ostatními. Zde ale přichází onen problém. Záplata řeší problém tak, že před zápisem do TLB cache donutí procesor TLB cache vyprázdnit, což práci procesoru v některých procesech velmi zpomalí. Server The Register prováděl testy a po záplatě se práce PostgreSQL serveru snížila v nejlepších případech o 17%, v nejhorších o 23%. Velmi podrobný článek najdete zde.

zdroj1 zdroj2 zdroj3 zdroj4 zdroj5 zdroj6

Virtualbox Resize neresiznutelného image pevně definovaného

máte soubor nejakyimage.vdi s pevně definovanou velikostí ve Virtualboxu.

Vboxmanage, v případě že máte windows tak zajedete do C:\Program Files\Oracle\Virtualbox\

a zadáte příkaz:

vboxmanage.exe clonehd "c:/cesta/k/imagi/nejakyimage.vdi" "c:/cesta/k/imagi/NOVYimage.vdi" --format VDI --variant standard

 

Dále jakmile to naklonujete, tak ten naklonovaný soubor NOVYimage.vdi můžete zvětšit dle libosti:

modifyhd "c:/cesta/k/imagi/NOVYimage.vdi" --resize <cílová velikost>

Kde cílová velikost nahradíte za počet MB, tedy pokud chcete, aby finální image soubor měl třeba 60 000 MB třeba:

modifyhd "c:/cesta/k/imagi/NOVYimage.vdi" --resize 60000

A pak už to můžete načíst ve virtualboxu jako disk image, zajedete do operačního systému (pokud je to windows 7 tak dáte start/pravým tlačítkem na tento počítač/spravovat/vlevo kliknete na správa disků/ pravým tlačítkem na oddíl disku C a rozšířit oddíl/proklikáte se průvodcem a hotovo).



 

Když proxmox dostane krámy

Dnes se mi stala nepříjemná věc. Restartoval jsem 2 mašiny a po restartu už to v quorum a v proxmoxu řvalo, že ty mašiny jsou odpojeny. Co teď? Pvecm status vypisuje, že je v clusteru jediná node a to je ta, která vše kontroluje, restartované mašiny jsou pryč. Po delším googlení jsem došel k následujícímu řešení, které Vás však může připravit o veškerou konfiguraci, či virtuálky, takže pozor! Na jednotlivých mašinách (mimo kontrolní, ze které cluster spravujete):  // ikdyž jsem to na kontrolní virtuálce pak udělal taky a v pohodě.

systemctl stop pve-cluster
systemctl stop corosync
pmxcfs -l
rm /etc/pve/corosync.conf
rm /etc/corosync/*
ps aux | grep pmxcfs
kill -9 $(pgrep pmxcfs)
systemctl restart pve-cluster

A potom mi šla mašina znovu přidat do clusteru příkazem: pvecm add <název čip IP adresa kontrolního stroje, kam chci fyzickou mašinu přidat), pak už to vypíše něco ve smyslu:

pvecm add dns_název_kontrolního_stroje
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'název_stroje' to cluster.

zdroj zdroj2 zdroj3

Zahoďte oVirt, je tu Proxmox ver. 4.x

Za tenhle článek mě Red Haťáci sežerou zaživa, na druhou stranu, než se pustím do Proxmoxu, popovídám Vám o oVirtu.

OVirt je skvělá technologie, založená na KVM (kernel based virtual machine), která umí live migraci, High-availability (vysokou dostupnost, dále jen HA), podporuje jak GlusterFS, tak namapování nejrůznějších diskových polí, umí snapshoty a je to prostě super technologie, o které jsem psal i ve své diplomce. Ovirt vychází z RHEV (Red Hat Enterprise Virtualization), máte na výběr si to buď rozjet na Centos 7, nebo Fedora Server, anebo si zkompilujete zdrojáky na Debianu/Ubuntu, což spíš nedoporučuji, protože oVirt je masivně podporovaný a používaný na Centosech a Fedorách, ale zatím jsem neviděl jedinou funkční bezproblémovou instalaci oVirtu na Debianu či Ubuntu. Parametricky je oVirt úplně vynikající technologie, která poměrem cena/výkon (je zdarma), nabízí to stejné, co konkurenti nabízí v cenové kategorii „platím jako mourovatý“. Ke zprovoznění oVirtu potřebujete 2 fyzické servery a aspoň 1 virtuálku. Občas se na internetu setkávám s pojmem „hosted engine“, kde honíte virtuálku, která řídí ty 2 fyzické mašiny uvnitř clusteru.

No a teď moje zkušenosti s oVirtem. Ještě jednou píšu, oVirt je vynikající technologie, která se řídí myšlenkou, že oVirtem spravujete v podstatě celý server. A už tady oVirt u mě naráží. Já chci virtualizační technologii, ať si ona virtualizuje, ale ať mě jako admina nechá možnost změnit něco v síťových připojeních serveru a ať ona vidí jen síťové mosty, které ji řeknu, že má vidět. Dále chci mít server pod kontrolou i jinačí možností, než jen přes rozhraní oVirtu a to se tu přesně nedoporučuje. Takže ikdyž jsem byl z oVirtu nadšený, stejně tak jako jsem byl předtím nadšený z OpenStacku, než mi došlo, že na správu a údržbu OpenStacku potřebujete celý team adminů a občas i nějakého programátora, který Vám ohne třeba síťová rozhraní, tak jak vy potřebujete, tak u oVirtu si uvědomuji, že jsem už na začátku dělal jednu chybu. Nevzal jsem si filosofii oVirtu a neporovnal to s tím, jaké víry ohledně Virtualizace jsem založený já sám.
Další co mi tak trošililinku vadí na oVirtu je fakt, že já musím mít ideálně server spárovaný s APC nebo napojený na ILOM, IMM či jiná management rozhraní serverů, ze kterých oVirt čerpá data pro HA a když to tak neudělám, tak mi ten oVirt zkrátka nezaručuje, že bude fungovat zcela bezproblémově s HA (tedy HA bude fungovat omezeně až po několika minutách viz zdroj2). No a teď ale k tomu, co si myslím, že já dělám špatně, když jsem kdykoliv nasazoval oVirt. Měl jsem si vždycky vzít bare metal instalační ISO a nainstalovat oVirt tak jak je rovnou přes něj a jsem přesvědčen, že by se mi neprojevovala většina problémů, které se mi projevovaly tehdy, když jsem oVirt instaloval dodatečně do Centosu 7. Další co mi vadilo na oVirtu byl web management. Já mám rád příkazy, ale jediné, kdy jsem ovládal virtualizační technologií příkazy bylo jen tehdy, když jsem tomu prováděl nějaký ruční update, nebo když jsem to chtěl nějak zautomatizovat přes webové rozhraní, aby se mi vytvářelo jedním kliknutím třeba desítky virtuálek a na to jsem si vygooglil příkazy, ozkoušel a za 14 dní zapomněl. Na oVirtu je web management jen taková nouzovka, která nabíhá pomale, má fakt docela mizernou odezvu a občas jsem měl strach na něco kliknout v obavách, že bych tím tu technologii rozbil, což se mi i parkrát na testovacím clusteru stalo. Potom se mi třeba stávalo, že mašina, která se mi „bugla“, prostě nešla z clusteru odebrat, takže jsem musel odebrat i nějaké další věci, nebo zrušit i celý cluster a povytvářet znovu a zkrátka jsem s tou technologií celý život spíš bojoval a přemlouval, abych ji dostal tam kam potřebuju, než že by to intuitivně fungovalo bez problémů tak, jak od virtualizační technologie očekávám (a to už mi rukama prošel VMware, Xenserver, KVM, VirtualBox, LXC kontejnery, OpenVZ, Xen a další…). Teď představte, že se vám něco takového bugne na produkčním clusteru? To se prostě nesmí stávat a z té nejistoty, kterou ve mě chování web managementu oVirtu vytvářelo, jsem z něho nakonec upustil (a nejen proto). Byla to verze 3.6 a já doteď nenávidím VDSM za to, jak mě, administrátora mlátí přes prsty. Je ale pravda, že sami Red Haťáci mi řekli, že web management je nouzovka, že oVirt se stejně ve většině případů ovládá přes příkazy, což je spolehlivé (ano, v tom jim dávám za pravdu) + s přihlédnutím na filosofii oVirtu jim musím zase dát za pravdu, že není chyba v oVirtu, ale v mém výběru virtualizační technologie vzhledem k mému smýšlení, ačkoliv parametricky splňuje vše, co administrátor potřebuje. Je to prostě jako když si ženská vysní nějaké úžasné boty, úplně se do nich zamiluje, ví že parametricky ji všechno kolem těch bot vyhovuje, cena, velikost bot, kvalita materiálů apod… Bohužel až druhý den, co nosí boty zjistí, že z nich má odřenou patu a že ji taky trošku tlačí palec. A to je přesně můj případ. oVirt je fajn, umí vše dle parametrů, co admin očekává od virtualizační technologie založené na KVM, která umí HA a web management, ale zkrátka mě v oVirtu tlačí palec a mám z něj odřenou patu.

Red Haťáci, promiňte, mám vás rád, děláte dobrý produkty, oVirt má vynikající budoucnost, hodně agresivně se vyvíjí a neustále přibývají nové vychytávky, ale bohužel, pokud chci nějaký cluster, moje následující požadavky na cluster jsou:

1) Ta technologie musí být tak primitivní a jednoduchá s ideologií „Keep it stupid simple“, abych se na ni mohl spolehnout i v časech updatování, pádu stroje, kritických situací apod…

2) Musí to umět vše co potom chci tak, aby se mi to nesypalo pod rukama, nepsalo to stovky warningů, nebo errorů

3) Já jsem tady administrátor, ne Virtualizační technologie, která mě bude házet klacky pod nohy a dělat si svoje a sahat mi do řízení serveru. Chci virtualizační technologii, která virtualizuje, vidí si jen to minimum, které potřebuje k virtualizaci (jiné stroje, virtuální bridge, virtuálky, disková pole, gluster fs atd…), ale už mě nepeskuje za to, jak si upravím nebo přidám vlany, vlany do trunku, bondingu, co nahážu do firewallu apod…

PROXMOX ver 4.x

O proxmox jsem vždycky zavadil, na jednu stranu jsem viděl, že je to „free“ a na druhou stranu jsem viděl subscription a ceny předplatné podpory. Slovo bare metal je u mě na single strojích spíš sprosté slovo kvůli ztrátě jedné veřejné IP, která padne v tu ranu pro management a taky nešťastnost updatů některých bare metal řešení. Tam kde použiju bare metal virtualizaci, tak jsou střední firmy, které si mohou nakoupit spoustu železa, mají dostatek IP adres, mašiny jsou schované za hardwarovým firewallem, nebo vůbec za nějakým spolehlivým firewallovým řešení, které chrání celou firmu a často se setkávám s tím, že na bare metalu mi najednou nepůjde dodat tu napojení na nagios, plugin pro munin, zkrátka přicházím o všechny výhody, které jsou spojené se svobodou plnohodnotného operačního systému, na kterém běží virtualizační technologie.

A Proxmox je přesně taková technologie, jakou jsem dlouho hledal. Je totiž:

1) Téměř nerozbitná
2) Tváří se jako Bare Metal, ale je to Debian s funkčním apt-get balíčkovacím systémem
3) Virtualizační technologie si řeší virtualizaci a jakékoliv další balíčky si do systému nahodíte, to už je na Vás. Stejně tak Vás neplácá proxmox přes ruce, když si změníte něco v konfigurácích.
4) Je zdarma či open-source
5) Podporuje HA, Live migraci, snapshoty, GlusterFS a jako bonus vnímám podporu ZFS a RAIDZ/RAIDZ2/RAIDZ3, pokud tedy máte levnější železo, můžete si tam rozjet velmi kvalitní softwarový raid založený na ZFS RAID.
6) A má webové rozhraní, kde si naklikám co potřebuji s integrovanou konzolí, která se mi zatím ani jednou nebugla, vše je extrémně rychlé, běží to na všech prohlížečích a nejeví to známku nějaké unavenosti, nebo problémů. Když se objeví problém, dá mi to najevo, vyplivne mi to errorovou hlášku, vložím ji do googlu a hned vím řešení.
7) Je to tak intuitivní, že ani nemusím studovat dokumentaci a rozběhám si během chvíle cluster, HA, cokoliv chci dodat dalšího, to si tam dodám, ale nic se v tom nesype.
8) V případě, že se to vážně rozsype, musím být schopen z technologie vytáhnout virtuálky a jejich image. Když jsem záměrně rozbil oVirt s GlusterFS, abych tohleto zjistil, vytáhnout se mi z toho virtuálky jen tak snadno nepodařilo.
9) Musí to umět jak local datastore, tak replicated, tak network datastore

Jediná velká nevýhoda Proxmoxu, kterou třeba nemá nejnovější Xenserver je, že na funkční HA cluster potřebujete 3 stroje a je jedno jestli ty 2 jsou fyzické a ten třetí je virtuálka, která ty 2 fyzické stroje řídí, ale potřebujete zkrátka 3 stroje a to znamená, že se Vám to ročně na provozních nákladech prodraží a to je velká škoda. Xenserver narozdíl od toho zvládá fungovat na 2 strojích s HA redundancí.

Další výhoda Proxmoxu (pro mě) je ta, že má IPtables a nemá FirewallD. FirewallD je doménou zejména RedHatích produktů, tedy Centosu, Fedory. Nikde jinde jsem FirewallD snad neviděl, ubuntu ho nemá, debian ho nemá, arch linux taky ne, gentoo nikoliv, zkrátka je snazší napsat, které distribuce ho mají, než které ho nemají. Další nevýhodou je kratší životní cylus Debianu, který je zhruba +- 2 roky, u LTS distribuce je to zhruba +- 4 roky. Ale protože ty virtuálky

No a teď konečně k ukázce virtualizační technologie a jejího chování.

1) Běžná ukázka, instalace jedné virtuálky uvnitř jednoho ze strojů:

2) Ukázka Live Migrace

3) Ukázka snapshotů a revertnutí

4) Ukázka zafungování HA redundance

5) Jak to vypadá, když odpojený fyzický stroj zase zapojíte do sítě

 

zdroje oficiální dokumentace a mé osobní poznatky + rozhovory s kolegy, které tímto zdravím

zdroj2 zdroj3 zdroj4

Oracle Virtualbox změna UUID disku

Mám 1 virtuálku a tu si chci naduplikovat. Nakopíruji někam druhou kopii .vdi souboru. Virtualbox při přidání image však řve, že to nejde, protože UUID virtuálního disku je stejné, jako dříve přidaný virtuální disk.

Jak postupovat? Pokud jste v linuxu, tak už píšete příkaz, pokud jste ve windows tak:

cd C:\Program Files\Oracle\VirtualBox\

VBoxManage.exe internalcommands sethduuid e:/cesta/k/soubor_virtualniho_disku_virtualky.vdi

pak to napíše něco ve smyslu:

UUID changed to: b35a1e……atd…………………..4c2

Pak už jde druhý vytvořený soubor přidat do virtualboxu do druhé virtuálky.

 

Testoval jsem to ve Virtualboxu 5.1.6 (verze z roku 2016)

zdroj

Přejmenování síťové karty z ens7, enp8, epo3 apod… na eth0, eth1 a eth2 (Centos 7)

Když tento zákrok uděláte, spadne Vám rozhraní, takže pokud jste připojení k internetu, můžete si server odstřihnout! Pozor na to!

 

síťová rozhraní vylistujeme příkazem:  (pokud máme nainstalovaný yum install epel-release && yum provides ifconfig -y )

ifconfig -a
/sbin/ip link set ens7 down
/sbin/ip link set ens7 name eth0
/sbin/ip link set ens7 up

 

Enjoy 😉

zdroj

Portforwarding na Windows

Máte stroj A, za něho je připojen stroj B. Stroj A má veřejnou ip. Stroj B má neveřejnou IP např.: 192.168.123.3. Stroj B běží na windows a má povolenou vzdálenou plochu na portu 3389.

Chci zadat do připojení ke vzdálené ploše adresu A:3390 a chci se přitom dostat na stroj B:3389, jak na to?

Na stroji A otevřeme příkazový řádek za správce a napíšeme:

netsh interface portproxy add v4tov4 listenport=3390 connectaddress=192.168.123.3 connectport=3389

Případně pokud chceme určit specifickou adresu stroje A, tak:

netsh interface portproxy add v4tov4 listenaddress=ip_stroje_A_např_123.123.123.123 listenport=3390 connectaddress=192.168.123.3 connectport=3389

 A to je vše přátelé. Windows neumí portforwardit UDP, ale pouze TCP packety. UDP se používají na audio/video některé PC hry. TCP se používá na služby, kde je potřeba zajistit konzistenci dat (www stránky, souborov služby, emailové služby apod…).Nastavení zůstává na stroji i po restartu, není tedy nutné na to psát skripty či to nějak automatizovat.

Otestováno na Windows server 2012, ale funguje to i na jiných verzích windows. 😉

 

zdroj

Jak zjistit počet obsazených RAM DIMM modulů v linuxovém serveru či počítači?

Máte více serverů, ale někde se v dokumentaci ztratilo, kolik ramek má který server obsazený.

Jak to zjistit?

V mém případě stačilo zadat:

dmidecode -t memory|grep "Clock Speed: Unknown"|nl
Vypsáno bylo:
 1 Configured Clock Speed: Unknown
 2 Configured Clock Speed: Unknown
 3 Configured Clock Speed: Unknown
 4 Configured Clock Speed: Unknown
 5 Configured Clock Speed: Unknown
 6 Configured Clock Speed: Unknown
 7 Configured Clock Speed: Unknown
 8 Configured Clock Speed: Unknown
 9 Configured Clock Speed: Unknown
 10 Configured Clock Speed: Unknown
 11 Configured Clock Speed: Unknown

 

Tedy 11 neobsazených modulů. Na serveru se 24 DIMM sloty se tedy jedná o server, kam chci přidat chybějící RAM, kvůli lichému obsazení RAM ve slotech.

 

zdroj

Qcow2 pomalost imagů ve srovnání s .raw na KVM (debian wheezy)

Všimněte si toho rozdílu:

Qcow2, dd test propustnosti dat sekvenčního zápisu.

příkaz:

dd if=/dev/zero of=ddfile.big bs=1MB count=1k

time cp ddfile.big ddfile2.big

Virtuální stroj na KVM, image .qcow2, io mode: default, cache mode: default

1 024 000 000 bajtů (1,0 GB) zkopírováno, 1 134,61 s, 903kB/s

Virtuální stroj na KVM, image .raw, io mode: native, cache mode: none

1 024 000 000 bajtů (1,0 GB) zkopírováno, 14,7578 s, 69,4 MB/s

Další zajímavé a užitečné příkazy pro testování výkonnosti a zdraví pevných disků či diskových polí na linuxu:

dd if=/dev/zero dd=ddfile.big bs=1MB count=1k
 hdparm -I /dev/sda
 smartctl --attributes --log=selftest /dev/sdb
 dd if=ddfile.big if=/dev/null
 time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=10000

 Stav zátěže disků při jejich práci:
iostat -xdk 1 25

konverzi image jsem provedl pomocí:

http://docs.openstack.org/image-guide/convert-images.html

Konkrétně příkazem:

qemu-img convert -f qcow2 -O raw puvodniqcow2.img novynazevraw.img

zdroj zdroj2 zdroj3 zdroj4 zdroj5 zdroj6 zdroj7 zdroj8

Virtualbox nechce naskočit WinverifyTrust failed on stub executable: WinVerifyTrust failed

Na hlášku ve windows 8.1 po aktualizacích neběží virtualbox, hlásí to následující chybu:

WinVerifyTrust failed on stub executable: WinVerifyTrust failed with hrc=Unknown Status 0x8009200D on '\Device\HarddiskVolumeX\Program Files\Oracle\VirtualBox\VirtualBox.exe' (rc=-22919) Please try reinstalling VirtualBox.

řešení:

cmd

wusa /uninstall /kb:3081320

Ve skutečnosti však trvalým řešením na win8.1 byla aktualizace virtualboxu na nejnovější verzi 5.0.10

zdroj

zdroj2

 

IPv6 může mít každý, ikdyž to jeho poskytovatel neumožňuje!

Doporučuji přečíst tento článek:

https://podpora.nic.cz/page/661/ipv6-tunelovaci-mechanismy—instalace-a-nastaveni/

Ve zkratce. Existují veřejní poskytovatelé IPv6 tunelů. Takže Vám stačí jen IPv4 poskytovatel, nemusíte mít ani veřejnou ipV4 adresu. Jen se připojíte na veřejného IPv6 skrze IPv4 tunelového providera a ten Vám zabalí IPv6 adresu do IPv4 tunelu a vy si můžete vychutnávat svou veřejnou IPv6 adresu.

Zde je návod na rootu:

http://www.root.cz/clanky/jak-zprovoznit-ipv6-tunel-pres-cesky-bod-sixxs/

Enjoy 😉

 

Cifs / Samba mountování v /etc/fstab

Potřebuji mountout v /etc/fstab nějaké diskové pole / sdílený adresář z windows nebo z nějakého qnapu, jak na to?

řádek v /etc/fstab pro mount diskového pole typu CIFS:

//ipadresastroje.cz/mountovanýAdresář /místníAdresářKamToMountujete cifs username=jménouživatele,pass=nejakeVamiZvoleneHeslo,uid=1000,gid=1000,iocharset=utf8 0 0

 

uid= a gid= tam cpát nemusíte. To že to máte přimountované poznáte pomocí příkazu:

cat /proc/mounts

 

zdroj

Co je to virtualizace a jak si to mám představit?

Přátelé, dnes jsem shlédl video, kvůli kterému píšu tento článek.

 

Na tomto videu Vám vysvětlím pojem VIRTUALIZACE a virtualizační technologie. Ten 1 hudební nástroj je fyzické železo – fyzický server, běžící v serverovně. Všichni muzikanti, hrající na tento „hardware“ jsou virtuální stroje/virtualní servery, které se velmi inteligentně dělí o systémové zdroje (operační paměť, diskové úložiště i procesorový čas a přístup na síť), které jim fyzické železo (tedy fyzický server) nabízí. Dohromady šetří náklady majitele za nákup dalších hudebních nástrojů, protože dokáží efektivně využít právě 1 hudební nástroj. Jinými slovy, za rozumné peníze díky virtualizaci získáváte mnohem více muziky, protože dokážete provozovat více tónů (síťových služeb) na 1 fyzickém stroji a nepotřebujete kvůli tomu více strojů, protože to všechno zvládá ten jeden. Kdyby však chtěli všichni 4 využívat ten 1 hudební nástroj úplně na plný výkon, nemohlo by to fungovat. Zde se právě vychází z toho, že každý virtuální stroj (hudebník) nikdy nevyužije nástroj na plno a brnká si jen to svoje, čímž si bere pro svůj provoz jen zlomek výkonu.

Abych Vám vysvětlil, jak funguje Fault-tolerance, tak si představte stejnou sestavu, ale vše 2x. Už vám nehrají 4 muzikanti na 1 nástroj, ale 8 muzikantů na 2 stejné nástroje a když kterákoliv z těchto sestav muzikantů vypadne, zachrání to ta druhá sestava a uživatel si ničeho nevšimne, protože hrají to stejné. (nejhorší co se může stát je, že někde během výpadku uslyšíme nějak falešně zahraný tón, nebo na chvíli horší odezvu zvuku). (při výpadku hudebního nástroje nepřichází o rozehranou hru, ani o žádná data, jen to prostě na chvíli zahapruje)

A jak funguje High-availability? Vedle je nachystán stejný hudební nástroj. V případě, když se jim porouchá hudební nástroj, tak se zkrátka přemístí všichni 4 k druhému nástroji a nejpozději za minutu začnou to stejné hrát celé znovu. (virtuální stroje se rebootnou od znovu na druhém hudebním nástroji / fyzickém serveru). Přichází však o rozehranou hru (o to co bylo v operační paměti).

 

 

 

Instalace oVirt na Centos 6.6

 

Je to ještě jednodušší, než jsem původně čekal.

V podstatě stačí zadat jen příkaz:

yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release35.rpm

 

A o vše ostatní včetně závislostí se to postará samo. Jak jednoduché na centosu. Instaluje to ale opravdu kýbl balíčků a závislostí.

Pro nastavení pak napište do terminálu:

engine-setup

A naběhne vám průvodce.

Defaultní local iso domain path je /var/lib/exports/iso (pro vás, kteří si to nastavíte v defaultu a zapomněli byste)

zdroj

Centos 6.x instalace KVM a bridged networking

Mám na instalaci 2 skripty. Obsah prvního:

kvm_install.sh

yum -y install @virt* dejavu-lgc-* xorg-x11-xauth tigervnc \
libguestfs-tools policycoreutils-python bridge-utils -y
semanage fcontext -a -t virt_image_t "/vm(/.*)?"; restorecon -R /vm
sed -i 's/^\(net.ipv4.ip_forward =\).*/\1 1/' /etc/sysctl.conf; sysctl -p
chkconfig libvirtd on; shutdown -r now

Obsah druhého:

chkconfig network on
service network restart
yum -y erase NetworkManager
cp -p /etc/sysconfig/network-scripts/ifcfg-{eth0,br0}
sed -i -e'/HWADDR/d' -e'/UUID/d' -e's/eth0/br0/' -e's/Ethernet/Bridge/' \
/etc/sysconfig/network-scripts/ifcfg-br0
echo DELAY=0 >> /etc/sysconfig/network-scripts/ifcfg-br0
echo 'BOOTPROTO="none"' >> /etc/sysconfig/network-scripts/ifcfg-eth0
echo BRIDGE=br0 >> /etc/sysconfig/network-scripts/ifcfg-eth0
service network restart
brctl show

Ten druhý jsem dokonce spustil, když jsem byl na ssh vzdáleně a stejně se to s tím porvalo dokonale. Takže výborná práce na centos wikině. Ve zdrojích uvádím odkaz na návod.

zdroj

LXC-container uvnitř KVM virtuálního stroje? JDE TO!

Ok, a na co byste to měli potřebovat?

Využití je opravdu spousta. Máte na hlavní mašině KVM virtualizaci a nechcete tam plácat LXC kontejnery? Chcete mít schované LXC kontejnery uvnitř jedné virtuálky, kterou celou zálohujete i se všemi kontejnery, uvnitř virtuální mašiny na KVM? Chcete lépe využít sytémové prostředky na KVMku? Nahodili jste KVM například se starším debianem squeeze a potřebujete nahodit na stejné IP adrese LXC kontejner s debianem Wheezy nebo Debianem jessie? To vše je možné a snadné. K LXC kontejnerům můžete snadno přistupovat ze stejného disku ze stejné virtuální mašiny na KVM, jako se nachází LXC kontejner.

Síťování s LXC kontejnery v mém případě fungovalo v podstatě stejně, jako když děláte bridge pro KVM virtuální mašiny.

Návod možná někdy příště. 😉

zdroj zdroj2 zdroj3 zdroj4 zdroj5

#Opáčko – Port forwarding (nejen) na Debian linuxu

Jednoduchá ukázka port forwardingu:

Internet =========== ><SERVER port eth0 s veřejnou IP 195.0.0.4  eth1192.168.123.1  >============> nějaký počítač ve vnitřní síti s ip 192.168.123.10

Forwardíme port 8080 z internetu na port 80 na nějaký počítač ve vnitřní síti-

# iptables -A PREROUTING -t nat -d 195.0.0.4 -p tcp -m tcp --dport 8080 -j DNAT --to 192.168.123.10:80
# iptables -A FORWARD -p tcp -d 192.168.123.10 --dport 80 -j ACCEPT

Díky těmto 2 příkazům umožníte prerouting z veřejné ip z portu 8080 na vnitřní ip ve vnitřní síti na port 80. Druhým příkazem povolíte forwardování tcp packetu na vnitřní ip na port 80.

Pokud Vám to „nic neudělalo“, tak se zeptejte nějakého Vašeho kolegy, jaký má smysl před příkazem znak #.  😉

K čemu to? Nebudu tady raději vkládat své iptably ze svých serverů na páteři, ale věřte, že tam mám několik desítek řádků, které mi umožňují maximalizovat využití 8x IPv4 adres, které mám ke každé mašině přiřazeny. Dokonce když mi na nějaké ip adrese skončí služba nebo ji přesouvám, chci zajistit zpětnou kompatibilitu a takto potom routuji porty tak, aby uživatel mohl mít klidně stará nastavení a stejně se připojil tam, kam skutečně potřebuje i se starým nastavením.

No a ať Vám tu najdu nějaký použitelný zdroj, tak třeba tento.

Enjoy 😉

Jak pokročil linux po dalším OpenAltu/LinuxAltu?

Zdravím Vás, přátelé,

z OpenAlt/LinuxAlt konference jsem se vracel nabitý poznatky a novými informacemi, které jsem poztrácel nebo nestihl pozískávat během roku.

Když jsem si potom ověřoval tyto informace, tak to bylo velmi zajímavé. Na serverech jsem s linuxem velmi spokojený a v podstatě cokoliv lze, tak se snažím cpát na linuxové servery. Situace je mnohem jiná na desktopu a já to začínám chápat. Na notebooku s linuxem není problém, pakliže neřešíte připojení 2 externích monitorů. Navíc od posledně jsem si všiml, že třeba na ZorinOS fungují defaultně veškeré applety na síť, wifina je detekována, téměř až na grafickou kartu nemusím řešit ovladače. Jsem velmi mile překvapen a nejvíce mě překvapuje, jak snadno a rychle lze nainstalovat tiskárny od Epsonu a Xeroxu i HP a to dokonce z grafického rozhraní, což je přesně to, co uživatel chtěl.

Na desktopu s linuxem rovněž nemám žádný problém, pakliže neřešíte připojení 3 monitorů a drivery na grafiku. To potom teprve začíná ten správný problém a výzva v jednom. Xrandr mi neumožňuje u druhého hd monitoru nastavit rozlišení vyšší než 1024×768, detekuje ho jako neznámý displej. Ale já jsem přece pokorný člověk, takže mám pochopení. Problém nastává tehdy, když jeden HD monitor mám na výšku a druhý na šířku. Ale já jsem přece pokorný člověk, takže se to snažím řešit. Bohužel jsem to však nevyřešil a mám chuť to vzdát. S open-source drivery mi alespoň funguje levý HD displej na výšku v rozlišení 1050×1680, pravý HD display na šířku ovšem maximálně 1024×768. Když přepnu na notebooku s těmito 2 displeji na nvidia drivery verze 331, nastávají problémy, že se modlím, aby se mi to nerozsypalo celé.

Co mi však vadí nejvíc je strašná zmatkovitost nastavení grafiky a rozlišení monitorů. To, že to GUI pro nastavení polohy monitorů nemá moc možností, na to už jsem si posledních pár let zvykl, co mě však neskutečně štve je to, že ještě dnes musí běžný uživatel lozit do terminálu a řešit si takovou základní věc několik dní sám. Jasně, linux je open-source, je zdarma, je škálovatelný a výhodami bych mohl zaplácat zbytek článku, ale co mi fakt vadí jsou tyto základy. To bych byl raději, kdyby si uživatel při prvním připojení monitoru mohl třeba ručně nastavit – pusť tam tohle a tohle rozlišení, klikneme na vyzkoušet, pokud  vše proběhne OK, nastavení se uloží, zapíše do xorg.conf a jedeme dál.

Popravdě jsem po nějakém rozumnějším hledání nenašel, kam se ukládá nastavení rozlišení defaultních driverů, protože xorg.conf mám prázdný a u xranderu jsem nenašel nějaký konfigurák přímo v etc, který bych mohl editnout a rozlišení tam dodat.

To ovšem není ten hlavní problém, po pár dnech bych na to asi přišel, to co mě však vadí nejvíc je nemožnost takový ZorinOS 9 nebo Mint 17 nainstalovat na Intel Atom desku foxconn d51s. Bez GUI to samozřejmě jde OK. S GUI vám to prostě nenaběhne a můžete si dělat co chcete. Jinými slovy – ono to naběhne, ale jediné co vidíte je pravý horní panel s hodinami. Nic víc prostě nenaloadne ani když nainstalujete drivery od intelu. RAM a minimální hw požadavky splňuji, když jsem se snažil editovat rozlišení v xranderu, psalo mi to „Can’t open display“, po zdlouhavém googlení jsem pochopil, že mám vypnout lightdm a zkusit znovu. Stále stejná hláška, nemožnost editovat rozlišení někde ručně a já opravdu nemám čas ztrácet čas několik dní nad linuxem, abych zjistil, kde je problém.

Ať to na závěr shrnu. Na servery je linux moje spása, vše co od toho chceme, to funguje a funguje to set sakra dobře! Na desktopu, pokud máte mainstreamový stroj, na který naleznete většinu ovladačů, tak jste taky v pohodě s jedním monitorem. Z fungování tiskáren jsem opravdu nadšen a vzpomeňme si na doby, kdy nainstalovat tiskárnu = 2 až 4 dny hledáním ovladačů a zjišťováním proč to nejde. Sám jsem si zažil svá muka s netisknoucí tiskárnou Canon MP 540 na Debianu Wheezy a to není tak dávno. (problémy s tiskem mám občas dodnes, jednou tiskárna tiskne, podruhé ne. ).

Pokud ale chcete po linuxu nemainstreamové věci, začínáte mít problém a musíte si cokoliv chcete, bohužel nastavit sami a řešit to s někým dlouhé dny a týdny na fórech a takhle já prostě nemohu fungovat.

Takže pokud se budeme bavit na desktopu, asi pochopím, že pokud uživatel třeba chce hrát hry, že budu tajně fandit steamOS a jakékoliv odnoži blbuntu, aby tam jednoho dne šly mainstreamové hry, což by znamenalo velký nárůst oblíbenosti. Ale do té doby se musí linux vypořádat právě s problémy typu „Jak připojím 6 monitorů, z toho 4 na výšku a 2 na šířku?“ „Jak připojím a funguji tiskárny od Canonu tak, aby mě tiskly pokaždé a ne jen když se jim to líbí a pak abych zbytek dne procházel logy, proč to netiskne“ a Ovladače, bluetooth a lepší integrace neopen-source věcí takovým způsobem, aby to umožňovaly obě licence, ale současně, aby uživatel nemusel progooglit a probdět noci nad nějakým nefunkčním nastavením, co se snaží rozběhat. Fakt by bylo super, kdyby byl v linuxu nějaký automatizovaný skript pro integraci čehokoliv (který by byl open-source) ale umožnil by integraci nějaké nesvobodné věci zcela automaticky pro uživatele. To by bylo asi nejgeniálnější.

A na závěr mi dovolte prohlášení – na ten můj domácí datastore, co jsem instaloval teď v sobotu, jsem měl dát raději buď Centos, nebo Arch linux. Chtěl jsem zkrátka pracovní mašinku, která umožní jít uživateli na internet, ale taky umožní v cronu zálohovat nějaká data ze serveru, umožnit na to ssh přístup a spoustu balíčků (než bych na tom atomu něco skompiloval, měli bychom dalšího prezidenta), aby to byla nějaká LTS distribuce (což mi třeba na debianu vadí) a chci tam mít novější balíčky, než na debianu (ikdyž nebudou úplně stable, což jsem schopen akceptovat, když to není jen datastore, ale i běžný kancelářský stroj na internet). Vcelku se mi líbil ZorinOS, který mi vychvalovali na afterparty OpenAltu. Na netu se dočtete, že je to defakto slabší konkurence Mintu, bohužel ani s jedním se ta základní deska moc dobře v defaultu nepoprala, takže jsem tam vrazil „pitomé“ Lubuntu 14.04 LTS. V podstatě to umí vše co bych od toho potřeboval a dokonce pro toho uživatele, který si k tomu sedne, nebude problém zajít na internet, což byl účel. A neblbne mi tam GUI, ani žádné problémy s rozlišením, vše v defaultu bez problémů nabootuje.

No a jinak vše asi při starém. OpenAlt mi připadl letos jako vykradený LinuxDays, ovšem s o hodně slabší návštěvností, než minulý rok. MInulý rok natřískáno, letos slabo, slabo, slabo. Ovšem ohromně fandím VPSfree.cz, s těmi jsem si tam velmi dobře pokecal o ZFS a linux kontejnerech a openVZ. Takhle geniálním způsobem jsem ještě žádnou jinou architekturu neviděl a musím uznat, že jim to funguje na výbornou. Líbí se mi, že šli cestou nekonvečních technologií. Vzali mašiny od supermicro, na ZFS si poskládali 3x raid1 po 2 discích, takže celkem 6 disků, nad těmito 3xZFS raidy udělali Jbod a takhle to má každá mašina. Virtuálky se jim zálohují na jedno centrální úložiště namísto aby všechna data ukládali na každé úložiště a když by se stalo to nejhorší, tak přijdou maximálně o 1 den záloh. Teď jim to ještě zálohuje dlouho, téměř celý jeden den. Říkali, že až budou používat ZFS send-receive, budou zálohovat fakt za zlomky času a hlavně veškeré zálohy virtuálních strojů budou konzistentní a to je opravdová bomba. V současnosti jim jeden stroj se dvěma 6jádrovými intely s hyperthreadingem zvládnou utáhnout 300 až 400 kontejnerů a to musím uznat, že je tak efektivní, jako jsem nikdy neviděl a to mě velmi inspirovalo třeba na mém hlavním stroji na páteři přejít z KVM na LXC kontejnery, protože používám defakto jednu a tu stejnou distribuci očesanou na kost. Zvládnu tak uspokojit více výkonu za menší režii. Minulý rok LXC prý ještě nebyly tak vychytané, jako letos, takže za mě se těším na LXC. I seznam.cz ze svých 7000 serverů používá 22% z nich pro LXC containery.

OpenVZ vs. KVM? Co použít k čemu? Polopatě! ;-)

Největší hloupost je vzít 2 technologie a přeměřovat pindíky, jako v tomto testu a potom říct, kdo či co je tedy lepší.

Popravdě mi připadne lepší tohle vysvětlení kde spíš autor vysvětluje, co použijete spíš k čemu a proč.

Ve zkratce.

Máte linuxový server, na kterém chcete běžet třeba 10 nebo 20 linuxových virtuálních serverů stejné distribuce? Tak zvolte OpenVZ.
Hledáte virtualizaci, která má sice vyšší režii, ale virtuálky jsou izolovanější a můžete na tom frčet s Windows Servery, Linuxy, Solarisy a ostatními OS? Tak volíte KVM.

Já už používám k dnešnímu datu KVM asi 3. rok a jsem vcelku spokojen, až na některé výhrady. Předtím jsem používal řešení od Vmwaru, Citrixu, osahal jsem si i Hyper-v. Virtualbox a další desktopová řešení ani nepočítám.

Pokud máte slabší hardware, tak volíte openVZ, pokud máte silnější hardware, který vyžaduje virtualizační instrukce procesoru, tak KVM.

Enjoy 😉

Jak ze vzdáleného linuxového serveru spustit rdesktop na vašem Windows?

Nikdy si nezapamatuju pořádně všechny parametry, tak to pořád odněkud kopíruji a tak mě napadlo, že bych to mohl tentokrát už začít kopírovat z mého webu.

 

rdesktop -g 1024x768 -k en-us -d název_domény -a 16 -u username  jméno_serveru

-g udáváte velikost rozlišení

-k klávesnici a její rozložení. Takže pokud chcete českou tak

-k cs-cz

-d doména -> v případě serveru franta.doména.cz uvádíte pouze: -d doména nebo -d doména.cz

-a 16  počet bitů barevné hloubky. Lze 8,15,16,24

-u uživatel

jméno_serveru -> Pokud máte celé doménové jméno serveru franta.doména.cz tak uvádíte pouze franta

link na manuál zde

pokud se snažíte dostat na linuxový server z windows a chcete, aby Vám takto z terminálu rdesktop naběhl, tak potřebujete mít na windows nainstalován Xming server – což je x11 GUI server pro Windows, díky kterému spustíte vzdálené linuxové aplikace na serveru ovšem jejich výstup – zobrazení bude na Vašem počítači s windows.  Pokud lezete na terminál server v Putty, musíte mít v /ssh/X11/ zaškrtnutou možnost Enable X11 forwarding.

 

Enjoy 😉

Zvládnout XEN? Otázka 2 hodin, maximálně odpoledne! ;-) (Debian Wheezy/ubuntu 12.04)

Jde to i bez LVM hezky imagem. 😉

Než začnete na linuxu instalovat jakoukoliv virtualizaci, sjeďte si základy bridgování a dalších srand. V podstatě by se dalo říct, že není rozdíl v nastavování bridgů pro Xen a pro KVM.  Je to dobře vysvětleno už v návodech na KVM s debianem Squeeze zde. Od bodu  apt-get install bridge-utils až po to, jak nějak má vypadat Váš /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
#iface eth0 inet dhcp
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address 192.168.0.100
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

1) instalujeme

apt-get install xen-linux-system xen-tools

2) Vložíme podporu vix virtuálních rozhranní pro budoucí virtuální mašiny. Uvedenými 2 příkazy se to doplní na konec souboru. etc/xen/xend-config.sxp

echo "(network-script network-nat)" >> etc/xen/xend-config.sxp
echo "(vif-script     vif-nat)" >> etc/xen/xend-config.sxp

3) Tohle je riskantní a dávejte si bacha, abyste příšte nabootovali! Xen stručně řečeno je v podstatě upravený image vašeho současného linuxu, takže potřebujete do něho naboootovat, aby Vám xen začal vůbec chodit. První příkaz hodí xen jako první k bootu a druhý příkaz rebootne server/počítač na kterém se snažíte xen rozchodit.

dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen update-grub
reboot

4) Příkazem

xen dmesg

Zkontrolujete, jestli je vše OK.

5) Příkazem

xm list

Se dozvíte, jestli Vám xen nastartuje a vypíše to něco jako:

xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 612 2 r----- 2192.4

Name = název

ID je zkrátka pořadové číslo

Mem je použitá paměť

VCPUs: je počet použitých procesorů

State – tam je důležité, že když to běží, tak tam uvidíte r—– a pokud uvidíte -b—— tak to znamená blocked. Ale k tomu se dostaneme.

Na LVM se tentokrát vykašleme, protože ne každý lvm upřednostňuje a já si rozjíždím xen na datastoru s intel atomem, kde jsem LVM nepoužil protože by to pro mě nemělo žádný přínos.

6) Příkazem

nano /etc/xen-tools/xen-tools.conf

se dostaneme do konfiguračnímu souboru, kde můžeme nastavit defaultní configurace pro nové Xeňácké Virtuální stroje (dále jen VM). V mém případě jsem si nastavil, aby každá virtuálka měla nastavenou ip adresu brány, masky a broadcastu.

gateway = 192.168.123.1
 netmask = 255.255.255.0
 broadcast = 192.168.123.255

Ale tento bod je teoreticky nepovinný. CTRL + O zapíšeme a uložíme změny. CTRL X ukončíme editor nano. Pokud jste neměli nainstalovaný editor nano tak použijte příkaz

apt-get install nano -y

(Přepínač -y znamená -> neptát se na potvrzení na y a enterování, prostě to rovnou začne bez dalšího optávání rovnou stahovat a instalovat).

Dále se ve stejném souboru nacházejí tyto řádky:

size = 4Gb # Disk image size.
swap = 128Mb # Swap size

Editací těchto 2 řádků si zajistíte příkazem size velikost diskového image. Tedy souboru, do kterého bude váš virtuální stroj (dále jen VM) zapisovat jako kdyby to byl virtuální harddisk. Swap je soubor, do kterého bude Váš VM zapisovat, jako kdyby to byl diskový oddíl určený na odkládací prostor pro Váš linux na VM.

7) Vytvořte si adresář, kde se Vám budou ukládat .img virtuálních strojů příkazem:

cd /
mkdir xen
cd xen
mkdir image

Spusťte tento příkaz potom co si ho editnete:

xen-create-image --hostname=nazevVirtualky \
 --memory=384mb \
 --vcpus=1 \
 --ip=192.168.123.32 \
 --netmask=255.255.255.0 \
 --gateway=192.168.123.1 \
 --dir=/xen/image/ \
 --dist=wheezy

–memory říká – kolik bude mít vaše virtuálka RAM, jak vidíte, dal jsem ji 384MB ram.

–vcpus=1 říká, že virtuálka bude mít jen 1 jádro procesoru

–ip= ipadresa virtuálky, kterou to tomu nastaví a přiřadí hezky za vás 😉

–netmask – maska podsítě kterou to virtuálce nastaví

–gateway – ip adresa brány, kterou se bude virtuálka dostávat do internetu. Pokud Natujete, tak nastavujete ip adresu virtuálního rozhranní, pokud používáte bridge, to znamená, že virtuálka je na síti na stejné úrovni, jako je fyzický stroj, na kterém běží, tak použijete pravděpodobně něco jako ip adresa rozhraní br0 nebo rozhraní br1 apod.

–dir=/xen/image <- to je adresář, kde se vytvoří oba dva image

–dist=wheezy <- distribuce debian wheezy.

Pokud chcete změnit vytvářecí velikost diskového image VM, tak stačí připsat parametr –size=20Gb  (tím nastavíte velikost virtuálního image na 20Gb). Standardně byla nastavena v configu na 4Gb.

Ta lomítka symbolizují další řádek. Tato procedura potom co odkliknete enter může trvat i několik minut, na starých strojích i desítky minut v závislosti na tom, jak velké image vytváříte.

8) Pokud jste si po vytvoření virtuálky nepoznamenali heslo na roota, tak dejte příkaz

tail /var/log/xen-tools/nazevVirtualky.log

a vypíše Vám to něco jako:

All done
Installation Summary
---------------------
Hostname : nazevVirtualky
Distribution : wheezy
IP-Address(es) : 192.168.123.32
RSA Fingerprint : cf:58:63:7e:51:e1:at:ak:da:le
Root Password : VaseHesloNaPrihlaseniPodRootaNaVirtualce

9) Pro nahození virtuálky (pokud se nenahodila a nevidíte ji po zadání příkazu xm list) napište příkaz:

xm create /etc/xen/nazevVirtualky.cfg

10) Potom co byste ji měli vidět v seznamu, tak by virtuálka měla jít pingnout a už by měla být nastartovaná.

Pro připojení na terminál virtuálky napište příkaz:

xm console nazevVirtualky

Případně z jiného stroje pak už půjde

ssh root@192.168.123.32

a mělo by Vás to tam připojit.

 

Edit: Pro vyjetí z konzole xm console <názevVirtuálky> stiskněte:

Buď: Ctrl + ‚]‘
Anebo: Ctrl + ‚5‘

Enjoy -> zdroj

 

Doporučím na závěr tento zdroj. A další. A ještě tenhle a tenhle.

Openstack a fyzická architektura – jak to má vypadat? Openstack a high-availability ? Vše se dozvíte.

Pokud chcete vědět, jak má vypadat fakt kvalitní infrastruktura pro menší openstack cluster tak zbystřete zrak a klikněte na následující odkaz. Mají to tam velmi dobře popsané a dokonce tam rozebírají i několik možností architektury. Takový článek jsem hledal posledních pár dní a nemohl jsem nikde na googlu nic rozumného a použitelného najít. Všude se Vám plete do fyzické architektury teoretické diagramy, které říkají jaká bude logická struktura, tady to máte hezky na zlatém podnose.

 

 

Enjoy

 

-> LINK <- 

Openstack – začátky, které pochopí i slabší jedinci

Nezapomenu na doby, kdy jsem si říkal, jak si dokonale zautomatizuju KVMko, jak si všechno pořeším do vlastního High-availability mini-clusteru a pak objevím openstack a uvědomím si, jak jsem byl naivní, když jsem si myslel, že můžu svými silami udělat něco, co by se alespoň vzdáleně blížilo High-availability řešení pro menší podnik.

Nebudu psát, jak mi openstack sedí a jak se mi líbí vše, co vypadá strašně komplikovaně, protože ruku na srdce, jakmile jsem si ošahal většinu nebo všechny funkce VMwaru, tak mě začal zajímat Citrix, až jsem si ošahal a vyzkoušel Citrix, tak mě začal zajímat KVM a příkazy z virshe. A najednou je načase, kdy už se i na KVMku začínám nudit stereotypem a chtěl bych něco „víc“. Najednou objevím openstack, pak se to začne objevovat i napříč všemi distribucemi a dneska chápu, že openstack je pro mě něco, co někdo psal akorát pro mě. A když jen vidím, čtu o tom a studuji to, tak se mi neustále v hlavě vybavují všechny možnosti a případy použití openstacku a když to porovnávám s konkurenčními technologiemi, tak musím uznat, že na to, že je openstack zadarmo, jenom to vyžaduje znalosti a trošku více času na začátku, tak je to samostatná kategorie o sobě, nemůžete to srovnávat s VMwarem nebo Citrixem, které se pohybují v kategorii freeware* ovšem v jejich podání ale taky v kategorii „neumí to skoro nic“. V cenové relaci „hezky mi to zaplať“ dostanete balík „už to něco umí“. V cenové relaci „plať jako mourovatej“ se teprve nacházíte v kategorii „umí to všechno“. Openstack je v tomhle super, protože dostáváte zadarmo to, co by se nacházelo jinak už v kategorii „hezky mi to zaplať“ nebo dokonce v kategorii „plať jako mourovatej“.

Tady přikládám odkaz na vcelku perfektní úvod k openstacku. Přišel jsem ohledně openstacku na jednu důležitou věc. Člověk na začátku neví k čemu je který modul dobrý, teď k tomu musí člověk chodit do práce, do toho starosti a po večerech sedíte nad openstackem a zkoumáte jak co funguje, než se k tomu dostanete za týden, tak samozřejmě už zase nic nevíte a navazujete na začátku tam, kde jste začali minule, narozdíl od toho, abyste se to snažili od začátku hlava nehlava nějak nahodit a pak si s tím hrát.

Proto pro snadnější zorientování na začátcích přikládám odkaz na článek, který věnuji všem začátečníkům s openstackem.

Občas tedy nakonec volnost, jakou poskytuje openstack v podobě tolika modulů a varianta architektur, může být pro některé do té doby zatvrzelé citrixáře, VMwaráky nebo KVMkaře, Xenaře a ostatní možná překážkou k tomu, aby hlouběji a snadněji pronikli do Openstacku.

 

 

Windows Server 2012 Standard aktivace hlásí error 0x8007007B

Řešení je spustit cmd (tlačítko WIN + R)

napsat cmd a dát enter.

 

a do příkazové řádky napsat:

slmgr -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

Kde xxxxx nahraďte vašim licenčním kódem a dejte enter. Chvilku počkáte a pak vám to vyhodí, že byl licenční kód úspěšně aktivován. Odentrujete a to že je vše ok ověříte /start/nastavení/ovladací panely/centrum akcí/ a tam už Vám to nebude hlásit vypršelý klíč nutný k aktivaci.

 

V mém případě fungovalo. zde zdroj.

KVM virsh list nic nezobrazí / virsh list doesn’t show anything / virsh freezes

Průser jak mraky…Spustím virt-manager, že se přihlásím a nic…Zasekne se to na connecting… a nic…

Přihlásím se na ssh serveru, dám příkaz

virsh list

a nic se nezobrazuje, dokud nedám CTRL + C tak je konzola zaseknutá a nic mě to dál nepovolí…

 

Po 355 dnech a 20 hodinách provozu debianu squeeze bez restartu jsem udělal rozhodnutí, že dokončím oněch 365 dní a že to dokážu bez restartu. A světe div se, zatím se to daří a překonal jsem další krizovku.

Problém celého řešení byl ten, že /etc/init.d/libvirt-bin restart nepomáhá. Protože to proces neshodí a když dám pgrep libvirt tak to ukazuje stále stejné ID procesu i po /etc/init.d/libvirt-bin restart. Kde tedy může být problém?

kill $(pgrep libvirt) nepomáhá! Proces nejde zabít, ačkoliv jsem root!

Takže řešení na tento problém bylo drsnější, ale efektivnější:

kill -9 $(pgrep libvirt)

Po tomto příkazu jsem shodil libvirt-bin na tvrdo, dále příkazem:

/etc/init.d/libvirt-bin start

nebo

/etc/init.d/libvirt-bin restart

Pak už libvirt naběhne OK a už jde bez problémů ovládat.

Enjoy 😉

Jak na LVM na linuxu (ubuntu 12.04 LTS za roota/ Debian Wheezy)

Předpokládejme, že už máte vytvořené LVM od instalace:

 

1) vgdisplay

zobrazí něco jako:

— Volume group —
VG Name hostnamestroje
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 203,71 GiB  //celkovávelikost LVM jednotky/jednotek
PE Size 4,00 MiB
Total PE 52151
Alloc PE / Size 51962 / 202,98 GiB   //kolik je alokováno teď
Free PE / Size 189 / 756,00 MiB //kolik lze ještě přidat
VG UUID aWWxDu-oma6-lot1-M2f6-AsED-hUf7-k1tPn4

zdroj

2) Chceme zvětšit logickou jednotku s názvem „usr“ o velikost dalších 2GB.

lvextend -L +2G /dev/volgrp/usr /dev/sda4  //+2G znamená, že chceme k současné velikosti přidat další 2giga za tím už je název jednotky.

Extending logical volume usr to 8.00 GB //vypisuje současnou velikost jednotky usr, tedy 8 gb.
Logical volume usr successfully resized

 

3) Jak snížit velikost současné LVM – zde:

Další užitečný zdroj.

 

 

SCP copy on specific port other than 22

 

 

scp -P 24 -r localdirectory user@destinedHostname:/directory/directory/

it means – copy on port 24 recursively localdirectory to destinedHostname server as a destination as user to /directory/directory (absolute address).

 

Enjoy 😉

První funkční návod na NTP a ntpdate

Často se mi stávalo, že utility na synchronizaci času počítače/serveru ntp a ntpdate prostě nefungovaly, jak měly.

Dnes už vím, že na debianu squeeze stačí jen zadat apt-get install ntp ntpdate -y

…a o zbytek se postará i v defaultním režimu linux sám. Samozřejmě povolit to na firewallu je druhá věc. Ale na to tam jsou taky pravidla.

 

Problém jenom je, že třeba na KVM virtualizaci musíte tohle nainstalovat na každý stroj zvlášť.

zdorj: http://articles.slicehost.com/2010/11/8/using-ntp-to-sync-time-on-debian

scp connect on a specific port // jak se připojit na scp na jiném portu než 22 ?

Typický problém na serverech, kde se šetří s ip adresami a vy se připojujete přes všelijaké porty úplně jinam, než byste se normálně měli připojovat. To je i můj případ. Dostal jsem jen 8 veřejných IP adres na servery a dalších virtualizované servery musím schovávat za hlavní veřejnou IP.

Teď už ale k příkazu:

chci něco kopírovat odsud na vzdálený server port 90 namísto portu 22 přes scp, to udělám takto:

scp -P90 -r kopirovany_adresar/ nejaky_user@ipadresa_serveru_nebo_jeho_domena:/adresar/adresar

přepínač -r zajistí, že se zkopíruje celý adresář včetně jeho samotného.

-P90 (pozor! P musí být velké!) připojí na port 90 namísto standardního portu 22.

nejaky_user doplňte za vašeho uživatele, to stejné s ip_adresa_server_nebo_jeho_domena.

 

Enjoy 😉

Offline konsolidace serverů na KVM?

Potřebujete migrovat současný server do virtuálního serveru na KVM, nebo-li konsolidovat?
Tak se vykašlete na drahá komerční řešení, stačí Vám k tomu blbé live cd.

Potřebujete přemigrovat 1 partitionu ze serveru. Připojíte externí disk, nahodíte live cd linuxu, nabootujete, zalogujete pod roota a potom:

mount /dev/sda1 /mnt
#sdx je váš diskový oddíl, třeba /dev/sda1 v mém případě nebo /dev/hda1

dd if=/dev/sda1 | gzip > /cesta/k/imagu.gz

Po dokončení odpojíme disk, příjdeme k serveru s KVM. Vytvoříme virtuální stroj, nabootujeme opět live cd, vytvoříme třeba pomocí fdisku, parted nebo gparted(gparted je GUI utilita) příkazem gparted v terminálu nový disk, který musí být minimálně stejné velikosti jako původní diskový oddíl.

Pak už stačí jen:
gzip -dc /cesta/k/imagu.gz | dd of=/dev/sda1

zdroj

Takto to dělám já a funguje to. Dotazy klidně pod článek .-)

Linux mi píše, že zadaný soubor nebo cesta neexistuje, ačkoliv existuje?!

Tak to jste narazili na stejný problém, jako já před chvílí na debianu squeeze 6.0.7 amd64. Z názvu vidíte, že se jedná o 64bitový linux. Já se snažil spustit 32bitovou aplikaci, pro kterou můj 64bitový linux neměl podporu.

K vyřešení problému mi stačil příkaz:
apt-get update -y
apt-get install ia32-libs-dev -y

pokud by se objevil nějaký problém, tak:
apt-get update –fix-missing

Po nainstalování balíčku ia32-libs-dev už vše funguje.

Pokud chcete vědět víc, doporučuji tento link.

KVM: Ovládejte kvm z windows

Poradí tento článek.

http://blog.allanglesit.com/2011/03/linux-kvm-managing-kvm-guests-using-virt-manager-on-windows/
Ve zkratce nainstalujte x-ming  a potom si nastavte podporu v putty na SSH/X11/odškrtnout enable X11 forwarding a už vám poběží gui aplikace z terminálu.

 

 

 

KVM: qemu: could not open disk image Permission denied

…i to se stává.

 

KVM je nevyzpytatelné a tohle se stává často zejména kvůli přístupovým právům.

Pokud jste již vyčerpali všechny možnosti a chcete to „prostě jen rozchodit“ tak mrkněte sem:

http://www.plugboot.com/index.php?option=com_content&task=view&id=239&Itemid=66

Ve zkratce:

1) Editněte soubor /etc/libvirt/qemu.conf

2)  Najděte v něm část

# The user ID for QEMU processes run by the system instance
# user = „root“
# The group ID for QEMU processes run by the system instance
# group = „root“

A odmažte první znak na začátku # před user a group takto:

# The user ID for QEMU processes run by the system instance
user = „root“
# The group ID for QEMU processes run by the system instance
group = „root“

pak změny uložte a dejte:
/etc/init.d/libvirt restart
Nebo restartujte stroj, ale předchozí příkaz jistě pomůže.

Jste IT. Jak vysvětlíte ekonomovi Virtualizaci a to, že to něco ušetří?

To je docela náročné téma. Spousta ekonomů ani neví, k čemu že je to ten server, ale ví, že ve firmě je asi hodně důležitý. Ti technicky zdatnější ekonomové vědí, že server je to, kde má firma data. Ti úplně skvělí ekonomové vědí, že díky serverům firma může fungovat a že IT je ten frajer, který tomu rozumí a který se o to stará, proto se v tom lepším případě nesnaží nějakým způsobem snižovat výdaje na IT, pokud to není nezbytně nutné.

No, ale stejně se mi podařilo dnes jednomu ekonomovi vysvětlit, co že to ten server je a jak je výhodná virtualizace z hlediska financí, úspor, hardwaru atd…

Prvně jsem musel vysvětlit, co že to ten server je a jak si to teda představit? Jak si má ekonom představit server? No…vysvětlil jsem to více než jednoduše. Fyzický server vypadá takhle -> odkaz na fyzický server <- a takový server je zapojený v -> odkaz na fotografie serverovny a datacentra <- . Tím jsem objasnil jak to teda fyzicky vypadá.

Pak jsem musel vysvětlit, jak vlastně FUNGUJE takový server a co to teda na tom internetu dělá, když zapnu počítač a napíšu třeba seznam.cz nebo google.com. To pro mě bylo snazší vysvětlit vlastními slovy.

Potom pro mě bylo nejdůležitější po vysvětlených pojmech říct, jak to tedy všechno pracuje a že servery vlastně tvoří internet. Nebýt serverů, tak tu nemáme internet (ve své podstatě). No a proč bych musel pracně vysvětlovat něco osobně ekonomovi já, když už to udělal někdo možná i lépe na youtube? A taky že jo. Odkaz na tohle video zabral. Vysvětlil Windo Další otázky jsem pak už zodpověděl ekonomovi osobně. Po vysvětlení projevil ekonom dokonce nevídaný zájem o další informace z oblasti, protože pokud se na tom dá ušetřit, nebo dokonce i vydělat, tak to ekonoma zajímat bude vždycky.

Problém byl, že ekonom nechápal, když jsem mu postnul zajímavé video o virtualizaci na cloud od master.cz. Asi jsem se naivně domníval, že to pochytí.

Pak jsem mu poslal svoji přednášku, kterou jsem přednášel na univerzitě. Na čež mi odpověděl, že rozumí jen prvnímu slajdu a dalším už nikoliv a že má ve mě neskutečnou úctu a respekt, protože se v tom fakt vyznám a že jsem fakt expert (ano, ego je taky důležité…). V tu chvíli mi došlo, že vysvětlení na obrázcích s jednoduchými komentáři fakt závisí jen na přednášejícím a pokud jsem to já dokázal dobře přednášet, ale neměl jsem tak dobré materiály, tak mi až teď teprve došlo, že ačkoliv to ti lidi tenkrát pochopili fakt dobře, tak to nebylo slajdy, ale mnou, protože jsem jim to potom ještě ukazoval na cvičení, kde si uvedené technologie přímo osahali. Když něco někomu vysvětlujete liší se to od učení ho s danou technologií pracovat.

Libí se mi Einsteinova hláška „Pokud to nedokážete vysvětlit jednoduše, tak tomu dostatečně dobře nerozumíte“. A je to tak.

Naštěstí to už teď onen ekonom chápe a jsem rád, že jsem někomu mohl rozšířit obzory a inspirovat ho.

 

 

Debian Linux (Squeeze): Informace o discích

Dnes krátce o tom, jaké užitečné příkazy vám poví různé informace o discích na linuxu:

SMART test:

(pokud nemáme nainstalován smartctl tak apt-get install smartctl -y )

smartctl –test=long /dev/sda
Až test doběhne, tak se na výsledek podíváme přes příkaz:
smartctl -l /dev/sda

Další užitečný příkaz je blkid.

Vypíše UUID disku, /dev/zařazení, LABEL a TYPE (ext3, nebo linux_raid_member apod…).

Další utilita je hdparm:

instalace pomocí: apt-get install hdparm -y

hdparm -I /dev/sda  <-tento příkaz poskytne obsáhlé informace o disku

Další příkazy zobrazí další podrobné informace o discích:

lshw -class disk – class storage

lshw -short -C disk  (vypíše konkrétní informace a chvilku to trvá)

lshw vypíše který pevný disk odpovídá jakému zařízení. Doporučuji!

Další podrobný příkaz je :

smartcl -d ata -a -i /dev/sda (vypíše v podstatě hardware disku, id, seriové číslo disku atd…)

Tyto utility se instalují pomocí:
apt-get install lshw -y
apt-get install hdparm -y

 

Měnili jste základní desku a nenašlo to eth0?

Vzácný problém, který se však vyskytne na jakémkoliv virtualizovaném serveru když něco měníte (hlavně na KVM), anebo když vyměníte počítači základní desku. Počítač v takovém případě třeba nevidí eth0.

Řešení:

rm -rf /etc/udev/rules.d/70-persistent-net.rules

touch /etc/udev/rules.d/70-persistent-net.rules

shutdown -r0

Příkazem Shutdown -r0 restartujete počítač.

Po restartu Vám na debianu naběhne vše jak má a konečně vidíte eth0, kterou jste předtím neviděli.

Linux Bonding teaming na Debian Squeeze + KVM

Situace jaká je na 3serveru. Jsou tam síťové karty eth0 eth1 eth2 . Rozhraní pro KVM je br0. (samozřejmě vy můžete mít více síťových karet, nebo taky jen eth0 a eth1) (ještě tam mám další rozhraní virbr0 ale o tom dnes mluvit nebudu).
Abychom mohli rozjet takzvaný bonding/teaming/link agregaci, potřebujeme provést následující:
Nainstalujeme balíček pro bonding:
apt-get install ifenslave-2.6  

dále zazálohujeme starou verzi nastavení připojení k síti (kdyby byl náhodou problém) následujícím příkazem:
cp /etc/network/interfaces /etc/network/interfaces.old
No a pak jsem na to udělal script, ve kterém jsem si nastavil, co to tam má nastavit. Protože script používám velmi často, tak si ho jen vždycky editnu, spustím a všechno se provede za mě:

echo „“ > /etc/network/interfaces
echo „auto lo“ >> /etc/network/interfaces
echo „iface lo inet loopback“ >> /etc/network/interfaces
echo „auto bond0“ >> /etc/network/interfaces
echo „iface bond0 inet manual“ >> /etc/network/interfaces
echo „slaves eth0 eth1 eth2″ >> /etc/network/interfaces
echo “ bond_mode balance-tlb“ >> /etc/network/interfaces
echo „bond_miimon 100″ >> /etc/network/interfaces
echo “ bond_downdelay 200″ >> /etc/network/interfaces
echo “ bond_updelay 200″ >> /etc/network/interfaces
echo „#auto eth0“ >> /etc/network/interfaces
echo „#iface eth0 inet manual“ >> /etc/network/interfaces
echo „auto br0“ >> /etc/network/interfaces
echo „iface br0 inet static“ >> /etc/network/interfaces
echo „address 192.168.123.33“ >> /etc/network/interfaces
echo „netmask 255.255.255.0“ >> /etc/network/interfaces
echo „gateway 192.168.123.254“ >> /etc/network/interfaces
echo „dns-server 81.31.33.19“ >> /etc/network/interfaces
echo „bridge_ports bond0“ >> /etc/network/interfaces
echo „bridge_fd 9“ >> /etc/network/interfaces
echo „bridge_hello 2“ >> /etc/network/interfaces
echo „bridge_maxage 12“ >> /etc/network/interfaces
echo „bridge_stp off“ >> /etc/network/interfaces

No a potom restartneme síťové připojení pomocí:
/etc/init.d/networking restart

A voila máme bonding! 🙂

Stačí připojit jen 1 kabel do jakékoliv ze síťových karet a můžeme fungovat!

Adresy v tomto článku si zaměňte za nastavení vašich adres. S bridge jsem nic nedělal, jenom jsem si teda nastavil „bridge_stp on“

Kdyby se něco po…kazilo tak stačí přiběhnout k serveru a napsat cp /etc/network/interfaces.old /etc/network/interfaces a máte nahozenou zpět starou konfigurací.

Kterou lze vyřešit buď restartem serveru, nebo pomocí /etc/init.d/networking restart a jste zase UP.

Tohle si prvně raději někde vždycky natrénujte a potom to teprve dělejte na ostrém serveru, protože ať víte, co děláte a že to děláte správně!

 

RAID na Debian Squeeze? To je jízda!

Musím se pochlubit, že SW RAID 5 na Debianu squeeze mě fakt dostal.

Čekal jsem, že budu muset pevný disk načíst do pole a pak začne teprve obnova, až já zadám příkazem načtení disku do pole. Všechno je jinak. Zapnu server bez hlavního disku (/dev/sda), bez problémů naběhne GRUB2, spustí se Debian squeeze a automaticky se po náběhu systému spouští obnova disků. Přiznávám ale, že pokud by se mi tohle stalo při ostrém provozu, že by najednou z ničeho nic vysadil disk, tak by to nedopadlo asi nejlépe, kdyby do šrotování s databází a dalšími daty musely disky šrotovat i obnovování dat na SPARE (záložní) disk. Což je vcelku zajímavá myšlenka autorů, aby došlo k obnově co nejrychleji. Na druhou stranu asi ale chápu, že mechanismus je tak chytře navržen, že se počítá s následující možností:

Disk vypadne tehdy, když dochází k vynucené kontrole povrchu disku. Tehdy je disk označen za vadný a vyřazen z pole. Spouští se obnova na záložní disk. A kdy se provádí tato kontrola? No samozřejmě tehdy, kdy to chce vynutit administrátor serveru, takže je vše v pořádku a toto řešení je takzvaně blbuvzdorné, protože se provádí tehdy, když je v cronu naplánovaná kontrola. A přece nebude server čekat, až se pan administrátor uráčí přijít k serveru, zjistit že došlo k degradaci pole a pak teprve na jeho žádost začít pracovat. NE! To musí jít hned a tohle je skutečně problémy řešící řešení, za které Debianu Squeeze na jádru 2.6.32.5 AMD64 musím skutečně vzdát hold.

Zatím se mi však obnovuje RAID 5 pole a neobnovuje se RAID1 pole, což je zvláštní, že to nevzalo od nejmenšího diskového pole, ale od největšího. Další geniální věcí je GRUB2. Ten mi sesnalo snad samotné nebe a teprve teď mi dochází, jak masivní rozdíl je mezi GRUBem 1 a Grubem 2. Zatímco GRUB neumí pracovat příliš dobře s jakýmkoliv SW RAID polem, GRUB2 to troufám si říct, zvládá na výbornou.

Je tedy pravda, že jsem aplikoval před vyhozením disku ze serveru příkaz grub-install /dev/sdb to stejné pro sdc a sdd, ale myslím si, že tento příkaz neměl na nic vliv, protože mi to vypsalo chybu.

Tohle moji důvěru v SW RAID na linuxu vcelku slušně zvýšilo. Uvidíme však, jaký bude reálný provoz na serveru. Kombinace úsporný Quad core procesor (bez L3 cache a s frekvencí jen 2.2Ghz), 16 GB RAM DDR3, RAID 5 bez SWAPu, virtualizací na KVM a 4 disky, kde 2 jsou z jedné série, ale jiného datumu, další je stejný typ disku, ale jiná série a poslední pevný disk od jiného výrobce, bude jistě zajímavou zkušeností. Největší strach mám z nedostatečného výkonu úsporného procesoru. Přeci jen absence L3 cache nemusí být zrovna výhra a frekvenci 2.2Ghz rovněž nevidím zcela nejoptimističtěji. Na druhou stranu současný 2.5Ghz čtyřjádrový procesor s architekturou K10 současného serveru podle utility powertop naznačuje, že jen v 14,5% času je využíván maximální výkon 2.5Ghz. Troufám si tedy tvrdit, že pokud na 85,5% procesorového času stačí poloviční rychlost procesoru, pak mohu být naprosto vklidu s nadcházejícím úsporným čtyřjádrovým procesorem, který mi ušetří již za méně než rok, nákupní náklady procesoru. A ruku na srdce, že TDP 45W oproti TDP 125W půjde jistě poznat.

/boot diskový oddíl nestačí! Na všech discích musí být nainstalován a nastaven grub!

Podle tohoto článku : http://www.texsoft.it/index.php?c=hardware&m=hw.storage.grubraid1&l=it

je nutno nastavit na všech discích v raidu GRUB v případě selhání „primárního“ z nich.

Uvedu příklad z článku
Máme 2 disky. Oba jedou v RAID 1. Při instalaci linuxu se nainstaloval však grub pouze do /dev/hda To znamená, že pokud by tento disk vypadl, server by znovu nenabootoval, protože by neměl disk, na kterém by byl nainstalován grub.

Řešení je následující:

pomocí apt-get install grub nainstalujeme grub.

Pak spustíme grub v terminálu pomocí příkazu grub .

Po napsání: root(hd0,0) nám to vypíše krátké info o tom, s čím jdeme pracovat.

další příkaz je setup(hd0)

Pro druhý disk:
root(hd1,0)

setup(hd1)

Až skončíme, tak napíšeme quit a hotovo.

Pokud by vypadnul disk, není potřeba nijak měnit /boot/grub/grub.conf . Systém bezproblému naběhne.

Lze to otestovat tak, že vypneme server, odpojíme první disk a necháme server naběhnout (nabootovat) jiný disk.

po zadání terminálového příkazu cat /proc/mdstat nám to ukáže [_U] kde _ znamená vypadlý disk a U znamená UP – připojený disk.

Po zadání příkazu:

mdadm –detail /dev/md0

(za md0 si dosaďte identifikátor vašeho diskového pole. Může to být md0 až md255)

vidíme už degraded ve State.

Teoreticky by šlo vypsat pouze

mdadm –detail /dev/md0 | grep degraded

Pokud příkaz nevypíše nic, diskové pole není degradované. Pokud vypíše řádek, kde bude napsáno „degraded“, tak jeden z disků je „vypadený“.

Navrácení disku do pole zpět

píšeme příkazy:

fdisk -l
Tento příkaz nám vypíše seznam všech disků a diskových polí.

Příkaz:

cat /proc/mdstat
Vypíše seznam aktivních připojených disků do raid pole. Pokud odpojený disk byl /dev/sda neměli bychom ho tu vidět a pokud jsme ho připojili znovu stejně tak, jak byl předtím, měl by mít opět stejný název zařízení, tedy /dev/sda. Pokud má 2 oddíly. Tak první z nich je /dev/sda1 a druhý /dev/sda2. Představme si, že máme 2 diskové pole. První je /dev/md0 a druhé je /dev/md1 .Pokud první oddíl patří do prvního diskového pole a druhý oddíl disku patří do druhého diskového oddílu, budeme psát následující příkazy uvedené níže:

Pro přiřazení disku do diskového pole použijeme příkazy:

mdadm –manage /dev/md0 –add /dev/hdc1

a do druhého diskového pole druhý oddíl stejného pevného disku.

mdadm –manage /dev/md1 –add /dev/hdc2

 

Pro sledování jak daleko doběhla synchronizace disků můžeme zjistit tímto příkazem docela interaktivně:

watch -n1 cat /proc/mdstat

Příkaz watch bude každou vteřinu vykonávat příkaz cat /proc/mdstat, takže v reálném čase můžeme sledovat na terminálu, jak jsme daleko se synchronizací.

Ohledně synchronizace. Tu děláme někdy ve 4 ráno (můžeme to naplánovat pomocí cronu), kdy je minimální provoz.

 

Ještě ohledně přípravy nového čistého disku pro RAID pole. Raid pole nepřežvýká naprosto čistý disk bez oddílů. Ty musíme vytvořit. Na linuxu existuje spousta utilit, jak toho dosáhnout.

příklad

Pokud máme 2 diskové pole. První diskové pole raid 1 o velikosti 1GB a druhé diskové pole RAID5 o velikosti 200GB, musíme na disku vytvořit 2 oddíly. První 1GB typu RAID (asi s Boot příznakem, pokud je to bootovací první oddíl, že?) a druhý oddíl taky typu RAID bez příznaku bootu (tam budou data a třeba kořenový adresář / ). Takový disk pak stačí vzít a zařadit do diskového pole a už by měl disk být synchronizován a fungovat. POZOR! Při zapojení nového disku je nutné znovu provést postup pro vytvoření GRUBu na novém disku, aby z něj server dokázal nabootovat v případě výpadku jiného disku!

 

Pokud používáme GRUB2, tak ten už nativne podporu RAIDu umí! viz odkaz.

 

Linux: Raid : Když selže disk….

…tak nejste v míst kam slunce nesvítí, ale můžete udělat tohle:

mdadm --fail /dev/md1 /dev/sda

mdadm --remove /dev/md1 /dev/sda

za /dev/sda si přiřaďte jméno vadného disku. Za /dev/md1 si přiřaďte vaše diskové pole. Já mám /dev/md0

Prvním příkazem dáme najevo, že ten disk odešel. A tím dalším ho odstraníme z pole.

Doporučuji tento odkaz: http://www.uzitecne.cz/SW-Raid–mdadm/?idfi=2&IDclanku=9

 

V diskusi na odkazu:  http://www.abclinuxu.cz/poradna/linux/show/298096

jsou docela užitečné příkazy jak zjistit jak na tom jsou jednotlivé disky pomocí SMART:

smartctl --test=long /dev/sda
a až test doběhne, tak se podívat přes
smartctl -l /dev/sda

 

Zde je návod česky a snadno:

http://www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-softwarovy-raid-prakticky

Linux : RAID5 : Přidáváme další disk do raidu

Tento návod jsem hledal už hodně dlouho a opravdu ho mohu doporučit komukoliv kdo začíná na debianech či ubuntu a pracuje se softwarovým RAIDem.

sudo fdisk -l

This will output, for each drive you have, something along the lines of:

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000f1f05

There may well be slightly more information available too if you already have some partitions made. From here note the name of the drives you wish to use (for example, /dev/sda). For each drive, create a partition and mark it as a RAID partition.

sudo fdisk /dev/sda

This will open up fdisk, the partition manager. If you already have any partitions on the drive you should first delete them (obviously this will erase any data on them!). To create one partition that is the size of the whole drive:

Command (m for help): n
Command action
	e	extended
	p	primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-182401, default 1): [blank]
Last cylinder or +size or +sizeM or +sizeK (1-182401, default 182401): [blank]

When choosing the first and last cylinder simply hitting return will use the default values (which are probably the values you actually want).

Next we will mark the partition as being part of a RAID array, allowing mdadm to automatically detect it:

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): fd
Changed system type of partition 1 to fd (Linux raid auto)

So far our changes haven’t actually been written to disk, so finally, issue the command to write the changes to disk.

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

 

Growing

One of the advantages of software RAID is the flexibility it gives you, that would normally only be available from high end (expensive) RAID cards. This includes the ability to grow an existing array (only for certain RAID levels), which means if you run out of space you can easily plug in a new drive and keep going.

1. Growing the array

Growing a RAID-5 array with mdadm is a fairly simple (though slow) task. First you will need to prepare the new drive in the same we we prepared the initial drives (step 1, above). To start the actual growing of the array we then add the new drive to the array as a spare:

sudo mdadm --add /dev/md0 /dev/sdd1

Then we grow the array onto this device. Because I had 3 drives before, the new drive obviously makes 4. Make sure to change this to whatever number you now have!

sudo mdadm --grow /dev/md0 --raid-devices=4

As when creating the array, we can follow the progress by checking the file /proc/mdstat.

sudo watch cat /proc/mdstat

Again, I decided to wait for the operation to finish before attempting to grow the filesystem, but you should be able to do it while the array syncs.

Návod je sice na ubuntu 9, ale na debianu squeeze fungoval bez problémů:

http://www.jamierf.co.uk/2009/11/04/software-raid-5-using-mdadm-in-ubuntu-9-10/

10 Důvodů proč virtualizovat

1 )  Pokud máte 4jádrový stroj, pohodlně na něm spustíte třeba 8 virtuálních serverů. Pokud se jedná o nenáročné servery, nemusíte mít 8 fyzických serverů, ale máte 8 virtuálních serverů. Pokud provoz 1 fyzického serveru stojí 2000 korun, který utáhne to stejné, co 8 fyzických serverů, pak ušetříme na měsíčních nákladech 14 000 korun. Má to tedy jasné ekonomické výhody.

2 )  Bezpečnost. Pokud je dobře vyřešena bezpečnost, pak se vyplatí virtualizovat i z hlediska bezpečnostních důvodů. 8 virtuálních serverů se chová jako 8 skutečných počítačů/serverů a pokud bych uživatelům svých virtuálních serverů neřekl, že se jedná o virtuální servery, nepoznali by rozdíl mezi fyzickým a virtuálním serverem. Servery jsou takto odděleny a nikdo nikomu neleze do zelí na jedné mašině. Uživatelé virtuálního serveru 1 (dále jen VPS1) nemohou hrabat uživatelům do serveru VPS2, na který nemají udělen přístup.

3 ) Ekologie. 1 skutečný server, který se chová jako 8 virtuálních serverů, nevygeneruje teplo jako 8 fyzických strojů, ale pouze jako 1 fyzický stroj. Kromě šetření nákladů na elektřinu, šetříme tedy i za hardware, který by generoval teplo, které je nutno chladit.

4 ) Škálování výkonu. Můžete do fyzického serveru za chodu přidávat další ram nebo další procesory? NE! Nemůžete. Můžete však totéž udělat u virtuálních serverů? Ano, můžete! *

* – neumožňují to všechny virtualizační technologie.

5 ) Větší spolehlivost! Kvalitnější virtualizační technologie (například Vmware ESXi a Citrix Xenserver) umí spustit virtualizovaný stroj na 2 fyzických serverech. V okamžiku, kdy vypadne na jednom z nich (shoří fyzický server, selže síťová karta, server se zacyklí atd…), spustí se jeho stejná kopie na druhém fyzickém stroji a výpadek je omezen buď na velice krátkou dobu do 2 minut, nebo je výpadek omezen pouze na dočasnou větší prodlevu v používání služby, která je brzy překonána.

6 ) Snadná migrovatelnost. Virtuální servery lze snadno migrovat z fyzického serveru na fyzický server. Velice snadno a rychle lze tak přenášet uživatelské servery i s daty i nastavením z fyzického stroje na fyzický stroj bez poškození, nebo znehodnocení, či nutnosti opětovné reinstalace operačního systému virtuálního stroje.

7 ) Snadnější zálohování. Pomocí tzv. snapshotů lze vzít virtuální server. Zmrazit ho (zazálohovat) a jeho zmraženou, zazálohovanou kopii použít v případě jeho výpadku v budoucnosti. Během několika minut lze znefunkčnělý systém uvést doprovozu několika příkazy, nebo několika kliknutími. Zachovají se nejen uživatelský data, ale i kompletní nastavení operačního systému. Jako kdybychom zmrazili čas, nebo dali save game a potom load game, ale převeďme si to na virtuální servery.

8 ) Dokonalé na testování aplikací. Pokud bychom chtěli testovat aplikace a nemáme možnosti pro testování na fyzickém stroji, nebo se obáváme zacyklení aplikace a tím pádem i stroje, můžeme aplikaci vyzkoušet na virtuálním serveru, který lze vzdáleně vypínat, restartovat, odstavovat mimo síť. Pro testování naprosto ideální, protože lze za chodu server odpojit od sítě, lze ho vhodit do izolované sítě jen pro virtuální servery mezi sebou.

9 )  Získání většího výkonu nejen v rámci virtuálních serverů. Ne každý server právě využívá 100% výkonu fyzického stroje. To je důvod, proč lze pro virtuální servery buď rezervovat více výkonu, škálovat jejich výkon, nebo jim připojit i několik virtuálních síťových karet naráz, které garantují větší bezpečnost a větší výkon.

10 )  Větší využití současných hardwarových prostředků. Pakliže máme ve firmě 10 fyzických vytěžovaných serverů, není možné, aby se výpočetní výkon těchto 10 fyzických strojů zmenšil na 1 fyzický stroj a 10 virtuálních strojů. Na druhou stranu jsme schopni z 10 serverů, které jsou využity z 50 až 60 % snížit počet fyzických strojů na 6 až 7 fyzických strojů, které budou vytíženy na 70 až 80%. V případě, kdy potřebujeme vyšší výkon, který nám naopak nemůže stačit, lze tento výkon rozšířit vzhledem k rozložení výkonu na více virtuálních strojů, které lze ještě doplnit náhradními virtuálními stroji, zvyšující bezpečnost celého řešení.