Änderungen
Zur Navigation springen
Zur Suche springen
K
Archiv:2011/IT/Dokumentation/OVH-Grundinstallation (Quelltext anzeigen)
Version vom 1. Februar 2019, 12:48 Uhr
, 12:48, 1. Feb. 2019JanRei verschob die Seite IT/Dokumentation/OVH-Grundinstallation nach Archiv:2011/IT/Dokumentation/OVH-Grundinstallation
= Grundinstallation =
== OVH-spezifische Vorbereitungen ==
Zuerst muss der Server über das OVH-Webinterface in den Rescue-Modus gesetzt werden. Dazu meldet man sich beim OVH-Manager an, wählt oben in der Leiste den Server aus, klickt links im Menü auf "Dienstleistungen", und im Hauptteil auf "Netboot". Im folgenden Konfigurationsmenü wählt man den Netboot "rescue-pro", gibt seine E-Mail-Adresse an, unter der man die Zugangsdaten für den Rescue-Modus erhalten will und bestätigt. Anschließend klickt man im Menü links wieder auf "Dienstleistungen" und dann auf "Reboot". Als Grund gibt man "Serverneuinstallation" ein und bestätigt. Sobald der server im Rescue-Modus ist, schickt er an die angegebene E-Mail-Adresse die Zugangsdaten. Das kann bis zu 10 Minuten dauern.
== Partitionierung der Platten ==
Jetzt können wir die Festplatten "ganz normal" partitionieren: Zuerst löschen wir den Anfang der Festplatten, schreiben dann neue Master Boot Records und lesen die Partitionstabelle neu ein. Das ist leider oft genug mit einem Reboot verbunden.
rescue:~# dd if=/dev/zero of=/dev/sda count=512 bs=1M
rescue:~# dd if=/dev/zero of=/dev/sdb count=512 bs=1M
rescue:~# sfdisk --force /dev/sda <<EOF
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 63, size= 514017, Id=fd, bootable
/dev/sda2 : start= 514080, size=1464629985, Id=fd
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
EOF
rescue:~# sfdisk --force /dev/sdb <<EOF
# partition table of /dev/sdb
unit: sectors
/dev/sdb1 : start= 63, size= 514017, Id=fd, bootable
/dev/sdb2 : start= 514080, size=1464629985, Id=fd
/dev/sdb3 : start= 0, size= 0, Id= 0
/dev/sdb4 : start= 0, size= 0, Id= 0
EOF
Hier wird aller Wahrscheinlichkeit nach ein Reboot fällig:
rescue:~# reboot
Dann kurz warten, und wir haben wieder Post vom Server: Neues root-Passwort.
Nun erstellen wir das Software-Raid, die LVM-Partitionen und die Dateisysteme. Auf dem Raid für <code>/boot</code> muss wegen <code>grub</code> die Metadata-Version 0.90 sein, sonst kann der nicht auf <code>/boot</code> installiert werden.
rescue:~# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
rescue:~# mdadm --create /dev/md1 --metadata=1.2 --bitmap=internal --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2
Dannach initialisieren wir die Partition für LVM, indem wir ein LVM-Physical-Volume erstellen, dannach eine Volume-Group (raid) und die ersten Logical Volumes und erstellen die Dateisysteme.
rescue:~# pvcreate /dev/md1
rescue:~# vgcreate raid /dev/md1
rescue:~# lvcreate --size 2G --name blackpearl_root raid
rescue:~# lvcreate --size 1G --name blackpearl_swap raid
rescue:~# mke2fs -j -L blackpearl_root /dev/raid/blackpearl_root
rescue:~# mke2fs -j -L blackpearl_boot /dev/md0
rescue:~# mkswap -L blackpearl_swap /dev/raid/blackpearl_swap
== Eigenes <code>debootstrap</code> notwendig? ==
Früher mussten Anpassungen speziell für das OVH-Rescue-System gemacht werden. Da OVH ein Sarge-Rescue-System verwendete, enthielt das natürlich keinen Lenny-fähigen <code>debootstrap</code> und wir mussten einen neuen herunterladen und installieren. Dummerweise ist das root-Filesystem ein read-only NFS-Share und wir mussten das Paket per Hand nach <code>/tmp</code> installieren, patchen und in den Pfad bringen:
rescue:~# cd /tmp
rescue:/tmp# wget -q http://ftp.fr.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.20_all.deb
rescue:/tmp# ar -x debootstrap_1.0.20_all.deb
rescue:/tmp# tar xzf data.tar.gz
rescue:/tmp# sed -i -e 's#DIR=/usr#DIR=/tmp/usr#' usr/sbin/debootstrap
rescue:/tmp# export PATH=/tmp/usr/sbin:$PATH
== Installieren des Zielsystems ==
Wir hängen nun die vorbereiteten Partitionen in <code>/mnt</code> ein und starten das gepatchte <code>debootstrap</code>:
rescue:~# mount /dev/raid/blackpearl_root /mnt/
rescue:~# mkdir /mnt/boot
rescue:~# mount /dev/md0 /mnt/boot/
rescue:~# debootstrap --arch=amd64 lenny /mnt/ http://ftp.fr.debian.org/debian
Anschliessend hängen wir noch die Dateisysteme <code>/proc</code> und <code>/dev</code> um, damit wir innerhalb des Zielsystems auch auf Geräte und Prozesse zugreifen können. Anschliessend gehen wir in das Zielsystem:
rescue:~# mount -t proc proc /mnt/proc/
rescue:~# mount -o bind /dev/ /mnt/dev/
rescue:~# chroot /mnt/ /bin/bash
== Konfiguration des Zielsystems ==
Ab jetzt sind wir im Zielsystem. Wir werden nun diverse Teile des Systems konfigurieren. Fangen wir mit der Zeitzone an, diese wurde bereits via debootstrap gesetzt, also müssen wir sie umsetzen und das System sich neu konfigurieren lassen:
rescue:/# echo "Europe/Berlin" > /etc/timezone
rescue:/# dpkg-reconfigure -f noninteractive tzdata
Setzen wir gleich auch ein Passwort für <code>root</code>
rescue:/# passwd
Wir müssen auch noch die Partitionen eintragen. Dafür editieren wir die <code>/etc/fstab</code>:
rescue:/# cat > /etc/fstab <<EOF
proc /proc proc defaults 0 0
/dev/raid/blackpearl_root / ext3 errors=remount-ro 0 1
/dev/raid/blackpearl_swap none swap sw 0 0
/dev/md0 /boot ext3 defaults 0 2
EOF
Dann kümmern wir uns um das Datennetz. Wir setzen den Hostnamen und erstellen eine <code>/etc/hosts</code> und <code>/etc/network/interfaces</code>. Hier bitte auf die IP-Adressen, Gateways, Hostnamen etc aufpassen und die eigenen wählen!
rescue:/# echo blackpearl > /etc/hostname
rescue:/# cat > /etc/hosts <<EOF
127.0.0.1 localhost
94.23.220.83 blackpearl.piratenpartei.de blackpearl
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
EOF
rescue:/# cat >> /etc/network/interfaces <<EOF
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 94.23.220.83
netmask 255.255.255.0
network 94.23.220.0
broadcast 94.23.220.255
gateway 94.23.220.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 213.186.33.99
dns-search piratenpartei.de
EOF
Anschließend konfigurieren wir apt. Da die OVH-Kisten in Frankreich stehen, ziehen sie vom französischen Debian-Mirror:
rescue:/# cat > /etc/apt/sources.list <<EOF
deb http://ftp.fr.debian.org/debian lenny main contrib non-free
deb http://security.debian.org lenny/updates main contrib non-free
EOF
== Installation von System-Paketen ==
Als erstes müssen wir <code>aptitude</code> die Paketlisten updaten lassen, anschließend upgraden wir die benötigten Pakete:
rescue:/# aptitude update
rescue:/# aptitude safe-upgrade
Die <code>locales</code> sind noch nicht installiert, und um uns lästige Fragen zu ersparen, legen wir die Konfigurationsdateien bereits im Vorfeld an und installieren dannach:
rescue:/# cat > /etc/locale.gen <<EOF
en_US.UTF-8 UTF-8
de_DE.UTF-8 UTF-8
en_GB.UTF-8 UTF-8
ja_JP.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8
EOF
rescue:/# cat > /etc/default/locale <<EOF
LANG=de_DE.UTF-8
LC_MESSAGES=en_US.UTF-8
EOF
rescue:/# aptitude install locales
Wir müssen noch die LVM-Tools installieren, dass das System nach dem Neustart auf die LVM-Partition zugreifen kann:
rescue:/# aptitude install -y lvm2
Ausserdem muss noch <code>mdadm</code> installiert werden, um auf die Raid-Partitionen zugreifen zu können. Dummerweise will der einen Mailer installieren, und zwar <code>exim</code>. Das ist uns aber zu viel, wir bevorzugen den kleinen <code>nullmailer</code>:
rescue:/# echo blackpearl.piratenpartei.de > /etc/mailname
rescue:/# debconf-set-selections <<EOF
nullmailer shared/mailname string blackpearl.piratenpartei.de
nullmailer nullmailer/relayhost string mail.piratenpartei.de
nullmailer nullmailer/adminaddr string
EOF
rescue:/# aptitude install nullmailer
rescue:/# aptitude install mdadm
Weiter gehts mit dem Boot-Loader, ich bin ein <code>grub</code>-Fan, darum kommt der drauf:
rescue:/# aptitude install -y grub
Achtung! Wenn <code>/dev/md0</code> nicht komplett ist, scheitert folgender Befehl:
rescue:/# grub-install /dev/md0
rescue:/# grub <<EOF
root (hd0,0)
setup (hd0)
setup (hd1)
quit
EOF
Dann installierten wir den Kernel, davor konfigurieren wir aber noch die Kernel-Image-Erstellung:
rescue:/# cat > /etc/kernel-img.conf <<EOF
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no
postinst_hook = update-grub
postrm_hook = update-grub
EOF
rescue:/# aptitude install -y linux-image-2.6-amd64
== Installation der Administrations-Pakete ==
So, jetzt haben wir das neue System bootfertig, aber kommen noch nicht drauf. Dafür brauchen wir noch <code>openssh-server</code>, den wir anschliessend absichern:
rescue:/# aptitude -y install openssh-server
rescue:/# sed -i -e 's/^PermitRootLogin yes$/#&\nPermitRootLogin no/' -e 's/^UsePAM yes$/#&\nUsePAM no/' -e 's/^#PasswordAuthentication yes$/&\nPasswordAuthentication no/' /etc/ssh/sshd_config
Damit die Rechte für den Root-Account sauber getrennt werden, verwenden wir <code>sudo</code>, das wir auch gleich konfigurieren:
rescue:/# aptitude install sudo
rescue:/# sed -i -e 's/^root\tALL=(ALL) ALL$/&\ndyfa\tALL=(ALL) ALL\nsebi\tALL=(ALL) ALL\nchrit\tALL=(ALL) ALL\nunger\tALL=(ALL) ALL\njamasi\tALL=(ALL) ALL\nnhornung\tALL=(ALL) ALL/' /etc/sudoers
Um die Festplatten überwachen zu können, installieren wir noch <code>smartmontools</code>, die wir auch noch aktivieren müssen:
rescue:/# aptitude install -y smartmontools
rescue:/# sed -i -e 's/^#\(start_smartd=yes\)$/\1/' /etc/default/smartmontools
Damit die Uhrzeit auf dem Server synchron zut Atomzeit läuft, installieren wir noch einen NTP-Dämon. Aus Sicherheitsaspekten und benötigten Features benutzen wir <code>openntpd</code>:
rescue:/# aptitude install openntpd
Es gibt noch einige kleine, aber sehr hilfreiche Tools, die wir ebenfalls noch installieren:
* <code>file</code> zeigt den Dateityp an
* <code>htop</code> ist ein komfortableres <code>top</code>
* <code>iftop</code> zeigt die momentane Auslastung der Netzwerk-Schnittstellen an
* <code>less</code> ist ein komfortablerer pager als <code>more</code>
* <code>locate</code> dient zum schnellen Auffinden von Dateinamen
* <code>lshw</code> dient zur Anzeige der installierten Hardware
* <code>lsof</code> zeigt offene Dateien an
* <code>mc</code> ist ein Norton-Commander-Klon, ein Dateimanager
* <code>netcat-openbsd</code> ist mächtiger als <code>netcat-traditional</code>, welches wir gleich deinstallieren
* <code>screen</code> benutzt man, um Sitzungen oder Befehle auszuführen, die auch weiterlaufen, wenn man die Verbindung schließt; man kann sie später wieder aufnehmen
* <code>strace</code> ist ein Tool, das die ausgeführten Systemcalls eines Programms anzeigt
* <code>sysstat</code> dient zur Anzeige von IO-Statistiken
* <code>tcpdump</code> benutzt man, um Netzwerkverkehr anzeigen zu können
rescue:/# aptitude install -y file htop iftop less locate lshw lsof mc netcat-openbsd netcat-traditional- screen strace sysstat tcpdump
== Anlegen der User-Accounts ==
Nun müssen wir auch User-Accounts anlegen, sonst können wir uns nicht mehr einloggen, hier mal für 2 von der Leitung (auch gut für neuinstallationen):
<pre>
rescue:/# useradd -c "Sebastian Mohr" -m -s /bin/bash sebi
rescue:/# passwd sebi
rescue:/# su - sebi
sebi@rescue:~$ mkdir .ssh
sebi@rescue:~$ cat > .ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAjtzKxPXNIlHzao8WeojHHCFvixMhDEFgt/4HlC+5DO+Vzned23Ymg6vKLKot+VtCR5qbshHbmvfiqFkj6qahPtZdzsMg7Git2lMd88MgvzDI8ao9f4o6NrPrP7nOTR/mk8zKzRPF79O/u2Pz2bRLiuaIn8fOCi3mqsnmUqA3zene9Hn/stURTHin+elcewQt2Q66YmhersY2nulXL6PVQsW1MhstVy02lMvbbaxdHmeG0FJY/e+ibZt1CR2l5OOZ6ZmbpfN/14Do5ebqB0lOoOSwvnSgnB78pg6cFDa/k8ugUnCMndbprBgxvGDHSBQf7dmCm4Pi2XnH6dltBnZwraewG3RsxmndqA2dGtSG7mLn9TjxjJ9W4LMOndtts9HzMFDXT1CY/Izv4PsaC8s3rAsvR6bT8lSyRDVdYkwmD/YmoX8dnpiNphmdJVO/4WiHWkL0j+BYVxGrd3dZ7yNhUSgftdvuVF99zWWoO1atZlN7xMMP2sI4Dz5NJvVLCy4nmKSYoDiKZ0s06fKzFMAoAePaBNawSNSei5I2eih/VyLq+qUvEbYrAtPcvApPaOT22MjP24LNf1+WWhlB8Zii+8cWNsW+58Ze2+Ku9/RqlmGltC9a7n2zVevkmCV4JJ8TBBW66IKuInixW6qs9sFYXiBWGi3Edwc1SYpz56Rc6U9h0pZiQJze7H4RH/PqowNifjPMEhO8Ci7xB59zzx1jQECo6UHs+2PDnPWnP+V8oiusrr9wu+ONcy6aStD sebi@sinkpad
EOF
sebi@rescue:~$ exit
rescue:/# useradd -c "Jan Simons" -m -s /bin/bash jamasi
rescue:/# passwd jamasi
rescue:/# su - jamasi
jamasi@rescue:~$ mkdir .ssh
jamasi@rescue:~$ cat > .ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAx2olFDwlPhh1plmUn24IZBj86gq2SxiqKgkmHEFy3qLKr5ZxiwqbZgDXba7ThGmcTmTEPGg/MhHl2pbbKaQrPGCrKDbtdJA2+8A/l4MDWln92KANqedR9n2L1ubEzFf4LUxBRIYMcu9L8PgqtJKIXq8bVD/i99tyJlE9Tz1y6LU= jan@blood
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuQQc/FK9lI1ZGecCkvf8PPl4Y/N+NW2GB/N8XSSf+1FQmNqqbGN5XhBOmzBWnTmEIjIOQVVsz6NH/ItT90Xxa0Tgu5BbLUc8WKqxIp5VjQI4/WYhJ3t+xopMDIdGqH5mMWUQpcGmUU/8/wgemMILahbQJXIeE9dP+BLFxTZ0UCFYNiuTDWLQxYeg46Kyg6AxVdNyOo6xIZG75vFuAVwoZRw3Z1UFEfWb+i2vwels2/CWAhGSJ8iWASCjlJTJCN4rPJUPDuHUC9s8w27064xyD/IeHtRlPRh3NzDcAhlACRd6HTjyy75iqXLEeRf5CFBiGSmqXQke6RdWnRoyfZHDPw== jan@subito
EOF
jamasi@rescue:~$ exit
</pre>
== Aufräumen ==
Am Schluss räumen wir noch alles auf:
rescue:/# exit
rescue:~# killall ntpd
rescue:~# killall nullmailer-send
rescue:~# killall mdadm
rescue:~# umount /mnt/boot/
rescue:~# umount /mnt/dev/
rescue:~# umount /mnt/proc/
rescue:~# umount /mnt/
Und schalten im OVH-Manager wieder auf Festplatten-Boot, dannach das letzte Kommando:
rescue:~# reboot
Und dann kommt die neue Kiste hoffentlich bald wieder hoch ;-)
= Installation der Dual-Server-Lösung =
Für einen professionellen Betrieb wollen wir mehrere Netze einrichten:
* Externes Netz
** Öffentliche IP-Adressen, Dienste für Benutzer
* Internes Netz
** Interner Datenaustausch, z.B. für DB-Abfragen, Mail zwischen den Kisten, usw.
** Aus Performanzgründen sollte geroutet und nicht gebriged werden
* Storage-Netz
** Schaufelt die benötigten Daten zu den Kisten; hier kümmert es sich um die Synchronisation der VM-Platten zwischen den Kisten mit DRBD.
** Hier sollte jeder DRBD-Link einzeln verschlüsselt sein.
* Admin-Netz
** Administration und Installation der Rechner. Hier müssen DHCP-Anfragen verschickt werden und die VMs sollen unabhängig von dem eingesetzten Netz direkt erreichbar sein können.
** Hier muss ein gebridgdes Netz vorliegen.
Weiterhin haben wir uns für die Virtualisierungslösung KVM entschieden. Im Test von 3 verschiedenen Versionen hat sich kvm-72 bewährt.
Die Performanztests sind hier zu finden: [[IT/Dokumentation/OVH-Grundinstallation/Performanztests]]
== <code>bridge-utils</code> oder Verbindungen zwischen den VMs ==
Damit unsere virtuellen Maschinen sinnvoll miteinander reden können, benötigen wir eine Bridge für das Admin-Netz, auf der sich dann die entsprechenden tap-Devices der Netzwerkkarten der KVM-Instanzen tummeln. Dadurch können sie bereits DHCP-Anfragen beantworten, was für den Installations-Server wichtig wird.
Wir installieren dafür <code>bridge-utils</code> und tragen dannach in der <code>/etc/network/interfaces</code> zwei zusätzliche Bridges ein und aktivieren sie. Wichtig dabei ist, das forward delay herabzusetzen, sonst können die KVM-Maschinen nicht übers Netz booten:
sebi@blackpearl:~$ sudo aptitude install bridge-utils
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/network/interfaces'
# The administration network
auto bradmin
iface bradmin inet manual
bridge_ports none
bridge_fd 0
bridge_maxwait 0
bridge_stp on
# The internal data network
auto brdata
iface brdata inet manual
bridge_ports none
bridge_fd 0
bridge_maxwait 0
bridge_stp on
EOF
sebi@blackpearl:~$ sudo ifup bradmin
sebi@blackpearl:~$ sudo ifup brdata
Nun sollten wir noch netfilter (Kernel-Firewall) aus Sicherheits- und Effizienzgründen auf den Bridges abschalten und die Änderungen aktivieren:
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat > /etc/sysctl.d/bridge-netfilter-off.conf'
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF
sebi@blackpearl:~$ sudo /etc/init.d/procps restart
== <code>openvpn</code> oder Verbindungen zwischen den Servern ==
Damit sie auch mit den Maschinen auf dem anderen Host im selben Subnetz sind und nach einer Migration immer noch unter der selben IP-Adresse zu erreichen sind, müssen wir diese Brücken miteinander verbinden. Dazu benutzen wir OpenVPN im p2p-Modus (da nur zwei Maschinen), um eine sichere Verbindung zum anderen Server aufbauen zu können.
Also installieren wir erstmal openvpn:
sebi@blackpearl:~$ sudo aptitude -y install openvpn
Dannach erstellen wir ein kleines Hilfs-Script zum Hinzufügen der Interfaces zu den jeweiligen Brücken, die Konfigurationsdateien und die gemeinsamen Schlüssel:
sebi@blackpearl:~$ cat <<'EOF' | sudo sh -c 'cat >> /etc/openvpn/brctl-wrapper.sh'
#!/bin/sh
# $1: "addif", "delif"
# $2: bridge-name
# $3: interface-name
brctl $1 $2 $3
ip link set up $3
EOF
sebi@blackpearl:~$ sudo chmod 755 /etc/openvpn/brctl-wrapper.sh
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/openvpn/bounty-blackpearl-admin.conf'
local 94.23.220.83
remote 94.23.198.106
port 14139
dev tap
persist-tun
persist-key
up '/etc/openvpn/brctl-wrapper.sh addif bradmin '
script-security 2
user nobody
group nogroup
comp-lzo
secret bounty-blackpearl-admin_static.key
EOF
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/openvpn/bounty-blackpearl-data.conf'
local 94.23.220.83
remote 94.23.198.106
port 41201
dev tap
persist-tun
persist-key
up '/etc/openvpn/brctl-wrapper.sh addif brdata '
script-security 2
user nobody
group nogroup
comp-lzo
secret bounty-blackpearl-data_static.key
EOF
sebi@blackpearl:~$ sudo openvpn --genkey --secret /etc/openvpn/bounty-blackpearl-admin_static.key
sebi@blackpearl:~$ sudo openvpn --genkey --secret /etc/openvpn/bounty-blackpearl-data_static.key
Die <code>.key</code>-Dateien müssen nun verschlüsselt auf den 2. Host übertragen werden. Für die Konfigurationsdateien auf dem 2. Host müssen nur die Parameter von "local" und "remote" vertauscht werden.
== <code>drbd-modules</code> oder Daten-Speicher-Syncronisation ==
Als erstes einmal installieren wir die DRBD-Module und die DRBD-Utilities
sebi@blackpearl:~$ sudo aptitude -y install drbd8-modules-2.6-amd64 drbd8-utils
Dann schreiben wir noch den gemeinsam genutzten Teil der Konfigurationsdatei für DRBD.
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat > /etc/drbd.conf'
global {
usage-count no;
}
common {
syncer { rate 80M; }
startup {
wfc-timeout 120;
degr-wfc-timeout 60;
}
}
EOF
Zum Schluss starten wir noch DRBD über die init-Scripte, damit die Module geladen werden können.
sebi@blackpearl:~$ sudo /etc/init.d/drbd start
Beim nächsten Systemstart werden die automatisch ausgeführt.
== <code>kvm</code> oder Virtuelle Maschinen ==
Wir installieren kvm und libvirt ohne recommends, das spart uns einige Pakete, die das System sehr aufblähen würden:
sebi@blackpearl:~$ sudo aptitude -y --without-recommends install kvm libvirt-bin
Anschließend fügen wir die Nutzer der libvirt-Gruppe hinzu, so dass sie mit dem <code>virt-manager</code> arbeiten können.
sebi@blackpearl:~$ sudo usermod -G libvirt dyfa
sebi@blackpearl:~$ sudo usermod -G libvirt sebi
sebi@blackpearl:~$ sudo usermod -G libvirt chrit
sebi@blackpearl:~$ sudo usermod -G libvirt unger
sebi@blackpearl:~$ sudo usermod -G libvirt jamasi
sebi@blackpearl:~$ sudo usermod -G libvirt nhornung
Wir erweitern KVM um die Möglichkeit des PXE-Netz-Boots, einmal per Boot-ROM, einmal per Boot-CD.
sebi@blackpearl:~$ sudo wget http://rom-o-matic.net/gpxe/gpxe-0.9.9/contrib/rom-o-matic/build.php --post-data 'version=0.9.9&ofmt=ROM+binary+%28flashable%29+image+%28.rom%29&nic=virtio-net&pci_vendor_code=1af4&pci_device_code=1000&A=Get+Image' -O /usr/share/kvm/pxe-virtio.bin
sebi@blackpearl:~$ sudo wget http://rom-o-matic.net/gpxe/gpxe-0.9.9/contrib/rom-o-matic/build.php --post-data 'version=0.9.9&ofmt=ISO+bootable+image+%28.iso%29&nic=virtio-net&pci_vendor_code=1af4&pci_device_code=1000&A=Get+Image' -O /root/gpxe-0.9.9-virtio-net.iso
=== KVM-Standard-Host mit Anmerkungen===
XML Aufspannen.
<domain type='kvm'>
Domain benennen.
<name>changeme</name>
Wird generiert.
<uuid></uuid>
Benutzter Speicher; Ballooning (ändern von <code>currentMemory</code>) führte zu Abstürzen.
<memory>524288</memory>
<currentMemory>524288</currentMemory>
Anzahl der CPUs
<vcpu>1</vcpu>
Wir fahren den Gast mit 64-Bit (<code>x86_64</code>) / 32-Bit (<code>i686</code>) und booten von Platte (<code>hd</code>) / CD-ROM (<code>cdrom</code>) / PXE aus dem Netzwerk (<code>network</code>).
<os>
<type arch='x86_64' machine='pc'>hvm</type>
<boot dev='hd'/>
</os>
Wir können ACPI und APIC und werden das auch benutzen!
<features>
<acpi/>
<apic/>
</features>
Unser Betriebssystem kann mit mehreren Zeitzonen gut umgehen.
<clock offset='utc'/>
Verhalten nach Beendigung des KVM-Prozesses
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
Wir verwenden <code>/usr/bin/kvm</code> fürs virtualisieren.
<devices>
<emulator>/usr/bin/kvm</emulator>
Ein CD-Laufwerk am IDE-Bus. Können wir nach funktionierendem Netzboot weglassen.
<disk type='file' device='cdrom'>
<source file='/path/to/image.iso'/>
<target dev='hda' bus='ide'/>
<readonly/>
</disk>
Zwei Platten, am flotten virtio-Bus. <code>changeme_disk</code> ist die System-Platte, <code>changeme_srv</code> ist das Dateisystem mit den Daten, welches unter <code>/srv</code> im Zielsystem gemountet wird. Siehe auch [[IT/Dokumentation/Namenskonventionen]]
<disk type='block' device='disk'>
<source dev='/dev/raid/changeme_disk'/>
<target dev='vda' bus='virtio'/>
</disk>
<disk type='block' device='disk'>
<source dev='/dev/raid/changeme_srv'/>
<target dev='vdb' bus='virtio'/>
</disk>
Die Netzwerk-Interfaces, wieder virtio. Netzwerk-Boot ist nur von der ersten definierten Karte möglich. Boot-ROM unter rom-o-matic.net besorgen, PCI-ID: 1af4:1000. 'bridge'-Interfaces werden gleich auf eine Brücke gelegt, 'ethernet'-Interfaces bleiben im Host sichtbar und können direkt geroutet werden. Maximale Länge des device-Namens beachten!
<interface type='bridge'>
<source bridge='bradmin'/>
<target dev='changeme_adm'/>
<model type='virtio'/>
</interface>
<interface type='bridge'>
<source bridge='brdata'/>
<target dev='changeme_int'/>
<model type='virtio'/>
</interface>
<interface type='ethernet'>
<script path='no'/>
<target dev='changeme_ext'/>
<model type='virtio'/>
</interface>
Grafische Ein- und Ausgabe. <code>type='tablet'</code> nimmt er nicht an. Nur Konsole (<code><console/></code>) nimmt er auch nicht an.
<input type='mouse' bus='ps2'/>
<graphics type='vnc' autoport='yes' keymap='de'/>
</devices>
</domain>
Bitte [[IT/Dokumentation/OVH-Grundinstallation/KVM-Erstellung]] beachten!
[[Kategorie:IT-Infrastruktur]]
[[Kategorie:Dokumentation]]
== OVH-spezifische Vorbereitungen ==
Zuerst muss der Server über das OVH-Webinterface in den Rescue-Modus gesetzt werden. Dazu meldet man sich beim OVH-Manager an, wählt oben in der Leiste den Server aus, klickt links im Menü auf "Dienstleistungen", und im Hauptteil auf "Netboot". Im folgenden Konfigurationsmenü wählt man den Netboot "rescue-pro", gibt seine E-Mail-Adresse an, unter der man die Zugangsdaten für den Rescue-Modus erhalten will und bestätigt. Anschließend klickt man im Menü links wieder auf "Dienstleistungen" und dann auf "Reboot". Als Grund gibt man "Serverneuinstallation" ein und bestätigt. Sobald der server im Rescue-Modus ist, schickt er an die angegebene E-Mail-Adresse die Zugangsdaten. Das kann bis zu 10 Minuten dauern.
== Partitionierung der Platten ==
Jetzt können wir die Festplatten "ganz normal" partitionieren: Zuerst löschen wir den Anfang der Festplatten, schreiben dann neue Master Boot Records und lesen die Partitionstabelle neu ein. Das ist leider oft genug mit einem Reboot verbunden.
rescue:~# dd if=/dev/zero of=/dev/sda count=512 bs=1M
rescue:~# dd if=/dev/zero of=/dev/sdb count=512 bs=1M
rescue:~# sfdisk --force /dev/sda <<EOF
# partition table of /dev/sda
unit: sectors
/dev/sda1 : start= 63, size= 514017, Id=fd, bootable
/dev/sda2 : start= 514080, size=1464629985, Id=fd
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
EOF
rescue:~# sfdisk --force /dev/sdb <<EOF
# partition table of /dev/sdb
unit: sectors
/dev/sdb1 : start= 63, size= 514017, Id=fd, bootable
/dev/sdb2 : start= 514080, size=1464629985, Id=fd
/dev/sdb3 : start= 0, size= 0, Id= 0
/dev/sdb4 : start= 0, size= 0, Id= 0
EOF
Hier wird aller Wahrscheinlichkeit nach ein Reboot fällig:
rescue:~# reboot
Dann kurz warten, und wir haben wieder Post vom Server: Neues root-Passwort.
Nun erstellen wir das Software-Raid, die LVM-Partitionen und die Dateisysteme. Auf dem Raid für <code>/boot</code> muss wegen <code>grub</code> die Metadata-Version 0.90 sein, sonst kann der nicht auf <code>/boot</code> installiert werden.
rescue:~# mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
rescue:~# mdadm --create /dev/md1 --metadata=1.2 --bitmap=internal --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2
Dannach initialisieren wir die Partition für LVM, indem wir ein LVM-Physical-Volume erstellen, dannach eine Volume-Group (raid) und die ersten Logical Volumes und erstellen die Dateisysteme.
rescue:~# pvcreate /dev/md1
rescue:~# vgcreate raid /dev/md1
rescue:~# lvcreate --size 2G --name blackpearl_root raid
rescue:~# lvcreate --size 1G --name blackpearl_swap raid
rescue:~# mke2fs -j -L blackpearl_root /dev/raid/blackpearl_root
rescue:~# mke2fs -j -L blackpearl_boot /dev/md0
rescue:~# mkswap -L blackpearl_swap /dev/raid/blackpearl_swap
== Eigenes <code>debootstrap</code> notwendig? ==
Früher mussten Anpassungen speziell für das OVH-Rescue-System gemacht werden. Da OVH ein Sarge-Rescue-System verwendete, enthielt das natürlich keinen Lenny-fähigen <code>debootstrap</code> und wir mussten einen neuen herunterladen und installieren. Dummerweise ist das root-Filesystem ein read-only NFS-Share und wir mussten das Paket per Hand nach <code>/tmp</code> installieren, patchen und in den Pfad bringen:
rescue:~# cd /tmp
rescue:/tmp# wget -q http://ftp.fr.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.20_all.deb
rescue:/tmp# ar -x debootstrap_1.0.20_all.deb
rescue:/tmp# tar xzf data.tar.gz
rescue:/tmp# sed -i -e 's#DIR=/usr#DIR=/tmp/usr#' usr/sbin/debootstrap
rescue:/tmp# export PATH=/tmp/usr/sbin:$PATH
== Installieren des Zielsystems ==
Wir hängen nun die vorbereiteten Partitionen in <code>/mnt</code> ein und starten das gepatchte <code>debootstrap</code>:
rescue:~# mount /dev/raid/blackpearl_root /mnt/
rescue:~# mkdir /mnt/boot
rescue:~# mount /dev/md0 /mnt/boot/
rescue:~# debootstrap --arch=amd64 lenny /mnt/ http://ftp.fr.debian.org/debian
Anschliessend hängen wir noch die Dateisysteme <code>/proc</code> und <code>/dev</code> um, damit wir innerhalb des Zielsystems auch auf Geräte und Prozesse zugreifen können. Anschliessend gehen wir in das Zielsystem:
rescue:~# mount -t proc proc /mnt/proc/
rescue:~# mount -o bind /dev/ /mnt/dev/
rescue:~# chroot /mnt/ /bin/bash
== Konfiguration des Zielsystems ==
Ab jetzt sind wir im Zielsystem. Wir werden nun diverse Teile des Systems konfigurieren. Fangen wir mit der Zeitzone an, diese wurde bereits via debootstrap gesetzt, also müssen wir sie umsetzen und das System sich neu konfigurieren lassen:
rescue:/# echo "Europe/Berlin" > /etc/timezone
rescue:/# dpkg-reconfigure -f noninteractive tzdata
Setzen wir gleich auch ein Passwort für <code>root</code>
rescue:/# passwd
Wir müssen auch noch die Partitionen eintragen. Dafür editieren wir die <code>/etc/fstab</code>:
rescue:/# cat > /etc/fstab <<EOF
proc /proc proc defaults 0 0
/dev/raid/blackpearl_root / ext3 errors=remount-ro 0 1
/dev/raid/blackpearl_swap none swap sw 0 0
/dev/md0 /boot ext3 defaults 0 2
EOF
Dann kümmern wir uns um das Datennetz. Wir setzen den Hostnamen und erstellen eine <code>/etc/hosts</code> und <code>/etc/network/interfaces</code>. Hier bitte auf die IP-Adressen, Gateways, Hostnamen etc aufpassen und die eigenen wählen!
rescue:/# echo blackpearl > /etc/hostname
rescue:/# cat > /etc/hosts <<EOF
127.0.0.1 localhost
94.23.220.83 blackpearl.piratenpartei.de blackpearl
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
EOF
rescue:/# cat >> /etc/network/interfaces <<EOF
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 94.23.220.83
netmask 255.255.255.0
network 94.23.220.0
broadcast 94.23.220.255
gateway 94.23.220.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 213.186.33.99
dns-search piratenpartei.de
EOF
Anschließend konfigurieren wir apt. Da die OVH-Kisten in Frankreich stehen, ziehen sie vom französischen Debian-Mirror:
rescue:/# cat > /etc/apt/sources.list <<EOF
deb http://ftp.fr.debian.org/debian lenny main contrib non-free
deb http://security.debian.org lenny/updates main contrib non-free
EOF
== Installation von System-Paketen ==
Als erstes müssen wir <code>aptitude</code> die Paketlisten updaten lassen, anschließend upgraden wir die benötigten Pakete:
rescue:/# aptitude update
rescue:/# aptitude safe-upgrade
Die <code>locales</code> sind noch nicht installiert, und um uns lästige Fragen zu ersparen, legen wir die Konfigurationsdateien bereits im Vorfeld an und installieren dannach:
rescue:/# cat > /etc/locale.gen <<EOF
en_US.UTF-8 UTF-8
de_DE.UTF-8 UTF-8
en_GB.UTF-8 UTF-8
ja_JP.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8
EOF
rescue:/# cat > /etc/default/locale <<EOF
LANG=de_DE.UTF-8
LC_MESSAGES=en_US.UTF-8
EOF
rescue:/# aptitude install locales
Wir müssen noch die LVM-Tools installieren, dass das System nach dem Neustart auf die LVM-Partition zugreifen kann:
rescue:/# aptitude install -y lvm2
Ausserdem muss noch <code>mdadm</code> installiert werden, um auf die Raid-Partitionen zugreifen zu können. Dummerweise will der einen Mailer installieren, und zwar <code>exim</code>. Das ist uns aber zu viel, wir bevorzugen den kleinen <code>nullmailer</code>:
rescue:/# echo blackpearl.piratenpartei.de > /etc/mailname
rescue:/# debconf-set-selections <<EOF
nullmailer shared/mailname string blackpearl.piratenpartei.de
nullmailer nullmailer/relayhost string mail.piratenpartei.de
nullmailer nullmailer/adminaddr string
EOF
rescue:/# aptitude install nullmailer
rescue:/# aptitude install mdadm
Weiter gehts mit dem Boot-Loader, ich bin ein <code>grub</code>-Fan, darum kommt der drauf:
rescue:/# aptitude install -y grub
Achtung! Wenn <code>/dev/md0</code> nicht komplett ist, scheitert folgender Befehl:
rescue:/# grub-install /dev/md0
rescue:/# grub <<EOF
root (hd0,0)
setup (hd0)
setup (hd1)
quit
EOF
Dann installierten wir den Kernel, davor konfigurieren wir aber noch die Kernel-Image-Erstellung:
rescue:/# cat > /etc/kernel-img.conf <<EOF
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = no
postinst_hook = update-grub
postrm_hook = update-grub
EOF
rescue:/# aptitude install -y linux-image-2.6-amd64
== Installation der Administrations-Pakete ==
So, jetzt haben wir das neue System bootfertig, aber kommen noch nicht drauf. Dafür brauchen wir noch <code>openssh-server</code>, den wir anschliessend absichern:
rescue:/# aptitude -y install openssh-server
rescue:/# sed -i -e 's/^PermitRootLogin yes$/#&\nPermitRootLogin no/' -e 's/^UsePAM yes$/#&\nUsePAM no/' -e 's/^#PasswordAuthentication yes$/&\nPasswordAuthentication no/' /etc/ssh/sshd_config
Damit die Rechte für den Root-Account sauber getrennt werden, verwenden wir <code>sudo</code>, das wir auch gleich konfigurieren:
rescue:/# aptitude install sudo
rescue:/# sed -i -e 's/^root\tALL=(ALL) ALL$/&\ndyfa\tALL=(ALL) ALL\nsebi\tALL=(ALL) ALL\nchrit\tALL=(ALL) ALL\nunger\tALL=(ALL) ALL\njamasi\tALL=(ALL) ALL\nnhornung\tALL=(ALL) ALL/' /etc/sudoers
Um die Festplatten überwachen zu können, installieren wir noch <code>smartmontools</code>, die wir auch noch aktivieren müssen:
rescue:/# aptitude install -y smartmontools
rescue:/# sed -i -e 's/^#\(start_smartd=yes\)$/\1/' /etc/default/smartmontools
Damit die Uhrzeit auf dem Server synchron zut Atomzeit läuft, installieren wir noch einen NTP-Dämon. Aus Sicherheitsaspekten und benötigten Features benutzen wir <code>openntpd</code>:
rescue:/# aptitude install openntpd
Es gibt noch einige kleine, aber sehr hilfreiche Tools, die wir ebenfalls noch installieren:
* <code>file</code> zeigt den Dateityp an
* <code>htop</code> ist ein komfortableres <code>top</code>
* <code>iftop</code> zeigt die momentane Auslastung der Netzwerk-Schnittstellen an
* <code>less</code> ist ein komfortablerer pager als <code>more</code>
* <code>locate</code> dient zum schnellen Auffinden von Dateinamen
* <code>lshw</code> dient zur Anzeige der installierten Hardware
* <code>lsof</code> zeigt offene Dateien an
* <code>mc</code> ist ein Norton-Commander-Klon, ein Dateimanager
* <code>netcat-openbsd</code> ist mächtiger als <code>netcat-traditional</code>, welches wir gleich deinstallieren
* <code>screen</code> benutzt man, um Sitzungen oder Befehle auszuführen, die auch weiterlaufen, wenn man die Verbindung schließt; man kann sie später wieder aufnehmen
* <code>strace</code> ist ein Tool, das die ausgeführten Systemcalls eines Programms anzeigt
* <code>sysstat</code> dient zur Anzeige von IO-Statistiken
* <code>tcpdump</code> benutzt man, um Netzwerkverkehr anzeigen zu können
rescue:/# aptitude install -y file htop iftop less locate lshw lsof mc netcat-openbsd netcat-traditional- screen strace sysstat tcpdump
== Anlegen der User-Accounts ==
Nun müssen wir auch User-Accounts anlegen, sonst können wir uns nicht mehr einloggen, hier mal für 2 von der Leitung (auch gut für neuinstallationen):
<pre>
rescue:/# useradd -c "Sebastian Mohr" -m -s /bin/bash sebi
rescue:/# passwd sebi
rescue:/# su - sebi
sebi@rescue:~$ mkdir .ssh
sebi@rescue:~$ cat > .ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAjtzKxPXNIlHzao8WeojHHCFvixMhDEFgt/4HlC+5DO+Vzned23Ymg6vKLKot+VtCR5qbshHbmvfiqFkj6qahPtZdzsMg7Git2lMd88MgvzDI8ao9f4o6NrPrP7nOTR/mk8zKzRPF79O/u2Pz2bRLiuaIn8fOCi3mqsnmUqA3zene9Hn/stURTHin+elcewQt2Q66YmhersY2nulXL6PVQsW1MhstVy02lMvbbaxdHmeG0FJY/e+ibZt1CR2l5OOZ6ZmbpfN/14Do5ebqB0lOoOSwvnSgnB78pg6cFDa/k8ugUnCMndbprBgxvGDHSBQf7dmCm4Pi2XnH6dltBnZwraewG3RsxmndqA2dGtSG7mLn9TjxjJ9W4LMOndtts9HzMFDXT1CY/Izv4PsaC8s3rAsvR6bT8lSyRDVdYkwmD/YmoX8dnpiNphmdJVO/4WiHWkL0j+BYVxGrd3dZ7yNhUSgftdvuVF99zWWoO1atZlN7xMMP2sI4Dz5NJvVLCy4nmKSYoDiKZ0s06fKzFMAoAePaBNawSNSei5I2eih/VyLq+qUvEbYrAtPcvApPaOT22MjP24LNf1+WWhlB8Zii+8cWNsW+58Ze2+Ku9/RqlmGltC9a7n2zVevkmCV4JJ8TBBW66IKuInixW6qs9sFYXiBWGi3Edwc1SYpz56Rc6U9h0pZiQJze7H4RH/PqowNifjPMEhO8Ci7xB59zzx1jQECo6UHs+2PDnPWnP+V8oiusrr9wu+ONcy6aStD sebi@sinkpad
EOF
sebi@rescue:~$ exit
rescue:/# useradd -c "Jan Simons" -m -s /bin/bash jamasi
rescue:/# passwd jamasi
rescue:/# su - jamasi
jamasi@rescue:~$ mkdir .ssh
jamasi@rescue:~$ cat > .ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAx2olFDwlPhh1plmUn24IZBj86gq2SxiqKgkmHEFy3qLKr5ZxiwqbZgDXba7ThGmcTmTEPGg/MhHl2pbbKaQrPGCrKDbtdJA2+8A/l4MDWln92KANqedR9n2L1ubEzFf4LUxBRIYMcu9L8PgqtJKIXq8bVD/i99tyJlE9Tz1y6LU= jan@blood
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuQQc/FK9lI1ZGecCkvf8PPl4Y/N+NW2GB/N8XSSf+1FQmNqqbGN5XhBOmzBWnTmEIjIOQVVsz6NH/ItT90Xxa0Tgu5BbLUc8WKqxIp5VjQI4/WYhJ3t+xopMDIdGqH5mMWUQpcGmUU/8/wgemMILahbQJXIeE9dP+BLFxTZ0UCFYNiuTDWLQxYeg46Kyg6AxVdNyOo6xIZG75vFuAVwoZRw3Z1UFEfWb+i2vwels2/CWAhGSJ8iWASCjlJTJCN4rPJUPDuHUC9s8w27064xyD/IeHtRlPRh3NzDcAhlACRd6HTjyy75iqXLEeRf5CFBiGSmqXQke6RdWnRoyfZHDPw== jan@subito
EOF
jamasi@rescue:~$ exit
</pre>
== Aufräumen ==
Am Schluss räumen wir noch alles auf:
rescue:/# exit
rescue:~# killall ntpd
rescue:~# killall nullmailer-send
rescue:~# killall mdadm
rescue:~# umount /mnt/boot/
rescue:~# umount /mnt/dev/
rescue:~# umount /mnt/proc/
rescue:~# umount /mnt/
Und schalten im OVH-Manager wieder auf Festplatten-Boot, dannach das letzte Kommando:
rescue:~# reboot
Und dann kommt die neue Kiste hoffentlich bald wieder hoch ;-)
= Installation der Dual-Server-Lösung =
Für einen professionellen Betrieb wollen wir mehrere Netze einrichten:
* Externes Netz
** Öffentliche IP-Adressen, Dienste für Benutzer
* Internes Netz
** Interner Datenaustausch, z.B. für DB-Abfragen, Mail zwischen den Kisten, usw.
** Aus Performanzgründen sollte geroutet und nicht gebriged werden
* Storage-Netz
** Schaufelt die benötigten Daten zu den Kisten; hier kümmert es sich um die Synchronisation der VM-Platten zwischen den Kisten mit DRBD.
** Hier sollte jeder DRBD-Link einzeln verschlüsselt sein.
* Admin-Netz
** Administration und Installation der Rechner. Hier müssen DHCP-Anfragen verschickt werden und die VMs sollen unabhängig von dem eingesetzten Netz direkt erreichbar sein können.
** Hier muss ein gebridgdes Netz vorliegen.
Weiterhin haben wir uns für die Virtualisierungslösung KVM entschieden. Im Test von 3 verschiedenen Versionen hat sich kvm-72 bewährt.
Die Performanztests sind hier zu finden: [[IT/Dokumentation/OVH-Grundinstallation/Performanztests]]
== <code>bridge-utils</code> oder Verbindungen zwischen den VMs ==
Damit unsere virtuellen Maschinen sinnvoll miteinander reden können, benötigen wir eine Bridge für das Admin-Netz, auf der sich dann die entsprechenden tap-Devices der Netzwerkkarten der KVM-Instanzen tummeln. Dadurch können sie bereits DHCP-Anfragen beantworten, was für den Installations-Server wichtig wird.
Wir installieren dafür <code>bridge-utils</code> und tragen dannach in der <code>/etc/network/interfaces</code> zwei zusätzliche Bridges ein und aktivieren sie. Wichtig dabei ist, das forward delay herabzusetzen, sonst können die KVM-Maschinen nicht übers Netz booten:
sebi@blackpearl:~$ sudo aptitude install bridge-utils
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/network/interfaces'
# The administration network
auto bradmin
iface bradmin inet manual
bridge_ports none
bridge_fd 0
bridge_maxwait 0
bridge_stp on
# The internal data network
auto brdata
iface brdata inet manual
bridge_ports none
bridge_fd 0
bridge_maxwait 0
bridge_stp on
EOF
sebi@blackpearl:~$ sudo ifup bradmin
sebi@blackpearl:~$ sudo ifup brdata
Nun sollten wir noch netfilter (Kernel-Firewall) aus Sicherheits- und Effizienzgründen auf den Bridges abschalten und die Änderungen aktivieren:
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat > /etc/sysctl.d/bridge-netfilter-off.conf'
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF
sebi@blackpearl:~$ sudo /etc/init.d/procps restart
== <code>openvpn</code> oder Verbindungen zwischen den Servern ==
Damit sie auch mit den Maschinen auf dem anderen Host im selben Subnetz sind und nach einer Migration immer noch unter der selben IP-Adresse zu erreichen sind, müssen wir diese Brücken miteinander verbinden. Dazu benutzen wir OpenVPN im p2p-Modus (da nur zwei Maschinen), um eine sichere Verbindung zum anderen Server aufbauen zu können.
Also installieren wir erstmal openvpn:
sebi@blackpearl:~$ sudo aptitude -y install openvpn
Dannach erstellen wir ein kleines Hilfs-Script zum Hinzufügen der Interfaces zu den jeweiligen Brücken, die Konfigurationsdateien und die gemeinsamen Schlüssel:
sebi@blackpearl:~$ cat <<'EOF' | sudo sh -c 'cat >> /etc/openvpn/brctl-wrapper.sh'
#!/bin/sh
# $1: "addif", "delif"
# $2: bridge-name
# $3: interface-name
brctl $1 $2 $3
ip link set up $3
EOF
sebi@blackpearl:~$ sudo chmod 755 /etc/openvpn/brctl-wrapper.sh
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/openvpn/bounty-blackpearl-admin.conf'
local 94.23.220.83
remote 94.23.198.106
port 14139
dev tap
persist-tun
persist-key
up '/etc/openvpn/brctl-wrapper.sh addif bradmin '
script-security 2
user nobody
group nogroup
comp-lzo
secret bounty-blackpearl-admin_static.key
EOF
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat >> /etc/openvpn/bounty-blackpearl-data.conf'
local 94.23.220.83
remote 94.23.198.106
port 41201
dev tap
persist-tun
persist-key
up '/etc/openvpn/brctl-wrapper.sh addif brdata '
script-security 2
user nobody
group nogroup
comp-lzo
secret bounty-blackpearl-data_static.key
EOF
sebi@blackpearl:~$ sudo openvpn --genkey --secret /etc/openvpn/bounty-blackpearl-admin_static.key
sebi@blackpearl:~$ sudo openvpn --genkey --secret /etc/openvpn/bounty-blackpearl-data_static.key
Die <code>.key</code>-Dateien müssen nun verschlüsselt auf den 2. Host übertragen werden. Für die Konfigurationsdateien auf dem 2. Host müssen nur die Parameter von "local" und "remote" vertauscht werden.
== <code>drbd-modules</code> oder Daten-Speicher-Syncronisation ==
Als erstes einmal installieren wir die DRBD-Module und die DRBD-Utilities
sebi@blackpearl:~$ sudo aptitude -y install drbd8-modules-2.6-amd64 drbd8-utils
Dann schreiben wir noch den gemeinsam genutzten Teil der Konfigurationsdatei für DRBD.
sebi@blackpearl:~$ cat <<EOF | sudo sh -c 'cat > /etc/drbd.conf'
global {
usage-count no;
}
common {
syncer { rate 80M; }
startup {
wfc-timeout 120;
degr-wfc-timeout 60;
}
}
EOF
Zum Schluss starten wir noch DRBD über die init-Scripte, damit die Module geladen werden können.
sebi@blackpearl:~$ sudo /etc/init.d/drbd start
Beim nächsten Systemstart werden die automatisch ausgeführt.
== <code>kvm</code> oder Virtuelle Maschinen ==
Wir installieren kvm und libvirt ohne recommends, das spart uns einige Pakete, die das System sehr aufblähen würden:
sebi@blackpearl:~$ sudo aptitude -y --without-recommends install kvm libvirt-bin
Anschließend fügen wir die Nutzer der libvirt-Gruppe hinzu, so dass sie mit dem <code>virt-manager</code> arbeiten können.
sebi@blackpearl:~$ sudo usermod -G libvirt dyfa
sebi@blackpearl:~$ sudo usermod -G libvirt sebi
sebi@blackpearl:~$ sudo usermod -G libvirt chrit
sebi@blackpearl:~$ sudo usermod -G libvirt unger
sebi@blackpearl:~$ sudo usermod -G libvirt jamasi
sebi@blackpearl:~$ sudo usermod -G libvirt nhornung
Wir erweitern KVM um die Möglichkeit des PXE-Netz-Boots, einmal per Boot-ROM, einmal per Boot-CD.
sebi@blackpearl:~$ sudo wget http://rom-o-matic.net/gpxe/gpxe-0.9.9/contrib/rom-o-matic/build.php --post-data 'version=0.9.9&ofmt=ROM+binary+%28flashable%29+image+%28.rom%29&nic=virtio-net&pci_vendor_code=1af4&pci_device_code=1000&A=Get+Image' -O /usr/share/kvm/pxe-virtio.bin
sebi@blackpearl:~$ sudo wget http://rom-o-matic.net/gpxe/gpxe-0.9.9/contrib/rom-o-matic/build.php --post-data 'version=0.9.9&ofmt=ISO+bootable+image+%28.iso%29&nic=virtio-net&pci_vendor_code=1af4&pci_device_code=1000&A=Get+Image' -O /root/gpxe-0.9.9-virtio-net.iso
=== KVM-Standard-Host mit Anmerkungen===
XML Aufspannen.
<domain type='kvm'>
Domain benennen.
<name>changeme</name>
Wird generiert.
<uuid></uuid>
Benutzter Speicher; Ballooning (ändern von <code>currentMemory</code>) führte zu Abstürzen.
<memory>524288</memory>
<currentMemory>524288</currentMemory>
Anzahl der CPUs
<vcpu>1</vcpu>
Wir fahren den Gast mit 64-Bit (<code>x86_64</code>) / 32-Bit (<code>i686</code>) und booten von Platte (<code>hd</code>) / CD-ROM (<code>cdrom</code>) / PXE aus dem Netzwerk (<code>network</code>).
<os>
<type arch='x86_64' machine='pc'>hvm</type>
<boot dev='hd'/>
</os>
Wir können ACPI und APIC und werden das auch benutzen!
<features>
<acpi/>
<apic/>
</features>
Unser Betriebssystem kann mit mehreren Zeitzonen gut umgehen.
<clock offset='utc'/>
Verhalten nach Beendigung des KVM-Prozesses
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
Wir verwenden <code>/usr/bin/kvm</code> fürs virtualisieren.
<devices>
<emulator>/usr/bin/kvm</emulator>
Ein CD-Laufwerk am IDE-Bus. Können wir nach funktionierendem Netzboot weglassen.
<disk type='file' device='cdrom'>
<source file='/path/to/image.iso'/>
<target dev='hda' bus='ide'/>
<readonly/>
</disk>
Zwei Platten, am flotten virtio-Bus. <code>changeme_disk</code> ist die System-Platte, <code>changeme_srv</code> ist das Dateisystem mit den Daten, welches unter <code>/srv</code> im Zielsystem gemountet wird. Siehe auch [[IT/Dokumentation/Namenskonventionen]]
<disk type='block' device='disk'>
<source dev='/dev/raid/changeme_disk'/>
<target dev='vda' bus='virtio'/>
</disk>
<disk type='block' device='disk'>
<source dev='/dev/raid/changeme_srv'/>
<target dev='vdb' bus='virtio'/>
</disk>
Die Netzwerk-Interfaces, wieder virtio. Netzwerk-Boot ist nur von der ersten definierten Karte möglich. Boot-ROM unter rom-o-matic.net besorgen, PCI-ID: 1af4:1000. 'bridge'-Interfaces werden gleich auf eine Brücke gelegt, 'ethernet'-Interfaces bleiben im Host sichtbar und können direkt geroutet werden. Maximale Länge des device-Namens beachten!
<interface type='bridge'>
<source bridge='bradmin'/>
<target dev='changeme_adm'/>
<model type='virtio'/>
</interface>
<interface type='bridge'>
<source bridge='brdata'/>
<target dev='changeme_int'/>
<model type='virtio'/>
</interface>
<interface type='ethernet'>
<script path='no'/>
<target dev='changeme_ext'/>
<model type='virtio'/>
</interface>
Grafische Ein- und Ausgabe. <code>type='tablet'</code> nimmt er nicht an. Nur Konsole (<code><console/></code>) nimmt er auch nicht an.
<input type='mouse' bus='ps2'/>
<graphics type='vnc' autoport='yes' keymap='de'/>
</devices>
</domain>
Bitte [[IT/Dokumentation/OVH-Grundinstallation/KVM-Erstellung]] beachten!
[[Kategorie:IT-Infrastruktur]]
[[Kategorie:Dokumentation]]