İmaj gereksinimleri

Linux

Linux tabanlı bir imajın OpenStack Hesaplama bulutunda tam işlevselliğe sahip olması için, bazı gereksinimler bulunur. Bunlardan bazıları için, gereksinimleri cloud-init paketini kurarak sağlayabilirsiniz. İmajın kullanmayı planladığınız OpenStack özelliklerini desteklediğinden emin olmak için imajı oluşturmadan önce bu kısmı okuyun.

  • Disk bölümleri ve önyüklemede kök bölümü yeniden boyutlandır (cloud-init)

  • Gömülü MAC adresi bilgisi yok

  • SSH sunucu çalışıyor

  • Güvenlik duvarını kapat

  • Sunucuya ssh açık anahtarını kullanarak eriş (cloud-init)

  • Kullanıcı verisi ve diğer metaveriyi işle (cloud-init)

  • Linux çekirdeğinde yarı sanallaştırılmış Xen desteği (Yalnızca Linux çekirdeği sürüm < 3.0 ile Xen hipervizörü)

Disk bölümleri ve önyüklemede kök bölümleri yeniden boyutlandır (cloud-init)

Bir Linux imajı oluşturduğunuzda, diskleri nasıl bölümleyeceğinize karar vermelisiniz. Bölümleme yöntemi seçini yeniden boyutlandırma işlevselliğini etkileyebilir, aşağıdaki kısımlarda bu anlatılıyor.

Bir sanal makine imajındaki diskin boyutu ilk olarak imajı oluşturduğunuzda kararlaştırılır. Ancak OpenStack farklı nitelikler belirterek farklı boyutta sürücülerle sunucular başlatmanıza izin verir. Örneğin imajınız 5 GB diskle oluşturulduysa, ve m1.small niteliğinde bir sunucu başlatırsanız. Sonuçta elde edilen sanal makine sunucusunun öntanımlı olarak 20 GB bir diski olur. Bir sunucu diski yukarı boyutlandırıldığında, sadece sonuna sıfırlar eklenir.

İmajınız kullanıcı tarafıdan istenen boyutla eşleşecek şekilde önyüklemeden bölümlerini yeniden boyutlandırabilmelidir. Aksi halde imajınız oluşturulduğun ayarlanan disk boyutu nitelikteki disk boyutundan küçükse sunucu önyüklendikten sonra elle bölümleri yeniden boyutlandırıp nitelikle ilişkili ek disk boyutuna erişimeniz gerekir.

Xen: bir ext3/ext4 bölümü (LVM yok)

OpenStack XenAPI sürücüsünü kullanırsanız, Hesaplama servisi otomatik olarak sunucunuz için bölümü ve dosya sistemini ayarlar. Şu durumların hepsi karşılanıyorsa otomatik yeniden boyutlandırma yapılır:

  • auto_disk_config=True imaj kaydında imaj için özellik olarak ayarlanır.

  • İmajdaki diskte yalnızca bir bölüm vardır.

  • Tek bölümdeki dosya sistemi ext3 veya ext4’dür.

Böylece, Xen kullanıyorsanız, imajlarınız oluşturduğunuzda tek bir ext3 veya ext4 bölüm oluşturmanızı öneriyoruz (LVM ile yönetilmeyen). Aksi halde, okumaya devam edin.

cloud-init/cloud-tools ile Xen-Olmayan: bir ext3/ext4 bölümü (LVM yok)

İmajınız içim şu ögeleri yapılandırmalısınız:

  • İmaj için bölüm tablosu imajın asıl boyutunu tanımlar.

  • İmaj için dosya sistemi imajın asıl boyutunu doldurur.

Ardından, önyükleme sürecinde, şunları yapmalısınız:

  • Bölüm tablosunu değiştirerek ek bölümden haberdar edin:

    • LVM kullanmıyorsanız, tabloyu mevcut kök bölümü bu ek alanı kapsayacak şekilde genişletmelisiniz.

    • LVM kullanıyorsanız, bölüm tablosuna yeni bir LVM girdisi ekleyebilir, yeni bir LVM fiziksel birimi oluşturabilir, onu bir birim grubuna ekleyebilir, ve mantıksal bölümü kök birimle genişletebilirsiniz.

  • Kök birim dosya sistemini yeniden boyutlandır.

Dağıtımınıza göre, bunu desteklemenin en basit yolu imajınızda şunları kurmaktır:

  • cloud-init paketi,

  • cloud-utils paketi, Ubuntu ve Debian’da ayrıca bölümleri genişletmeye yarayan growpart aracını da içerir,

  • Fedora, CentOS 7 veya RHEL 7 kullanıyorsanız, cloud-utils-growpart paketi, bölümleri genişletmeye yarayan growpart aracını da içerir,

  • Ubuntu veya Debian kullanıyorsanız, cloud-initramfs-growroot paketi, ilk önyüklemede kök bölümü yendien boyutlandırmayı destekler.

Bu paketler yüklü olduğunda, imaj kök bölümün yeniden boyutlandırılmasını önyüklemede yapar. Örneğin /etc/rc.local dosyasında.

cloud-initramfs-tools paketini yükleyemiyorsanız, Robert Plestenjak’ın imajın önyüklemede düzgün yeniden boyutlandırılmasını sağlamak için growpart kullanarak ramdisk’i güncelleyen betikler içeren linux-rootfs-resize isimli bir GitHub projesi var.

cloud-init ve cloud-utils paketlerini kurabilirseniz, imajları oluştururken tek bir ext3 veya ext4 bölüm oluşturmanızı öneriyoruz (LVM tarafından yönetilmeyen).

cloud-init/cloud-tools olmadan Xen-Dışı: LVM

cloud-init ve cloud-tools paketlerini misafirinizde kuramıyorsanız, ve yeniden boyutlandırmayı desteklemek istiyorsanız, imajınızın önyüklemede çalıştırarak bölüm tablosunu değiştirdiği bir betik yazmalısınız. Bu durumda, bölümlerinizi yönetmek için LVM kullanmanızı öneriyoruz. Linux çekirdeğindeki bir kısıtlama sebebiyle (bu yazının yazıldığı tarihte) bağlı durumda bölümleri olan bir raw diskin bölüm tablosunu değiştiremezsiniz, ama LVM ile bunu yapabilirsiniz.

Betiğiniz aşağıdaki gibi bir şey yapmalı:

  1. Diskte ek bir alan olup olmadığını tanımalı. Örneğin, parted /dev/sda --script "print free" çıktısını ayrıştırabilir.

  2. Ek alana sahip yeni bir LVM bölümü oluşturmalı. Örneğin, ‘’parted /dev/sda –script “mkpart lvm …”``.

  3. Yeni bir fiziksel birim oluşturmalı. Örneğin, pvcreate /dev/sda6.

  4. Birim grubunu bu fiziksel bölümle genişletin. Örneğin, vgextend vg00 /dev/sda6.

  5. Kök bölümü içeren mantıksal birimi boş alan miktarınca genişletin. Örneğin, lvextend /dev/mapper/node-root /dev/sda6.

  6. Kök dosya sistemini yeniden boyutlandırın. Örneğin resize2fs /dev/mapper/node-root.

Linux dağıtımınız /boot yolunun LVM tarafından yönetilmemesini gerektiren eski dağıtımlardan değilse ayrı bir /boot bölümüne ihtiyacınız yoktur.

Gömülü MAC adresi bilgisi yok

İmajdaki ağ kalıcılık kurallarını kaldırmalısınız çünkü sunucudaki ağ arayüzünün eth0 dışında bir arayüz olarak açılmalarına sebep olur. Bunun sebebi imajınızın ilk kurulumdaki ağ arayüz kartının MAC adresinin kaydına sahip olmasıdır, ve bu MAC adresi sunucu her önyüklendiğinde değişir. Aşağıdaki dosyaları düzenlemelisiniz:

  • /etc/udev/rules.d/70-persistent-net.rules dosyasını boş bir dosyayla değiştirin (ağ kalıcılık kurallarını içerir, MAC adresleri de dahil).

  • /lib/udev/rules.d/75-persistent-net-generator.rules dosyasını boş bir dosyayla değiştirin (bu yukardaki dosyayı üretir).

  • Fedora tabanlı imajlarda /etc/sysconfig/network-scripts/ifcfg-eth0 dosyasından HWADDR satırını silin.

Not

Ağ kalıcılık kuralları dosyasını silerseniz, önyükleme sırasında udev kernel uyarısı alabilirsiniz, bu yüzden boş bir dosyayla değiştirmenizi öneriyoruz.

Ssh sunucunun çalıştığından emin olun

İmaja bir ssh sunucu kurmalı ve önyükleme sırasında başladığından emin olmalısınız, yoksa OpenStack içinde açıldığında sunucuya ssh ile erişemezsiniz. Bu paket genellikle openssh-server olarak adlandırılır.

Güvenlik duvarını kapat

Genellikle, imajınızdaki güvenlik duvarlarını kapatmanızı ve sunuculara erişim için OpenStack güvenlik gruplarını kullanmanızı öneriyoruz. Bunun sebebi sunucuda çalışan güvenlik duvarının sunucunuza bağlanamadığınız durumlarda sorun gidermeyi zorlaştıracak olmasıdır.

Ssh açık anahtar kullanarak sunucuya erişin (cloud-init)

OpenStack’de çalışan sanal makinelere erişmek için kullanıcılar genellikle ssh ile açık anahtarlı kimlik doğrulama kullanır. Bunun çalışması için, sanal makine imajınız önyükleme sırasında ssh açık anahtarını OpenStack metaveri servisinden veeya yapılandırma sürücüsünden indirecek şekilde yapılandırılmalıdır.

Bir imajda hem XenAPI aracısı hem de cloud-init mevcutsa, ssh anahtarı eklemeyi cloud-init ele alır. İmajda cloud_init_intalled özelliği mevcutsa sistem ``cloud-init``in mevcut olduğunu varsayar.

cloud-init kullanarak açık anahtarı çekin

cloud-init paketi otomatik olarak açık anahtarı metaveri sunucusundan getirir ve anahtarı hesaba ekler. Hesap dağıtıma göre değişiklik gösterir. Ubuntu tabanlı sanal makinelerde, hesap ismi ubuntu olur, Fedora tabanlı sanal makinelerde, hesap ismi fedora ve CentOS tabanlı sanal makinelerde hesap ismi centos olur.

cloud-init tarafıdan kullanılan hesap ismini /etc/cloud/cloud.cfg dosyasını düzenleyerek farklı kullanıcı içeren bir satır ekleyerek değiştirebilirsiniz. Örneğin, cloud-init``i ``admin isimli bir hesaba anahtar koyacak şekilde yapılandırmak için , yapılandırma dosyasında aşağıdaki sözdizimini kullanın.

users:
  - name: admin
    (...)

Açık anahtarı çekmek için özel bir betik yazın

Misafir içinde cloud-init paketini kuramıyor ya da kurmak istemiyorsanız, açık anahtarı çekip kullanıcı hesabına eklemek için özel bir betik yazabilirsiniz.

Ssh açık anahtarını çekip root hesabına eklemek için, /etc/rc.local dosyasını düzenleyin ve touch /var/lock/subsys/local satırından önce şu satırları ekleyin. Bu kod parçası rackerjoe oz-image-build CentOS 6 şablonundan alınmıştır.

if [ ! -d /root/.ssh ]; then
  mkdir -p /root/.ssh
  chmod 700 /root/.ssh
fi

# Fetch public key using HTTP
ATTEMPTS=30
FAILED=0
while [ ! -f /root/.ssh/authorized_keys ]; do
  curl -f http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/metadata-key 2>/dev/null
  if [ $? -eq 0 ]; then
    cat /tmp/metadata-key >> /root/.ssh/authorized_keys
    chmod 0600 /root/.ssh/authorized_keys
    restorecon /root/.ssh/authorized_keys
    rm -f /tmp/metadata-key
    echo "Successfully retrieved public key from instance metadata"
    echo "*****************"
    echo "AUTHORIZED KEYS"
    echo "*****************"
    cat /root/.ssh/authorized_keys
    echo "*****************"
  else
    FAILED=`expr $FAILED + 1`
    if [ $FAILED -ge $ATTEMPTS ]; then
      echo "Failed to retrieve public key from instance metadata after $FAILED attempts, quitting"
      break
    fi
    echo "Could not retrieve public key from instance metadata (attempt #$FAILED/$ATTEMPTS), retrying in 5 seconds..."
    sleep 5
  fi
done

Not

Bazı VNC istemcileri : (iki nokta) işaretini ; (noktalı virgül) ve _ (alt çizgi) işaretini - (tire) ile değiştirir. Dosyayı VNC oturumu üzerinden değiştiriyorsanız, http; değil http: ve authorized-keys değil authorized_keys olduğundan emin olun.

Kullanıcı verisini ve diğer metaveriyi işle (cloud-init)

Ssh açık anahtara ek olarak bir imaj OpenStack’den daha fazla bilgiye ihtiyaç duyabilir, örneğin kullanıcının imajı isterken gönderdiği kullanıcı verisinin sunuculara sağlanması. Sunucu önyüklenirken sunucunun makine adını ayarlamak isteyebilirsiniz. Veya imajı kullanıcı verisini önyüklemeden betik olarak çalıştıracak şekilde yapılandırabilirsiniz.

Bu bilgiye metaveri servisi üzerinden veya Yapılandırma sürücüsü üzerine metaveri saklayarak erişebilirsiniz. OpenStack metaveri servisi Amazon EC2 metaveri servisinin 2009-04-04 sürümüyle uyumlu olduğundan, kullanıcı verisini nasıl alacağınızla ilgili bilgi için Amazon EC2 Sunucu Metaverisini Kullanmak belgesine danışabilirsiniz.

Bu tür bir işlevselliği sağlamanın en kolay yolu imajınıza cloud-init paketini kurmaktır, bu da öntanımlı olarak kullanıcı verisini çalıştırılabilir betik olarak ele alır ve makine adını ayarlar.

İmajın önyükleme kaydını konsola yazdığından emin olun

İmajınızı çekirdeği önyükleme logunu ttyS0 aygıtına yazacak şekilde yapılandırmalısınız. Özellikle, önyükleme sırasında console=tty0 console=ttyS0,115200n8 değişkenleri çekirdeğe aktarılmalıdır.

İmajınız önyükleyici olarak grub2 kullanıyorsa, grub yapılandırma dosyasında bir satır bulunmalı. Örneğin /boot/grub/grub.cfg dosyasında şu şekilde bir şey:

linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=tty0 console=ttyS0,115200n8

console=tty0 console=ttyS0,115200n8 görünmezse, grub yapılandırmanızı değiştirmeniz gerekir. Genellikle grub.cfg dosyasını doğrudan düzenlememeniz gerekir, çünkü otomatik olarak üretilir. Bunun yerine /etc/default/grub dosyasını düzenlemeli ve GRUB_CMDLINE_LINUX_DEFAULT değişkeninin değerini değiştirmelisiniz:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"

Ardından grub yapılandırmasını güncelleyin. Ubuntu gibi Debian tabanlı işletim sistemlerinde, şu komutu çalıştırın:

# update-grub

RHEL ve CentOS gibi Fedora tabanlı sistemlerde ve openSUSE’de, şu komutu çalıştırın:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Çekirdekte yarı sanallaştırılmış Xen desteği (Yalnızca Xen hipervizörü)

3.0 sürümünden önceki Linux çekirdeklerinde, Linux çekirdeğinin ana dalı yarı sanallaştırılmış Xen sanal makineleri desteklemiyordu (Xen bunları DomU misafirleri olarak adlandırır). Xen hipervizörünü yarı sanallaştırmayla çalıştırıyorsanız, ve 3.0 çekirdeği önceskinde bir çekirdeğe sahip eski bir Linux dağıtımı için bir imaj oluşturacaksanız, imajın Xen desteği ile derlenmiş bir çekirdekle önyüklendiğinden emin olmalısınız.

İmaj önbelleğini yönetin

Kullanılmayan taban imajların /var/lib/nova/instances/_base/``de tutulup tutulmayacağını ya da ne kadar tutulacağını kontrol etmek için ``nova.conf dosyasındaki seçenekleri kullanın. Sunucuların canlı göçünü yapılandırdıysanız, tüm hesaplama düğümleriniz ortak bir /var/lib/nova/instances/ dizinini paylaşır.

OpenStack’deki libvirt imajlarıyla ilgili bilgi için, bknz Pádraig Brady’den bir OpenStack libvirt imajının yaşamı.

İmaj önbelleği yönetim yapılandırma seçenekleri

Yapılandırma seçeneği=Öntanımlı değer

(Tür) Açıklama

preallocate_images=none

(StrOpt) Sanal makine imajı ön ayırma kipi:

hiçbiri

Önden hiçbir depolama hazırlığı meydana gelmiyor.

boşluk

Depolama sunucu başlangıcında tamamen ayrılmış. $instance_dir/ imajları yeterli alanın var olup olmadığına anında karar vermek üzere fallocate edilmiş, ve muhtemel sanal makine I/O başarımını devam eden ayırmadan kaçınma sebebiyle artırmış, ve daha iyi yerel blok ayırma sağlanmış.

remove_unused_base_images=True

(BoolOpt) Kullanılmayan taban imajlar silinmeli mi? Doğru olarak ayarlandığında, aşağıdaki iki ayarla taban imajların silinme aralıkları ayarlanır. Yanlış olarak ayarlanırsa taban imajlar Hesaplama tarafından asla silinmez.

remove_unused_original_minimum_age_seconds=86400

(IntOpt) Bundan daha yeni kullanılmayan yeniden boyutlandırılmamış taban imajlar silinmez. Varsayılan 86400 saniyedir, yani 24 saat.

remove_unused_resized_minimum_age_seconds=3600

(IntOpt) Bundan daha yeni kullanılmayan yeniden boyutlandırılmış taban imajlar silinmez. Öntanımlı olarak 3600 saniyedir, yani bir saat.

Ayarların çalışan bir sunucunun silinmesini nasıl etkilediğini görmek için, imajları kaydedildiği dizini kontrol edin:

# ls -lash /var/lib/nova/instances/_base/

/var/log/compute/compute.log dosyasında tanımlayıcıya bakın:

2012-02-18 04:24:17 41389 WARNING nova.virt.libvirt.imagecache [-] Unknown base file: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3_20
2012-02-18 04:24:17 41389 INFO nova.virt.libvirt.imagecache [-] Removable base files: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3 /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3_20
2012-02-18 04:24:17 41389 INFO nova.virt.libvirt.imagecache [-] Removing base file: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3

remove_unused_original_minimum_age_seconds için öntanımlı değer 86400 saniye (24 saat) olduğundan, taban imajın silindiğini görmek için bu kadar saniye bekleyebilir, ya da nova.conf dosyasında aralığı daha kısa tutabilirsiniz. nova.conf dosyasında bir ayar değiştirdikten sonra tüm nova servislerini yeniden başlatın.