Ingent

Ingent Network

  • Entreu
  • Registreu-vos

Language

  • English
  • Español
  • Català

RSS Feeds

  • Network
  • Mòduls
    • Facturació fàcil amb Haltr
    • Gestió de sistemes amb Initr
  • Blog

Arxiu de March, 2012

Virtualització de servidors

Mar 23

Publicat per Lluís a administració de sistemes

No comments

Quan tens més de dos servidors, virtualitzar-los és una bona manera de reduir les despeses de hosting. Es tracta de contractar una màquina potent i instal·lar-hi màquines virtuals que substituiran els servidors actuals: una màquina amb molta RAM, per poder-la repartir entre els servidors virtuals, i una bona CPU.

Hi ha moltes companyies de hosting que ofereixen màquines amb aquestes característiques i aquí hi ha un bon llistat de les que ofereixen Debian. Nosaltres, en aquest cas, hem escollit Hetzner.de que té preus molt competitius.

Amb el servidor ex4s tindrem una màquina de 32 GB de RAM, amb un processador Intel i7 i un RAID1 de 3TB per 59€ al més, IVA inclòs. Com que necessitem més IP’s per les màquines virtuals, demanarem una subxarxa de 6 IP, que costa 5,40€. Per poder demanar les IP cal pagar una cosa que han batejat com a “flexi pack” i que ens costarà 15€ cada més. Al contractar el servidor també haurem de pagar 149€ en concepte de posada apunt. Fent la suma, apart dels 149€ inicials, el cost mensual serà d’uns 80€, realment és un preu molt competitiu per un servidor d’aquestes característiques.

Un cop demanat, en un o dos dies ja tenim el servidor instal·lat amb el sistema operatiu que hagem escollit, que en el nostre cas és “Debian 6.0 minimal”. Entrem per SSH i instal·lem el Puppet que ens configura automàticament les alertes de Nagios, gràfiques de Munin, etc.. i ja podem centrar-nos en la virtualització.

Discs

Per defecte tot el disc està particionat i muntat, si volem fer servir volums LVM cal desmuntar una de les particions i configurar-lo amb LVM.

Escollim la partició a eliminar, en aquest cas /home

# df -ah
Filesystem            Size  Used Avail Use% Mounted on
/dev/md2             1016G  281G  684G  30% /
tmpfs                 7.8G     0  7.8G   0% /lib/init/rw
proc                     0     0     0   -  /proc
sysfs                    0     0     0   -  /sys
udev                  7.8G  168K  7.8G   1% /dev
tmpfs                 7.8G     0  7.8G   0% /dev/shm
devpts                   0     0     0   -  /dev/pts
/dev/md1              496M   38M  434M   8% /boot
/dev/md3              1.7T  196M  1.6T   1% /home

La desmuntem (si volem conservar-ne les dades caldrà copiar-les a una altre partició) i configurem l’LVM

umount /home
pvcreate /dev/md3
vgcreate vg0 /dev/md3

Cal treure l’entrada que munta /home del fitxer /etc/fstab.
A partir d’aquí podrem afegir un “storage pool” del tipus “LVM Volume Group” fent servir el virt-manager

KVM

KVM (Kernel Based Virtual Machine) és el software que farem servir per la virtualització. L’instal·lem amb l’apt:

apt-get install qemu-kvm libvirt-bin

Quan tinguem corrent el dimoni libvirt-bin, ens hi podrem connectar per crear màquines virtuals i gestionar-les. Podem fer servir virtinst a la línia de comandes o bé una aplicació d’escriptori que es diu virt-manager.

També podem migrar els servidors actuals a màquines virtuals seguint el mètode d’aquest post.

Configuració de xarxa

Hem seguit aquesta pàgina (en alemany) del wiki de Hetzner. També hi ha aquesta pàgina on s’explica una altre manera de configurar la xarxa, un pèl més complicada.

Bridge

Per poder assignar IP’s públiques a les màquines virtuals, configurarem un bridge, un dispositiu virtual que agafa els paquets d’una interfície i els enruta cap a una altre de manera transparent. La idea és fer el bridge i connectar-hi la eth0 i les màquines virtuals, tal com si estiguessin totes connectades al mateix switch de xarxa, per configurar el bridge de manera permanent hem de modificar /etc/network/interfaces:

# /etc/network/interfaces
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
  address 1.2.3.174
  broadcast 1.2.3.191
  netmask 255.255.255.224
  gateway 1.2.3.161
  pointopoint 1.2.3.161
  bridge_ports eth0
  bridge_stp off
  bridge_fd 0
  bridge_maxwait 0
  # si ho fessim amb route add -net perdriem 2 IP's:
  up route add -host 3.4.5.216 dev br0
  up route add -host 3.4.5.217 dev br0
  up route add -host 3.4.5.218 dev br0
  up route add -host 3.4.5.219 dev br0
  up route add -host 3.4.5.220 dev br0
  up route add -host 3.4.5.221 dev br0
  up route add -host 3.4.5.222 dev br0
  up route add -host 3.4.5.223 dev br0

Hem deixat eth0 sense IP i li hem donat al bridge br0 la IP principal (1.2.3.174). Afegim una ruta per cada host de la subxarxa que ens ha tocat. Es podria fer amb una sola línia amb “route add -net” però no podríem usar les IP de xarxa i de broadcast, fent-ho host per host aprofitem les 8 IP.

Creem el fitxer /etc/sysctl.d/10-no-icmp-redirects.conf i hi afegim:

# /etc/sysctl.d/10-no-icmp-redirects.conf
# Because of our network setup, the Host machine could send ICMP
# "redirect" messages to all guests, telling them to find the Hetzner
# gateway directly.  That is impossible: Hetzner would throw away the
# traffic from the virtual interfaces because of their non registered
# MAC addresses (ie different from the main interface).
net.ipv4.conf.eth0.send_redirects=0
net.ipv4.conf.br0.send_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0

Podem aplicar-ho amb:

/sbin/sysctl -w net.ipv4.conf.eth0.send_redirects=0
/sbin/sysctl -w net.ipv4.conf.br0.send_redirects=0
/sbin/sysctl -w net.ipv4.conf.all.send_redirects=0
/sbin/sysctl -w net.ipv4.conf.default.send_redirects=0

també cal activar l’ip_forward però això ho farem amb el Shorewall.

Tallafocs

Per configurar les regles de tallafocs farem servir Shorewall. Els fitxers de configuració estaran a /etc/shorewall. Hi podem copiar els exemples de /usr/share/doc/shorewall/default-config/ , ja que per defecte /etc/shorewall és buit.

Al fitxer zones podem separar conceptualment la xarxa en varies zones: la zona local (el tallafocs, fw), Internet (net) i les màquines virtuals (kvm). Com que net i kvm estan a br0, tenim dues zones a la mateixa interfície. Per separar aquestes zones hem d’especificar quins hosts pertanyen a cada zona, tal com s’explica aquí. El fitxer zones queda així:

# /etc/shorewall/zones
##############################################################################
#ZONE   TYPE            OPTIONS         IN                      OUT
#                                       OPTIONS                 OPTIONS
fw       firewall
net      ipv4
kvm:net  ipv4

La zona kvm està inclosa a la zona net, per especificar quins hosts pertanyen a kvm cal indicar-ho al fitxer hosts, així tot el que estigui a la zona net i dins els rangs de xarxa 3.4.5.216/29 i 192.168.1.0/24 (el rang que configurarem al dhcp) serà de la zona kvm, la resta serà net.

# /etc/shorewall/hosts
##############################################################################
#ZONE   HOST(S)                                 OPTIONS
kvm     br0:3.4.5.216/29,192.168.1.0/24    -

A interfaces és on assignem les interfícies a una zona, en aquest cas estem assignant br0 a la zona net

# /etc/shorewall/interfaces
##############################################################################
#ZONE   INTERFACE       BROADCAST       OPTIONS
net      br0         detect      tcpflags,nosmurfs,routeback,blacklist,dhcp

A policy definim les polítiques per defecte, hem configurat que s’accepti tot el trànsit de sortida del tallafocs i de la zona kvm, la resta es denega (drop).

# /etc/shorewall/policy
##############################################################################
#SOURCE DEST    POLICY          LOG     LIMIT:          CONNLIMIT:
#                               LEVEL   BURST           MASK
$FW     all     ACCEPT
kvm     net     ACCEPT
net     kvm     DROP        info
all     all     DROP        info

A rules definim polítiques específiques que sobreescriuen les anteriors, aquí estem definint que s’acceptin les connexions SSH entrants i els ping, però cap a kvm només els pings:

# /etc/shorewall/rules
####################################################################################################################################################
#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK    CONNLIMIT       TIME
#                                                       PORT    PORT(S)         DEST            LIMIT           GROUP
#SECTION ESTABLISHED
#SECTION RELATED
SECTION NEW

# transit cap al FW
SSH/ACCEPT  net $FW
SSH/ACCEPT  kvm $FW
Ping/ACCEPT net $FW
Ping/ACCEPT kvm $FW

# transit cap a KVM
Ping/ACCEPT  net kvm

També hem modificat shorewall.conf per activar l’ip_forward:

# /etc/shorewall/shorewall.conf
#IP_FORWARDING=Keep
IP_FORWARDING=Yes

Configuració de xarxa de la màquina virtual

Configurem una IP de la subxarxa que ens han assignat i posem la IP principal de la màquina host com a porta d’enllaç, cal posar el pointopoint per indicar que tot el trànsit ha de passar per 1.2.3.174, cal tenir en compte que la màquina virtual no pot parlar directament amb el gateway de Hetzner, ja que l’adreça MAC de la màquina virtual és desconeguda i la rebutgen.

# /etc/network/interfaces
auto eth0
iface eth0 inet static
       address 3.4.5.216
       netmask 255.255.255.255
       gateway 1.2.3.174
       pointopoint 1.2.3.174
       # dns-* options are implemented by the resolvconf package, if installed
       dns-nameservers 213.133.98.98 213.133.99.99

Configuració DHCP

Ens pot resultar útil tenir un servidor DHCP per instal·lar noves màquines virtuals sense haver de configurar manualment la xarxa. Configurar-lo ha sigut una mica complicat: el que hem fet és afegir una IP d’un rang privat al bridge br0.

# /etc/network/interfaces
auto br0:0
iface br0:0 inet static
  address 192.168.1.1
  broadcast 192.168.1.255
  netmask 255.255.255.0

Al dhcpd.conf hem afegit aquesta declaració:

# /etc/dhcp/dhcpd.conf
subnet 0.0.0.0 netmask 0.0.0.0 {
  range 192.168.1.10 192.168.1.200 ;
  option routers 192.168.1.1;
  option subnet-mask 255.255.255.0;
  option domain-name-servers 213.133.99.99, 213.133.100.100, 213.133.98.98;
}

Hem provat de configurar-ho amb “subnet 192.168.1.0 netmask 255.255.255.0” però sembla que al dhcpd no li agrada que li configuris el rang de l’àlies br0:0 i fallava l’arrencada amb aquest error:

dhcpd: Not configured to listen on any interfaces!

Només queda configurar el NAT al Shorewall perquè enruti el trànsit de 192.168.1.0/24:

# /etc/shorewall/masq
##############################################################################
#INTERFACE              SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK    USER/
#                                                                                       GROUP
br0            192.168.1.0/24

Conclusions

El preu d’una màquina virtual auto-gestionada d’aquesta manera és molt més baix que qualsevol altre màquina virtual de proveïdors com Linode, Rackspace o Amazon. Per exemple, una màquina virtual de 1 GB de Linode val 30€ i en el que hem muntat n’hi caben 30. El cost és 10 vegades menor.

El sistema de virtualització KVM, Linux i tot el software que hem utilitzat és lliure i no està subjecte a costoses llicències. Així doncs en el preu no hi hem de sumar cap llicència, cosa que si que hauríem de fer en el cas d’haver triat fabricants com Microsoft i VMware.

Com a contrapartida si la màquina física falla, fallen totes les màquines virtuals. Així doncs és aconsellable tenir, com a mínim, dos servidors per si un falla poder arrencar un backup de la màquina virtual a l’altre.

Accelerar el temps de càrrega de les aplicacions RubyOnRails

Mar 23

Publicat per Lluís a administració de sistemes

No comments

A vegades quan accedim a una aplicació RubyOnRails notem que la primera petició triga molt i després ja va més fluït. Això passa perquè a la primera connexió el Passenger ha de carregar l’aplicació en memòria, quan es deixen de rebre peticions durant un cert temps, el Passenger la descarrega i a la següent petició caldrà tornar a aixecar-la.
Podem evitar aquesta espera si mantenim sempre una o més instàncies de l’aplicació aixecades. Passenger ens permet configurar-ho amb el paràmetre PassengerMinInstances

PassengerMaxPoolSize 15
PassengerPoolIdleTime 10

<VirtualHost *:80>
    ServerName foobar.com
    DocumentRoot /webapps/foobar/public
    PassengerMinInstances 3
</VirtualHost>

amb aquesta configuració tindrem com a mínim sempre tres instàncies aixecades per servir peticions, excepte quan acabem d’engegar l’Apache, ja que per defecte el Passenger no carregarà les instàncies. Podem fer que es carreguin a l’engegar l’Apache amb PassengerPreStart:

PassengerMaxPoolSize 15
PassengerPoolIdleTime 10

<VirtualHost *:80>
    ServerName foobar.com
    DocumentRoot /webapps/foobar/public
    PassengerMinInstances 3
</VirtualHost>

PassengerPreStart http://foobar.com/

Així en arrencar l’Apache es farà una petició a la URL indicada i es carregaran les instàncies de Passenger.

Al comprovar la nova configuració, ens surt aquest error:

[root@webserver ~]# apache2ctl configtest
Syntax error on line 4 of /etc/apache2/sites-enabled/foobar.com.conf:
Invalid command 'PassengerMinInstances', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.

és perquè la versió de Passenger que porta Debian Squeeze (2.2.11debian), encara no suporta PassengerMinInstances, desinstal·lem el paquet libapache2-mod-passenger i instal·lem el Passenger amb Rubygems:

[root@webserver ~]# gem install passenger --no-ri --no-rdoc
# /etc/apache2/mods-available/passenger.conf
<IfModule mod_passenger.c>
   PassengerRoot /var/lib/gems/1.8/gems/passenger-3.0.11
   PassengerRuby /usr/bin/ruby1.8
</IfModule>
# /etc/apache2/mods-available/passenger.load
LoadModule passenger_module /var/lib/gems/1.8/gems/passenger-3.0.11/ext/apache2/mod_passenger.so
[root@webserver ~]# a2enmod passenger
[root@webserver ~]# /etc/init.d/apache2 restart
    • Recent comments
    • Archives
    • Tags
    • Categories
    • b2b (1)
    • products (1)
    • administració de sistemes (11)
    accounting b2b backscatting bandwidth centos cloud debian desktop exchange internet explorer iowait java kvm linux mdadm migration munin p2v passenger peppol performance php postfix products raid raid5 rdp ruby on rails server services shorewall terminal server tmpfs traffic virtualization windows wine workstation
    • març 2012 (2)
    • febrer 2012 (2)
    • gener 2012 (1)
    • desembre 2011 (1)
    • novembre 2011 (3)
    • octubre 2011 (2)
    • agost 2011 (2)
    • Ahlonko: Nice Post ...It's gonna save me lot of time. THANK
    • windows_7: Ante la próxima desaparición de Windows XP, la necesidad de las empresas de migrar a Windows 7 se h...
    • Lluís: Hi Philip, thanks for this point, updated post!
    • Philip Helger: Hi! There's a little typo in this page. The generated DNS names should start with upperbase "B"...
Copyright © 2021 Ingent RSS Feeds