XEN Server - zmiana wielkości woluminu

Zmiana wielkości woluminu w XEN Server

Jeśli konieczna jest zmiana wielkości woluminu, jest to możliwe do zrobienia z CLI, jak i z XenCenter.

UWAGA: Możliwe jest rozszerzenie woluminu (extend), nie jest możliwe jest zmniejszenie.

Zmiana wielkości woluminu z CLI:

1. Zalogować się na konsolę serwera XEN.

2. Wyłączyć odpowiednią maszynę wirtualną.

3. Odnaleźć odpowiedni UUID (Universal Unique Identifier) dysku za pomocą komendy:
       # xe vm-disk-list vm=<nazwa VM>

4. Zmienić rozmiar woluminu za pomocą komendy:
       # xe vdi-resize uuid=<vdi uuid> size=<size (GiB, MiB)>

XenServer - instalowanie patchy z CLI

Installing the update using the off-host CLI

1. Download the update to a known location on a computer that has the XenServer CLI or XenCenter installed.
2. Extract the xsupdate file from the zip.
3. If using Windows, start a Command Prompt and navigate to the XenCenter directory, for example:

cd C:\Program files\Citrix\XenCenter

4. Upload the xsupdate file to the Pool Master by entering the following commands:
   (Where hostname is the Pool Master's IP address or DNS name.)
   

   xe patch-upload -s <hostname> -u root -pw <password> file-name=<path_to_update_file> XS60E016.xsupdate

   XenServer assigns the update file a UUID which this command prints. Note the UUID.

   46BC6C41-3889-41BE-B394-A4D8455A58E2



5. Apply the hotfix to all hosts in the pool, specifying the UUID of the hotfix:

   xe patch-pool-apply uuid=<46BC6C41-3889-41BE-B394-A4D8455A58E2>

6. Verify that the update was applied by using the patch-list command.

   xe patch-list -s <hostname> -u root -pw <password> name-label=XS60E016

   If the update has been successful, the hosts field will contain the UUIDs of the hosts this patch was successfully applied to. This should be a complete list of all hosts in the pool.
7. The hotfix is applied to all hosts in the pool, but it will not take effect until each host has been rebooted. For each host, migrate the VMs that you wish to keep running, and shutdown the remaining VMs before rebooting the host.
8. To verify in XenCenter that the update has been applied correctly, select the Pool, and then click the General tab. This displays the Pool properties. In the Updates section, ensure that the update is listed as Fully applied.    

XenServer - dodawanie nowego lokalnego SR

Ostatnio musiałem dodać do XEN SERVER 6.0 dodatkowe dyski. Ale tu mała konsternacja, z XenCenter nie ma możliwości dodania nowego lokalnego storage, wyłącznie różne dyski sieciowe - NFS, iSCSI, FC itp. Można to jednak zrobić używając niezawodnej konsoli. Zatem po kolei co zrobić, aby dodać nowy dysk twardy jako Storage Repository.

1. Sprawdzamy zainstalowane dyski twarde

# fdisk -l

Disk /dev/sdb: 999.9 GB, 999989182464 bytes

255 heads, 63 sectors/track, 121575 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

2. Wyświetlamy UUID hosta XEN SERVER

# xe host-list

uuid ( RO)                : a3fa9eea-21de-45f6-a89a-4e23b3010c68
    name-label ( RW): mordor
    name-description ( RW): XenServer 6.0.0

3. Dodajemy storage repository

# xe sr-create host-uuid=a3fa9eea-21de-45f6-a89a-4e23b3010c68  content-type=user type=ext device-config:device=/dev/sdb shared=false name-label="Local Storage 2"

4. Teraz możemy sprawdzić czy nowy dysk jest widziany przez XEN SERVER

# xe sr-list

uuid ( RO)                : d5175b5c-d042-aa49-ec90-1fcc6d2fc7a2
          name-label ( RW): Local Storage 2
    name-description ( RW):
                host ( RO): mordor
                type ( RO): lvm
        content-type ( RO): user

Nagios - monitorowanie kontrolera RAID 3WARE 9650SE

Z uwagi na budżet, nie używam "dużych" serwerów takich jak np. HP Proliant DL380 G7. Do wykorzystywanych przeze mnie funkcjonalności w zupełności wystarcza najmniejszy HP Proliant DL 120 G6 i G7. Niestety HP ograniczyło ich funkcjonalność przez zastosowanie kontrolera RAID SmartArray B110i SATA, który nie jest wspierany przez XenServer. Nie zależnie od ustawień w BIOSie maszyny, XenServer widzi dyski fizyczne a nie np. zestaw RAID1. Funkcjonalność serwera DL120 można poprawić przez zastosowanie kontrolera RAID 3Ware z rodziny 9560SE. Są ta bardzo zaawansowane kontrolery obsługujące od 4 do 24 dysków SATA i umożliwiające zbudowanie macierzy RAID praktycznie każdego poziomu  z RAID6 włącznie. Mogą być one doposażone w moduł bateryjny służący do podtrzymania cache dyskowego w razie nagłej utraty zasilania, co zapobiega utracie danych przy trybie zapisu writeback cache. Niestety jest też dość znaczący minus. Normalnie serwer posiada moduł diagnostyczny i w razie awarii dysku na kieszeni wyświetlany jest alarm w postaci diody LED. Po zastosowaniu kontrolera nie mamy dostępu do tej funkcjonalności. Jest to prawdopodobnie do obejścia, ale wymaga ingerencji w okablowanie wewnętrzne serwera. Z pomocą do monitoringu stanu pracy macierzy, dysków i baterii przyszedł mi Nagios i plugin napisany przez Mariusa Heina z firmy Netways Gmbh a znaleziony na http://exchange.nagios.org. Marius ograniczył się do testowania wyłącznie zestawów RAID na lokalnej maszynie. Rozbudowałem ten plugin o możliwość monitorowania maszyny zdalnej, testowanie dysków fizycznych i baterii. Dzięki temu uzyskałem w pełni funkcjonalny monitoring stanu macierzy dyskowej w serwerach.


jak to działa???

Plugin jest napisany w Perlu, wykorzystuje protokół SSH do zdalnego wykonania programu na monitorowanym serwerze. Do logowania się na zdalnej maszynie użyłem kluczy RSA by nie było konieczności podawania hasła - opisane tutaj. 

UWAGA: Skrypt używa konta roota dla dostępu do zdalnej maszyny - tak wiem jest to niebezpieczne, ale w posiadanym przeze mnie środowisku jest to nieistotne. Można przystosować skrypt do użycia z dowolnym użytkownikiem, który będzie miał możliwość wykonania kodu na zdalnej maszynie. 

Oprócz tego potrzebny będzie interfejs CLI kontrolera 3Ware. To za jego pomocą uzyskamy dostęp do kontrolera i stanu poszczególnych komponentów systemu RAID. W zależności od systemu Linux potrzebny będzie jeden z poniższych plików:
     
tw_cli-linux-x86_64-9.4.1.3.tgz
tw_cli-linux-x86_64-9.5.3.tgz
tw_cli-linux-x86-9.3.0.7.tgz

Program tw_cli odpowiada za bezpośredni dostęp do interfejsu kontrolera, program tw_sched jest portem pomiędzy cronem a tw_cli i pozwala na automatyzację niektórych funkcji, np. cykliczne test macieży. Składnia obu programów jest opisana w załączonej dokumentacji.

Ostatnim krokiem jest konfiguracja Nagiosa - komendy, testy itp.


konfiguracja

Teraz trzeba zebrać to w całość i uruchomić. Zatem po kolei:

1. instalacja tw_cli 

Kopiujemy i rozpakowujemy archiwum z oprogramowaniem dla kontrolera

# tar -xvf tw_cli-linux-x86-9.3.0.7.tgz

Program ma bardzo bogaty help, opisany również w manach.

2. instalacja i konfiguracja pluginu

Plik z pluginem należy skopiować do katalogu /usr/lib/nagios/plugins i upewnić się że użytkownik nagios może wykonywać skrypt, np.

-rwxr-xr-x 1 root root 6723 06-25 13:29 check_3ware.pl

Plugin jest to pobrania TUTAJ

Oprócz tego, jeśli to konieczne należy zmienić użytkownika, który loguje się przez SSH do maszyny - linia 55

$conf{'path'} = 'ssh root@';



3. konfiguracja Nagiosa

W katalogu /etc/nagios-plugins/config należy utworzyć plik z konfiguracją komend dla Nagiosa:


# 'check_3ware' command definition
define command{
        command_name    check_3ware_raid
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -U $ARG2
        }

define command{
        command_name    check_3ware_disc
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -D $ARG2$
        }

define command{
        command_name    check_3ware_bbu
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -B $ARG2$
        }

Następnie w pliku konfiguracyjnym dodajemy nowe serwisy, należy pamiętać o zmianie   parametru hostgroup_name na odpowiedni dla posiadanej konfiguracji.


define service {
        hostgroup_name          xen-servers
        service_description     RAID Unit 0
        check_command           check_3ware_raid!0!0
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     RAID Unit 1
        check_command           check_3ware_raid!0!1
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     BBU
        check_command           check_3ware_bbu!0!0
        use                     template-service
}
define service {

        hostgroup_name          xen-servers
        service_description     Disc 0
        check_command           check_3ware_disc!0!0
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     Disc 1
        check_command           check_3ware_disc!0!1
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     Disc 2
        check_command           check_3ware_disc!0!2
        use                     template-service
}

define service {

        hostgroup_name          xen-servers

        service_description     Disc 3

        check_command           check_3ware_disc!0!3

        use                     template-service

}

Na koniec weryfikujemy konfigurację Nagiosa i restartujemy serwis.

# /usr/sbin/nagios3 -v /etc/nagios3/nagios.cfg
# /etc/init.d/nagios3 restart



4. A oto efekt

Alarm modułu bateryjnego

Alarmu dysku fizycznego i macierzy

XenServer - interfejsy VLAN

Kilka dni temu robiłem małą instalację XenServera na lekko zmodyfikowanym serwerze HP Proliant DL120 G7. Normalnie nie nadaje się on do wirtualizacji, gdyż zastosowany przez HP kontroler macierzy RAID nie jest obsługiwany przez XenServer. Serwer jest standardowo wyposażony w dwa interfejsy ethernet, z czego interfejs pierwszy jest współdzielony z konsolą iLo3. Ponieważ potrzebowałem rozdzielić ruch zarządzający od ruchu produkcyjnego do pracy musiałem zaprząc protokół 802.1q czyli uruchomić obsługę VLANów. Założenie było następujące:

port Ethernet 1
- VLAN10 dla konsoli iLo3 - tworzony z poziomu konsoli, nie będzie opisywane,
- VLAN12 dla zarządzania XenServerem

port Ethernet 2
- VLAN25 dla maszyny wirtualnej 1
- VLAN26 dla maszyny wirtualnej 2

W czasie instalacji serwera nie przypisujemy żadnego adresu IP do interfejsów sieciowych, jeśli to zrobimy, trzeba będzie "odkręcać" bo adresy są podczas instalacji przypisywane do VLAN1 i ramki nie są tagowane. Po instalacji uruchamiamy command-line i wykonujemy:

1. tworzenie nowych interfejsów

# xe network-create name-label=<NAME_OF_NEW_INTERFACE>

np.

# xe network-create name-label=xenbr0.12

Tworzymy tyle interfejsów, ile jest potrzebne. Ja zrobiłem 3: xenbr0.12, xenbr1.25, xenbr1.26

2. wyświetlenie zainstalowanych kart sieciowych (PIF) oraz interfejsów sieciowych 

# xe pif-list

uuid ( RO)                  : 3f1ac1b6-800b-a7e3-1f3b-c142974199cb
                device ( RO): eth1
    currently-attached ( RO): true
                  VLAN ( RO): -1
          network-uuid ( RO): 18c82b20-d97b-2c88-fe25-07039342a1d9


uuid ( RO)                  : e5c0dee5-ec02-0aef-ac0c-4d5d1c88e948
                device ( RO): eth0
    currently-attached ( RO): true
                  VLAN ( RO): -1
          network-uuid ( RO): be31f919-9c54-c21e-43ec-df4b23bf02f6

# xe network-list

uuid ( RO)                : 70d0220b-0454-ec68-d232-12ea90e60fad

          name-label ( RW): xenbr1.26

    name-description ( RW): web server

              bridge ( RO): xapi2

uuid ( RO)                : 99a560ba-599a-f617-aa3e-1563fffa2b73

          name-label ( RW): xenbr1.25

    name-description ( RW): mail server

              bridge ( RO): xapi0

uuid ( RO)                : ed3346b4-a650-013c-afb2-a617234468cd

          name-label ( RW): xenbr0.19

    name-description ( RW): management

              bridge ( RO): xapi1

3. utworzenie interfejsów sieciowych 802.1q

# xe vlan-create network_uuid=<UUID_OF_INTERFACE> pif_list=<UUID_OF_PIF> vlan=<VLAN_NUMBER>

np.

# xe vlan-create network_uuid=be31f919-9c54-c21e-43ec-df4b23bf02f6 pif_list=ed3346b4-a650-013c-afb2-a617234468cd vlan=19

I tak dla każdego z interfejsów. Teraz pozostaje już nadać adres IP, można zrobić to z xsconsole, pojawią się tam nowe interfejsy. A do pełni szczęścia :) pozostaje skonfigurować switch LAN.

XenServer - backup konfiguracji i oprogramowania serwera

Oprócz opisanego w poprzednim poście backupu maszyn wirtualnych, konsola XenServera umożliwia wykonanie kopii zapasowej samego serwera oraz jego konfiguracji. W tym celu należy wykonać komendę:

# xe host-backup host=<HOSTNAME> file-name=<PATH and FILENAME.xbk>

np.

# xe host-backup host=xen1 file-name=/mnt/nfs/xen1bckp.xbk

UWAGA: Aby odtworzyć serwer z kopii zapasowej należy wystartować system z dysku instalacyjnego XenServer. W przeciwieństwie do kopii zapasowych maszyn wirtualnych, odtworzenie kopii zapasowej serwera jest możliwe jedynie na oryginalnej maszynie.

XenServer - prosty backup maszyny wirtualnej

Istnieje co najmniej kilka metod wykonywania kopii zapasowych maszyn w Citrix XenServer. Większość z nich to dość drogie rozwiązania komercyjne jak PHD Virtual Backup . Oczywiście oferują one wiele użytecznych funkcji, ale czy jest to niezbędne, gdy mamy do backupu kilka maszyn wirtualnych, które na dodatek pracują na darmowej wersji XenServera? Nie, XenServer ma wbudowane narzędzie do wykonania i przywracania kopii zapasowej maszyny. Nie jest ono może intuicyjne i wymaga nieco wiedzy od użytkownika, ale jest w pełni funkcjonalne i sprawnie wykonuje żądane czynności. Zatem, jak to zrobić?

 przygotowanie do backupu

Do wykonania kopii zapasowej musimy przygotować miejsce. Najlepiej by był to jakiś dysk sieciowy, który potrafi udostępniać swoje zasoby jako dysk NFS. Oczywiście musi być on udostępniony z prawami do zapisu. Z konsoli XenServera należy utworzyć miejsce, gdzie podmontujemy dysk sieciowy:

 ~# mkdir /mnt/nfs

a następnie montujemy zasób sieciowy

~# mount -t nfs <IP_ADDR_>:<PATH> /mnt/nfs

<IP_ADDR> - adres IP dysku sieciowego 
<PATH>     - ścieżka do katalogu na dysku sieciowym, gdzie będzie wykonywana kopia zapasowa

UWAGA: nie jest to ścieżka zasobu SMB tylko NFS więc o ile jest to możliwe, należy sprawdzić na dysku, jaka jest prawidłowa ścieżka. Np. na moim Icy Box IB-NAS4220-B ścieżka NFS do zasobu public to /mnt/ide1/public

  wykonanie backupu 

Gdy mamy już przygotowane miejsce, możemy przystąpić do wykonywania kopii zapasowej. Najpierw należy wyświetlić listę maszyn wirtualnych:

 # xe vm-list
  

uuid ( RO)           : 2eff6db7-cf0d-24c2-8009-6c45c4435e0f

     name-label ( RW): machine1
    power-state ( RO): running


uuid ( RO)           : 2e4a8a77-e75a-47e7-5eb6-1aa9b5cf6b54
     name-label ( RW): machine2
    power-state ( RO): running

Jeśli zostały zainstalowane poprawnie XenTools na maszynach wirtualnych to wykonujemy kopię zapasową maszyny

 # xe vm-export vm=<UUID> filename=<PATH and FILENAME.xva>

np.

# xe vm-export vm=2eff6db7-cf0d-24c2-8009-6c45c4435e0f filename=/mnt/nfs/machine1_backup.xva

I możemy się cieszyć wykonana kopią maszyny. Nieco problemów stworzy maszyna, która z różnych powodów nie ma zainstalowanych XenTools. Taką maszynę musimy zatrzymać przed wykonaniem kopii zapasowej i uruchomić po zakończeniu operacji

 # xe vm-shutdown vm=<UUID>

 # xe vm-start vm=<UUID>

Kopię zapasową wykonujemy w identyczny sposób jak poprzednio. 

TU jest prosty skrypt, który realizuje backup wybranych maszyn. Nazwy maszyn trzeba wpisać w zmienną $HOSTS.

  przywracanie kopii zapasowej

Przywrócenie kopii zapasowej wykonujemy w podobny sposób jak backup. Najpierw należy sie upewnić czy jest prawidłowo podmontowany zasób z kopią zapasową. Następnie należy wyświetlić listę dostępnych Storage Repository i ich UUID

# xe sr-list

uuid ( RO)                : fffb9b4d-16e5-20b0-8154-962781d362c2
          name-label ( RW): Local storage
    name-description ( RW):
                host ( RO): xen1
                type ( RO): lvm
        content-type ( RO): user


uuid ( RO)                : d5175b5c-d042-aa49-ec90-1fcc6d2fc7a2
          name-label ( RW): Local Storage 2
    name-description ( RW):
                host ( RO): xen1
                type ( RO): lvm
        content-type ( RO): user 

Przywrócenie kopii wykonujemy za pomocą komendy

# xe vm-import sr-uuid=<UUID> filename=<PATH and FILENAME.xva>

np.

# xe vm-import sr-uuid=fffb9b4d-16e5-20b0-8154-962781d362c2 filename=/mnt/nfs/machine1_backup.xva