İ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 yarayangrowpart
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ı:
Diskte ek bir alan olup olmadığını tanımalı. Örneğin,
parted /dev/sda --script "print free"
çıktısını ayrıştırabilir.Ek alana sahip yeni bir LVM bölümü oluşturmalı. Örneğin, ‘’parted /dev/sda –script “mkpart lvm …”``.
Yeni bir fiziksel birim oluşturmalı. Örneğin,
pvcreate /dev/sda6
.Birim grubunu bu fiziksel bölümle genişletin. Örneğin,
vgextend vg00 /dev/sda6
.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
.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ı.
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:
|
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.