[ English | Indonesia | Deutsch | 日本語 ]
Operasi Menghadapi Pengguna¶
Panduan ini diperuntukkan bagi operator OpenStack dan tidak mencari referensi lengkap bagi pengguna, tetapi sebagai operator, Anda harus memiliki pemahaman dasar tentang cara menggunakan fasilitas cloud. Bab ini membahas tentang OpenStack dari perspektif pengguna dasar, yang membantu Anda memahami kebutuhan pengguna Anda dan menentukan, ketika Anda mendapatkan tiket masalah, apakah itu masalah pengguna atau masalah layanan. Konsep utama yang dicakup adalah images, flavors, security groups, block storage, shared file system storage, dan instances.
Images¶
Images OpenStack sering dapat dianggap sebagai "virtual machine templates.". Images juga bisa menjadi media instalasi standar seperti image ISO. Pada dasarnya, mereka berisi sistem file bootable yang digunakan untuk meluncurkan instance.
Menambahkan Images¶
Beberapa image pra-made ada dan dapat dengan mudah diimpor ke layanan Image. Image yang umum untuk ditambahkan adalah image CirrOS, yang sangat kecil dan digunakan untuk tujuan pengujian. Untuk menambahkan image ini, cukup lakukan:
$ wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
$ openstack image create --file cirros-0.3.5-x86_64-disk.img \
--public --container-format bare \
--disk-format qcow2 "cirros image"
Perintah openstack image create menyediakan sejumlah besar opsi untuk bekerja dengan image Anda. Sebagai contoh, opsi --min-disk berguna untuk image yang membutuhkan disket root dengan ukuran tertentu (misalnya, image Windows besar). Untuk melihat opsi ini, jalankan:
$ openstack help image create
Jalankan perintah berikut untuk melihat properti image yang ada:
$ openstack image show IMAGE_NAME_OR_UUID
Menambahkan Signed Images¶
Untuk memberikan rantai kepercayaan dari end user ke layanan Image, dan layanan Image untuk Compute, end user dapat mengimpor signed image yang pada awalnya dapat diverifikasi dalam layanan Image, dan kemudian diverifikasi dalam layanan Compute. Properti layanan Image yang tepat perlu diatur untuk mengaktifkan fitur signature ini.
Catatan
Sebelum langkah-langkah di bawah ini, asymmetric keypair dan certificate harus dibuat. Dalam contoh ini, masing-masing disebut private_key.pem dan new_cert.crt, dan keduanya berada di direktori saat ini. Perhatikan juga bahwa image dalam contoh ini adalah cirros-0.3.5-x86_64-disk.img, tetapi image apa pun dapat digunakan.
Berikut ini adalah langkah-langkah yang diperlukan untuk membuat signature yang digunakan untuk signed image:
Ambil image untuk diunggah
$ wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
Gunakan private key untuk membuat signature of image
Catatan
Nilai implisit berikut ini digunakan untuk membuat signature dalam contoh ini:
Metode hash signature = SHA-256
Jenis signature key = RSA-PSS
Catatan
Opsi berikut saat ini didukung:
Metode hash signature: SHA-224, SHA-256, SHA-384, and SHA-512
Jenis signature key: DSA, ECC_SECT571K1, ECC_SECT409K1, ECC_SECT571R1, ECC_SECT409R1, ECC_SECP521R1, ECC_SECP384R1, dan RSA-PSS
Hasilkan signature of imager dan mengubahnya menjadi representasi base64:
$ openssl dgst -sha256 -sign private_key.pem -sigopt rsa_padding_mode:pss \ -out image-file.signature cirros-0.3.5-x86_64-disk.img $ base64 -w 0 image-file.signature > signature_64 $ cat signature_64 'c4br5f3FYQV6Nu20cRUSnx75R/VcW3diQdsUN2nhPw+UcQRDoGx92hwMgRxzFYeUyydRTWCcUS2ZLudPR9X7rM THFInA54Zj1TwEIbJTkHwlqbWBMU4+k5IUIjXxHO6RuH3Z5f/SlSt7ajsNVXaIclWqIw5YvEkgXTIEuDPE+C4='
Catatan
Menggunakan Image API v1 memerlukan '-w 0' di atas, karena properti image multiline tidak didukung.
Image API v2 mendukung properti multiline, jadi opsi ini tidak diperlukan untuk v2 tetapi masih dapat digunakan.
Buat konteks
$ python >>> from keystoneclient.v3 import client >>> keystone_client = client.Client(username='demo', user_domain_name='Default', password='password', project_name='demo', auth_url='http://localhost:5000/v3') >>> from oslo_context import context >>> context = context.RequestContext(auth_token=keystone_client.auth_token, tenant=keystone_client.project_id)
Encode sertifikat dalam format DER
>>> from cryptography import x509 as cryptography_x509 >>> from cryptography.hazmat import backends >>> from cryptography.hazmat.primitives import serialization >>> with open("new_cert.crt", "rb") as cert_file: >>> cert = cryptography_x509.load_pem_x509_certificate( cert_file.read(), backend=backends.default_backend() ) >>> certificate_der = cert.public_bytes(encoding=serialization.Encoding.DER)
Unggah Sertifikat dalam format DER ke Castellan
>>> from castellan.common.objects import x_509 >>> from castellan import key_manager >>> castellan_cert = x_509.X509(certificate_der) >>> key_API = key_manager.API() >>> cert_uuid = key_API.store(context, castellan_cert) >>> cert_uuid u'62a33f41-f061-44ba-9a69-4fc247d3bfce'
Unggah Image ke layanan Image, dengan Signature Metadata
Catatan
Properti signature berikut digunakan:
img_signature menggunakan signature yang disebut signature_64
img_signature_certificate_uuid menggunakan nilai dari cert_uuid di bagian 5 di atas
img_signature_hash_method cocok dengan 'SHA-256' di bagian 2 di atas
img_signature_key_type cocok dengan 'RSA-PSS' di bagian 2 di atas
$ . openrc demo $ export OS_IMAGE_API_VERSION=2 $ openstack image create --property name=cirrosSignedImage_goodSignature \ --property is-public=true --container-format bare --disk-format qcow2 \ --property img_signature='c4br5f3FYQV6Nu20cRUSnx75R/VcW3diQdsUN2nhPw+UcQRDoGx92hwMgRxzFYeUyydRTWCcUS2ZLudPR9X7rMTHFInA54Zj1TwEIbJTkHwlqbWBMU4+k5IUIjXxHO6RuH3Z5fSlSt7ajsNVXaIclWqIw5YvEkgXTIEuDPE+C4=' \ --property img_signature_certificate_uuid='62a33f41-f061-44ba-9a69-4fc247d3bfce' \ --property img_signature_hash_method='SHA-256' \ --property img_signature_key_type='RSA-PSS' < ~/cirros-0.3.5-x86_64-disk.img
Catatan
Batas karakter image signature maksimum adalah 255.
Verifikasi URL Keystone
Catatan
Konfigurasi Keystone default mengasumsikan Keystone ada di host lokal, dan menggunakan
http://localhost:5000/v3sebagai URL endpoint, yang ditentukan dalamglance-api.confdanfile nova-api.conf:[barbican] auth_endpoint = http://localhost:5000/v3
Catatan
Jika Keystone terletak dari jarak jauh, edit file
glance-api.confdannova.conf. Di bagian[barbican] ``, konfigurasikan opsi ``auth_endpoint:[barbican] auth_endpoint = https://192.168.245.9:5000/v3
Verifikasi signature akan terjadi ketika Compute mem-boot signed image
Catatan
server nova-compute terlebih dahulu perlu diperbarui dengan langkah-langkah berikut:
Pastikan cryptsetup diinstal, dan pastikan bahwa
pythin-barbicanclientPython package diinstalAtur layanan Key Manager dengan mengedit /etc/nova/nova.conf dan menambahkan entri di codeblock di bawah ini
Flag verifikasi_glance_signatures memungkinkan Compute untuk secara otomatis memvalidasi signed instance sebelum diluncurkan. Fitur validasi ini diaktifkan ketika nilainya diatur ke TRUE
[key_manager] api_class = castellan.key_manager.barbican_key_manager.BarbicanKeyManager [glance] verify_glance_signatures = TRUE
Catatan
api_class [keymgr] sudah tidak digunakan lagi oleh Newton, jadi tidak boleh disertakan dalam rilis ini atau lebih.
Menghapus Image¶
Untuk menghapus image, cukup jalankan:
$ openstack image delete IMAGE_NAME_OR_UUID
Hati-hati
Secara umum, menghapus image tidak memengaruhi instance atau snapshot yang didasarkan pada image. Namun, beberapa driver mungkin memerlukan image asli untuk hadir untuk melakukan migrasi. Misalnya, migrasi langsung XenAPI akan berfungsi dengan baik jika image dihapus, tetapi libvirt akan gagal.
Opsi CLI lainnya¶
Set lengkap opsi dapat ditemukan menggunakan:
$ glance help
Layanan Image dan Basis Data¶
Satu-satunya layanan Image tidak menyimpan dalam basis data adalah image itu sendiri. Basis data layanan image memiliki dua tabel utama:
imagesimage_properties
Bekerja secara langsung dengan database dan kueri SQL dapat memberi Anda daftar dan laporan khusus dari image. Secara teknis, Anda dapat memperbarui properti tentang image melalui database, meskipun ini umumnya tidak disarankan.
Contoh Database Queries layanan Image¶
Salah satu contoh menarik adalah memodifikasi tabel image dan pemilik image itu. Ini dapat dengan mudah dilakukan jika Anda hanya menampilkan ID unik pemiliknya. Contoh ini melangkah lebih jauh dan menampilkan nama pemilik yang dapat dibaca:
mysql> select glance.images.id,
glance.images.name, keystone.tenant.name, is_public from
glance.images inner join keystone.tenant on
glance.images.owner=keystone.tenant.id;
Contoh lain adalah menampilkan semua properti untuk image tertentu:
mysql> select name, value from
image_properties where id = <image_id>
Flavors¶
Template perangkat keras virtual disebut "flavors" di OpenStack, yang menentukan ukuran untuk RAM, disk, jumlah core, dan sebagainya. Instalasi default menyediakan lima flavor.
Ini dapat dikonfigurasi oleh pengguna admin (hak juga dapat didelegasikan kepada pengguna lain dengan mendefinisikan kembali kontrol akses untuk compute_extension: flavormanage di /etc/nova/policy.json pada ``nova-api` `server). Untuk mendapatkan daftar flavor yang tersedia di sistem Anda, jalankan:
$ openstack flavor list
+----+-----------+-------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+----+-----------+-------+------+-----------+-------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | 1 | True |
| 2 | m1.small | 2048 | 20 | 0 | 1 | True |
| 3 | m1.medium | 4096 | 40 | 0 | 2 | True |
| 4 | m1.large | 8192 | 80 | 0 | 4 | True |
| 5 | m1.xlarge | 16384 | 160 | 0 | 8 | True |
+----+-----------+-------+------+-----------+-------+-----------+
Perintah openstack flavour create memungkinkan pengguna yang berwenang untuk membuat flavor baru. Perintah manipulasi flavor tambahan dapat ditunjukkan dengan perintah berikut:
$ openstack help | grep flavor
Flavour menentukan sejumlah parameter, sehingga pengguna memiliki pilihan jenis mesin virtual apa yang akan dijalankan — seperti yang akan mereka miliki jika mereka membeli server fisik. :ref: table_flavor_params mencantumkan elemen yang dapat diatur. Catatan khususnya extra_specs, yang dapat digunakan untuk mendefinisikan karakteristik bentuk bebas, memberikan banyak fleksibilitas di luar ukuran RAM, CPU, dan Disk.
Column |
Description |
|---|---|
ID |
ID unik (integer atau UUID) untuk flavor. |
Name |
Nama deskriptif, seperti xx.size_name, adalah konvensional tetapi tidak diperlukan, meskipun beberapa alat pihak ketiga mungkin bergantung padanya. |
Memory_MB |
Memori mesin virtual dalam megabytes. |
Disk |
Ukuran disk root virtual dalam gigabytes. Ini adalah cakram ephemeral tempat image dasar disalin. Anda tidak menggunakannya saat Anda boot dari volume persisten. Ukuran "0" adalah kasus khusus yang menggunakan ukuran image dasar asli (native base image size) sebagai ukuran volume root ephemeral. |
Ephemeral |
Menentukan ukuran disk data sementara sekunder. Ini adalah disk kosong yang tidak diformat dan hanya ada selama masa pakai instance. |
Swap |
Alokasi ruang swap opsional untuk instance. |
VCPU |
Jumlah CPU virtual disajikan ke instance. |
RXTX_Factor |
Properti opsional yang memungkinkan server yang dibuat memiliki batas bandwidth yang berbeda dari yang ditentukan dalam jaringan yang dilampirkan. Faktor ini dikalikan dengan properti rxtx_base dari jaringan. Nilai default adalah 1.0 (yaitu, sama dengan jaringan yang terpasang). |
Is_Public |
Nilai Boolean yang menunjukkan apakah flavor tersedia untuk semua pengguna atau pribadi. Flavors pribadi tidak membuat penyewa saat ini ditugaskan untuk mereka. Default ke ``True ``. |
extra_specs |
Pembatasan opsional tambahan di mana node komputasi flavor dapat berjalan. Ini diimplementasikan sebagai pasangan nilai kunci yang harus cocok dengan pasangan nilai kunci yang sesuai pada node komputasi. Dapat digunakan untuk mengimplementasikan hal-hal seperti sumber daya khusus (seperti flavor yang hanya dapat berjalan pada komputasi node dengan perangkat keras GPU). |
Private Flavors¶
Seorang pengguna mungkin membutuhkan flavor khusus yang disesuaikan secara unik untuk proyek yang sedang dikerjakannya. Misalnya, pengguna mungkin membutuhkan memori 128 GB. Jika Anda membuat flavor baru seperti dijelaskan di atas, pengguna akan memiliki akses ke flavor kustom, tetapi demikian juga semua penyewa lain di cloud Anda. Terkadang berbagi ini tidak diinginkan. Dalam skenario ini, memungkinkan semua pengguna memiliki akses ke flavor dengan memori 128 GB dapat menyebabkan cloud Anda mencapai kapasitas penuh dengan sangat cepat. Untuk mencegah hal ini, Anda dapat membatasi akses ke flavor kustom menggunakan perintah nova flavor-access-add :
$ nova flavor-access-add FLAVOR_ID PROJECT_ID
Untuk melihat daftar akses flavor, lakukan hal berikut:
$ nova flavor-access-list [--flavor FLAVOR_ID]
Tip
Setelah akses ke flavor telah dibatasi, tidak ada proyek lain selain yang diberikan akses eksplisit akan dapat melihat flavor. Ini termasuk proyek admin. Pastikan untuk menambahkan proyek admin di samping proyek asli.
Ini juga membantu untuk mengalokasikan rentang numerik tertentu untuk flavor kustom dan pribadi. Pada sistem berbasis UNIX, akun nonsistem biasanya memiliki UID mulai dari 500. Pendekatan serupa dapat diambil dengan flavor khusus. Ini membantu Anda dengan mudah mengidentifikasi flavor mana yang khusus, pribadi, dan publik untuk keseluruhan cloud.
Bagaimana Saya Memodifikasi Flavor yang Ada?¶
Dashboard OpenStack mensimulasikan kemampuan untuk memodifikasi flavor dengan menghapus flavor yang ada dan membuat yang baru dengan nama yang sama.
Grup Keamanan¶
Masalah umum pengguna baru dengan OpenStack gagal untuk mengatur grup keamanan yang tepat ketika meluncurkan sebuah instance. Akibatnya, pengguna tidak dapat menghubungi instance di jaringan.
Grup keamanan adalah sekumpulan aturan filter IP yang diterapkan pada jaringan instance. Mereka spesifik proyek, dan anggota proyek dapat mengedit aturan default untuk grup mereka dan menambahkan set aturan baru. Semua proyek memiliki grup keamanan "default", yang diterapkan pada instance yang tidak memiliki grup keamanan lain yang ditentukan. Kecuali diubah, grup keamanan ini menolak semua lalu lintas masuk.
Tip
Seperti disebutkan dalam bab sebelumnya, jumlah aturan per grup keamanan dikendalikan oleh quota_security_group_rules, dan jumlah grup keamanan yang diizinkan per proyek dikontrol oleh kuota quota_security_groups.
Konfigurasi Kelompok Keamanan End-User¶
Grup keamanan untuk proyek saat ini dapat ditemukan di dashboard OpenStack di bawah Access & Security. Untuk melihat detail grup yang ada, pilih tindakan Edit Grup Keamanan untuk grup keamanan itu. Jelas, memodifikasi grup yang ada dapat dilakukan dari antarmuka edit ini. Ada tombol Create Security Group pada halaman utama Access & Security untuk membuat grup baru. Kami membahas istilah yang digunakan dalam field ini ketika kami menjelaskan padanan baris perintah (command-line equivalent).
Setting with openstack command
Jika lingkungan Anda menggunakan Neutron, Anda dapat mengonfigurasi pengaturan grup keamanan menggunakan perintah openstack. Dapatkan daftar grup keamanan untuk proyek tempat Anda bertindak, dengan menggunakan perintah berikut:
$ openstack security group list
+------------------------+---------+------------------------+-------------------------+
| ID | Name | Description | Project |
+------------------------+---------+------------------------+-------------------------+
| 3bef30ed-442d-4cf1 | default | Default security group | 35e3820f7490493ca9e3a5e |
| -b84d-2ba50a395599 | | | 685393298 |
| aaf1d0b7-98a0-41a3-ae1 | default | Default security group | 32e9707393c34364923edf8 |
| 6-a58b94503289 | | | f5029cbfe |
+------------------------+---------+------------------------+-------------------------+
Untuk melihat detail grup keamanan:
$ openstack security group show 3bef30ed-442d-4cf1-b84d-2ba50a395599
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2016-11-08T21:55:19Z |
| description | Default security group |
| id | 3bef30ed-442d-4cf1-b84d-2ba50a395599 |
| name | default |
| project_id | 35e3820f7490493ca9e3a5e685393298 |
| project_id | 35e3820f7490493ca9e3a5e685393298 |
| revision_number | 1 |
| rules | created_at='2016-11-08T21:55:19Z', direction='egress', ethertype='IPv6', id='1dca4cac-d4f2-46f5-b757-d53c01a87bdf', project_id='35e3820f7490493ca9e3a5e685393298', |
| | revision_number='1', updated_at='2016-11-08T21:55:19Z' |
| | created_at='2016-11-08T21:55:19Z', direction='egress', ethertype='IPv4', id='2d83d6f2-424e-4b7c-b9c4-1ede89c00aab', project_id='35e3820f7490493ca9e3a5e685393298', |
| | revision_number='1', updated_at='2016-11-08T21:55:19Z' |
| | created_at='2016-11-08T21:55:19Z', direction='ingress', ethertype='IPv4', id='62b7d1eb-b98d-4707-a29f-6df379afdbaa', project_id='35e3820f7490493ca9e3a5e685393298', remote_group_id |
| | ='3bef30ed-442d-4cf1-b84d-2ba50a395599', revision_number='1', updated_at='2016-11-08T21:55:19Z' |
| | created_at='2016-11-08T21:55:19Z', direction='ingress', ethertype='IPv6', id='f0d4b8d6-32d4-4f93-813d-3ede9d698fbb', project_id='35e3820f7490493ca9e3a5e685393298', remote_group_id |
| | ='3bef30ed-442d-4cf1-b84d-2ba50a395599', revision_number='1', updated_at='2016-11-08T21:55:19Z' |
| updated_at | 2016-11-08T21:55:19Z |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Aturan-aturan ini semua aturan jenis "allow" , karena standarnya ditolak. Contoh ini menunjukkan kisaran port lengkap untuk semua protokol yang diizinkan dari semua IP. Bagian ini menjelaskan parameter aturan grup keamanan yang paling umum:
- direction
Arah penerapan aturan grup keamanan. Nilai yang valid adalah
ingressatauegress.- remote_ip_prefix
Nilai atribut ini cocok dengan awalan IP yang ditentukan sebagai alamat IP sumber dari paket IP.
- protocol
Protokol yang dicocokkan dengan aturan grup keamanan. Nilai yang valid adalah
null,tcp,udp,icmp, danicmpv6.- port_range_min
Nomor port minimum dalam rentang yang cocok dengan aturan grup keamanan. Jika protokolnya adalah TCP atau UDP, nilai ini harus kurang dari atau sama dengan nilai atribut
port_range_max. Jika protokolnya adalah ICMP atau ICMPv6, nilai ini harus masing-masing merupakan tipe ICMP atau ICMPv6.- port_range_max
Nomor port maksimum dalam rentang yang cocok dengan aturan grup keamanan. Atribut
port_range_minmembatasi atributport_range_max. Jika protokolnya adalah ICMP atau ICMPv6, nilai ini harus masing-masing merupakan tipe ICMP atau ICMPv6.- ethertype
Harus
IPv4atauIPv6, dan alamat yang diwakili dalam CIDR harus cocok dengan aturan ingress atau egress.
Saat menambahkan grup keamanan baru, Anda harus memilih nama yang deskriptif tapi singkat. Nama ini muncul dalam deskripsi singkat tentang contoh yang menggunakannya di mana bidang deskripsi yang lebih panjang sering tidak. Melihat sebuah instance menggunakan grup keamanan http lebih mudah dipahami daripada bobs_group atau secgrp1.
Contoh ini membuat grup keamanan yang memungkinkan lalu lintas web di mana saja di Internet. Kami akan menyebut grup ini global_http, yang jelas dan cukup ringkas, merangkum apa yang diizinkan dan dari mana. Dari command line, lakukan:
$ openstack security group create global_http --description "allow web traffic from the Internet"
Created a new security_group:
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2016-11-10T16:09:18Z |
| description | allow web traffic from the Internet |
| headers | |
| id | 70675447-1b92-4102-a7ea-6a3ca99d2290 |
| name | global_http |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| revision_number | 1 |
| rules | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv4', id='e440b13a-e74f-4700-a36f-9ecc0de76612', project_id='32e9707393c34364923edf8f5029cbfe', |
| | revision_number='1', updated_at='2016-11-10T16:09:18Z' |
| | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv6', id='0debf8cb-9f1d-45e5-98db-ee169c0715fe', project_id='32e9707393c34364923edf8f5029cbfe', |
| | revision_number='1', updated_at='2016-11-10T16:09:18Z' |
| updated_at | 2016-11-10T16:09:18Z |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Segera setelah dibuat, grup keamanan hanya memiliki aturan egress yang diizinkan. Untuk membuatnya melakukan apa yang kita inginkan, kita perlu menambahkan beberapa aturan:
$ openstack security group rule create --help
usage: openstack security group rule create [-h]
[-f {json,shell,table,value,yaml}]
[-c COLUMN]
[--max-width <integer>]
[--noindent] [--prefix PREFIX]
[--remote-ip <ip-address> | --remote-group <group>]
[--dst-port <port-range>]
[--icmp-type <icmp-type>]
[--icmp-code <icmp-code>]
[--protocol <protocol>]
[--ingress | --egress]
[--ethertype <ethertype>]
[--project <project>]
[--project-domain <project-domain>]
<group>
$ openstack security group rule create --ingress --ethertype IPv4 \
--protocol tcp --remote-ip 0.0.0.0/0 global_http
Created a new security group rule:
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| created_at | 2016-11-10T16:12:27Z |
| description | |
| direction | ingress |
| ethertype | IPv4 |
| headers | |
| id | 694d30b1-1c4d-4bb8-acbe-7f1b3de2b20f |
| port_range_max | None |
| port_range_min | None |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| protocol | tcp |
| remote_group_id | None |
| remote_ip_prefix | 0.0.0.0/0 |
| revision_number | 1 |
| security_group_id | 70675447-1b92-4102-a7ea-6a3ca99d2290 |
| updated_at | 2016-11-10T16:12:27Z |
+-------------------+--------------------------------------+
Meskipun hanya mengeluarkan aturan yang baru ditambahkan, operasi ini aditif:
$ openstack security group show global_http
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2016-11-10T16:09:18Z |
| description | allow web traffic from the Internet |
| id | 70675447-1b92-4102-a7ea-6a3ca99d2290 |
| name | global_http |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| revision_number | 2 |
| rules | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv6', id='0debf8cb-9f1d-45e5-98db-ee169c0715fe', project_id='32e9707393c34364923edf8f5029cbfe', |
| | revision_number='1', updated_at='2016-11-10T16:09:18Z' |
| | created_at='2016-11-10T16:12:27Z', direction='ingress', ethertype='IPv4', id='694d30b1-1c4d-4bb8-acbe-7f1b3de2b20f', project_id='32e9707393c34364923edf8f5029cbfe', protocol='tcp', |
| | remote_ip_prefix='0.0.0.0/0', revision_number='1', updated_at='2016-11-10T16:12:27Z' |
| | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv4', id='e440b13a-e74f-4700-a36f-9ecc0de76612', project_id='32e9707393c34364923edf8f5029cbfe', |
| | revision_number='1', updated_at='2016-11-10T16:09:18Z' |
| updated_at | 2016-11-10T16:12:27Z |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Operasi terbalik disebut openstack security group rule delete, yang menentukan ID aturan grup keamanan. Seluruh grup keamanan dapat dihapus dengan openstack security group delete.
Untuk membuat aturan grup keamanan untuk sekelompok instance, gunakan RemoteGroups.
RemoteGroup adalah cara dinamis untuk mendefinisikan CIDR dari sumber yang diizinkan. Pengguna menentukan RemoteGroup (nama grup keamanan) dan kemudian semua instance pengguna yang menggunakan RemoteGroup yang ditentukan dipilih secara dinamis. Seleksi dinamis ini mengurangi kebutuhan akan aturan individual untuk memungkinkan setiap anggota baru cluster.
Kode ini mirip dengan contoh di atas dari :command: openstack security group rule create. Untuk menggunakan RemoteGroup, tentukan --remote-group daripada --remote-ip. Sebagai contoh:
$ openstack security group rule create --ingress \
--ethertype IPv4 --protocol tcp \
--remote-group global_http cluster
Aturan "cluster" memungkinkan akses SSH dari setiap instance lain yang menggunakan grup global-http.
Block Storage¶
Volume OpenStack adalah perangkat penyimpanan blok persisten yang dapat dilampirkan dan dilepaskan dari instance, tetapi mereka dapat dilampirkan hanya pada satu instance pada satu waktu. Mirip dengan hard drive eksternal, mereka tidak menyediakan penyimpanan bersama seperti sistem file jaringan atau penyimpanan objek. Itu diserahkan ke sistem operasi dalam instance untuk menempatkan sistem file pada perangkat blok dan me-mount-nya, atau tidak.
Seperti halnya teknologi removable disk lainnya, penting agar sistem operasi tidak mencoba memanfaatkan disk sebelum melepasnya. Pada instance Linux, ini biasanya melibatkan unmount sistem file yang dipasang dari volume. Layanan volume OpenStack tidak dapat memastikan apakah aman untuk menghapus volume dari sebuah instance, sehingga ia melakukan apa yang diperintahkan. Jika pengguna memberi tahu layanan volume untuk melepaskan volume dari instance saat sedang ditulis, Anda dapat mengharapkan beberapa tingkat kerusakan sistem file serta kesalahan dari proses apa pun dalam instance yang menggunakan perangkat.
Tidak ada yang spesifik dengan OpenStack untuk mengetahui langkah-langkah yang diperlukan untuk mengakses perangkat blok dari dalam sistem operasi instance, berpotensi memformatnya untuk penggunaan pertama dan berhati-hati saat melepaskannya. Yang spesifik adalah bagaimana membuat volume baru dan melampirkan dan melepaskannya dari instance. Semua operasi ini dapat dilakukan dari halaman Volumes dashboard atau dengan menggunakan klien command-line openstack.
Untuk menambahkan volume baru, Anda hanya perlu ukuran volume dalam gigabyte. Masukkan ini ke formulir web Create Volume atau gunakan command line:
$ openstack volume create volume1 --size 10
Ini menghasilkan volume 10 GB. Untuk membuat daftar volume yang ada dan instance yang terhubung, jika ada:
$ openstack volume list
+--------------------------------------+--------------+--------+------+-------------+
| ID | Display Name | Status | Size | Attached to |
+--------------------------------------+--------------+--------+------+-------------+
| 6cf4114a-56b2-476b-acf7-7359d8334aa2 | volume1 | error | 10 | |
+--------------------------------------+--------------+--------+------+-------------+
OpenStack Block Storage juga memungkinkan membuat snapshot volume. Ingat bahwa ini adalah snapshot level blok yang konsisten dengan gangguan, jadi yang terbaik adalah jika volume tidak terhubung ke instance ketika snapshot diambil dan terbaik kedua jika volume tidak digunakan pada instance yang dilampirkan. Jika volumenya sedang digunakan, snapshot mungkin memiliki sistem file yang tidak konsisten. Bahkan, secara default, layanan volume tidak mengambil snapshot dari volume yang dilampirkan pada image, meskipun itu bisa dipaksa. Untuk mengambil snapshot volume, pilih Create Snapshot dari kolom tindakan di sebelah nama volume pada halaman dashboard Volumes , atau jalankan ini dari command line:
$ openstack help snapshot create
usage: openstack snapshot create [-h] [-f {json,shell,table,value,yaml}]
[-c COLUMN] [--max-width <integer>]
[--noindent] [--prefix PREFIX]
[--name <name>] [--description <description>]
[--force] [--property <key=value>]
<volume>
Create new snapshot
positional arguments:
<volume> Volume to snapshot (name or ID)
optional arguments:
-h, --help show this help message and exit
--name <name> Name of the snapshot
--description <description>
Description of the snapshot
--force Create a snapshot attached to an instance. Default is
False
--property <key=value>
Set a property to this snapshot (repeat option to set
multiple properties)
output formatters:
output formatter options
-f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml}
the output format, defaults to table
-c COLUMN, --column COLUMN
specify the column(s) to include, can be repeated
table formatter:
--max-width <integer>
Maximum display width, <1 to disable. You can also use
the CLIFF_MAX_TERM_WIDTH environment variable, but the
parameter takes precedence.
json formatter:
--noindent whether to disable indenting the JSON
shell formatter:
a format a UNIX shell can parse (variable="value")
--prefix PREFIX add a prefix to all variable names
Catatan
Untuk informasi lebih lanjut tentang memperbarui volume Block Storage (misalnya, mengubah ukuran atau mentransfer), lihat OpenStack End User Guide.
Kegagalan Pembuatan Block Storage¶
Jika pengguna mencoba membuat volume dan volume segera masuk ke status kesalahan, cara terbaik untuk memecahkan masalah adalah dengan mengambil file log cinder untuk UUID volume. Pertama-tama coba file log pada pengontrol cloud, dan kemudian coba node penyimpanan tempat volume dicoba dibuat:
# grep 903b85d0-bacc-4855-a261-10843fc2d65b /var/log/cinder/*.log
Instance¶
Instance adalah mesin virtual yang berjalan di dalam cloud OpenStack. Bagian ini membahas cara bekerja dengan mereka dan image yang mendasarinya, properti jaringan mereka, dan bagaimana mereka diwakili dalam database.
Memulai Instance¶
Untuk meluncurkan sebuah instance, Anda perlu memilih image, flavor, dan nama. Nama tidak harus unik, tetapi hidup Anda akan lebih sederhana jika itu karena banyak alat akan menggunakan nama di tempat UUID selama namanya unik. Anda dapat memulai instance dari dashboard dari tombol Launch Instance pada halaman Instances atau dengan memilih aksi :guilabel: Launch di sebelah image atau snapshot pada halaman Images.
Di command line, lakukan ini:
$ openstack server create --flavor FLAVOR --image IMAGE_NAME_OR_ID
Ada sejumlah item opsional yang dapat ditentukan. Anda harus membaca sisa bagian ini sebelum mencoba memulai sebuah instance, tetapi ini adalah perintah dasar yang kemudian menjadi detail.
Untuk menghapus instance dari dasbor, pilih tindakan Delete Instance ` di sebelah instance pada halaman Instances.
Catatan
Dalam rilis sebelum Mitaka, pilih yang setara tindakan Terminate instance.
Dari command line, lakukan ini:
$ openstack server delete INSTANCE_ID
Penting untuk dicatat bahwa mematikan sebuah instance tidak menghentikannya dalam arti OpenStack.
Kegagalan Boot Instance¶
Jika sebuah instance gagal memulai dan segera pindah ke status kesalahan, ada beberapa cara berbeda untuk melacak apa yang salah. Beberapa di antaranya dapat dilakukan dengan akses pengguna normal, sementara yang lain memerlukan akses ke server log Anda atau komputasi node.
Alasan paling sederhana mengapa node gagal diluncurkan adalah pelanggaran kuota atau penjadwal tidak dapat menemukan node komputasi yang cocok untuk menjalankan instance. Dalam kasus ini, kesalahan terlihat ketika Anda menjalankan openstack server show pada instance yang salah:
$ openstack server show test-instance
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
| OS-DCF:diskConfig | AUTO |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | None |
| OS-EXT-SRV-ATTR:hypervisor_hostname | None |
| OS-EXT-SRV-ATTR:instance_name | instance-0000000a |
| OS-EXT-STS:power_state | NOSTATE |
| OS-EXT-STS:task_state | None |
| OS-EXT-STS:vm_state | error |
| OS-SRV-USG:launched_at | None |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | |
| config_drive | |
| created | 2016-11-23T07:51:53Z |
| fault | {u'message': u'Build of instance 6ec42311-a121-4887-aece-48fb93a4a098 aborted: Failed to allocate the network(s), not rescheduling.', |
| | u'code': 500, u'details': u' File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1779, in |
| | _do_build_and_run_instance\n filter_properties)\n File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1960, in |
| | _build_and_run_instance\n reason=msg)\n', u'created': u'2016-11-23T07:57:04Z'} |
| flavor | m1.tiny (1) |
| hostId | |
| id | 6ec42311-a121-4887-aece-48fb93a4a098 |
| image | cirros (9fef3b2d-c35d-4b61-bea8-09cc6dc41829) |
| key_name | None |
| name | test-instance |
| os-extended-volumes:volumes_attached | [] |
| project_id | 5669caad86a04256994cdf755df4d3c1 |
| properties | |
| status | ERROR |
| updated | 2016-11-23T07:57:04Z |
| user_id | c36cec73b0e44876a4478b1e6cd749bb |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
Dalam hal ini, melihat pesan fault `` menunjukkan ``NoValidHost, yang menunjukkan bahwa penjadwal tidak dapat mencocokkan persyaratan instance.
Jika openstack server show tidak cukup menjelaskan kegagalan, mencari instance UUID di nova-compute.log pada node komputasi yang telah dijadwalkan atau nova-scheduler.log pada host penjadwal Anda adalah tempat yang baik untuk mulai mencari masalah tingkat rendah.
Menggunakan openstack server show sebagai pengguna admin akan menunjukkan node komputasi tempat instance dijadwalkan sebagai hostId. Jika instance gagal selama penjadwalan, field ini blank.
Menggunakan Data Instance-Specific¶
Ada dua jenis utama data instance-specific: metadata dan data pengguna.
Instance metadata¶
Untuk Compute, instance metadata adalah kumpulan pasangan nilai kunci yang terkait dengan sebuah instance. Compute membaca dan menulis ke pasangan nilai kunci ini kapan saja selama masa instance, dari dalam dan luar instance, ketika pengguna akhir menggunakan Compute API untuk melakukannya. Namun, Anda tidak dapat meminta pasangan nilai kunci yang terkait dengan instance dengan layanan metadata yang kompatibel dengan layanan metadata Amazon EC2.
Sebagai contoh metadata instance, pengguna dapat membuat dan mendaftarkan kunci SSH menggunakan perintah openstack keypair create :
$ openstack keypair create mykey > mykey.pem
Ini menciptakan kunci bernama mykey, yang dapat Anda kaitkan dengan instance. File mykey.pem adalah kunci pribadi, yang harus disimpan ke lokasi yang aman karena memungkinkan akses root ke instance yang terkait dengan kunci mykey.
Gunakan perintah ini untuk mendaftarkan kunci yang ada dengan OpenStack:
$ openstack keypair create --public-key mykey.pub mykey
Catatan
Anda harus memiliki kunci pribadi yang cocok untuk mengakses instance yang terkait dengan kunci ini.
Untuk mengaitkan kunci dengan instance saat boot, tambahkan --key-name mykey ke command line Anda. Sebagai contoh:
$ openstack server create --image ubuntu-cloudimage --flavor 2 \
--key-name mykey myimage
Saat mem-boot server, Anda juga dapat menambahkan metadata secara acak (arbitrary) sehingga Anda dapat lebih mudah mengidentifikasinya di antara instance yang sedang berjalan. Gunakan opsi --property dengan pasangan nilai-kunci, di mana Anda dapat membuat string untuk kunci dan nilainya. Misalnya, Anda dapat menambahkan deskripsi dan juga pembuat server:
$ openstack server create --image=test-image --flavor=1 \
--property description='Small test image' smallimage
Saat melihat informasi server, Anda dapat melihat metadata yang disertakan pada baris metadata:
$ openstack server show smallimage
+--------------------------------------+----------------------------------------------------------+
| Field | Value |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | rdo-newton.novalocal |
| OS-EXT-SRV-ATTR:hypervisor_hostname | rdo-newton.novalocal |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |
| OS-EXT-STS:power_state | Running |
| OS-EXT-STS:task_state | None |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2016-12-07T11:20:08.000000 |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | public=172.24.4.227 |
| config_drive | |
| created | 2016-12-07T11:17:44Z |
| flavor | m1.tiny (1) |
| hostId | aca973d5b7981faaf8c713a0130713bbc1e64151be65c8dfb53039f7 |
| id | 4f7c6b2c-f27e-4ccd-a606-6bfc9d7c0d91 |
| image | cirros (01bcb649-45d7-4e3d-8a58-1fcc87816907) |
| key_name | None |
| name | smallimage |
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| project_id | 2daf82a578e9437cab396c888ff0ca57 |
| properties | description='Small test image' |
| security_groups | [{u'name': u'default'}] |
| status | ACTIVE |
| updated | 2016-12-07T11:20:08Z |
| user_id | 8cbea24666ae49bbb8c1641f9b12d2d2 |
+--------------------------------------+----------------------------------------------------------+
Instance data pengguna¶
Kunci user-data adalah kunci khusus dalam layanan metadata yang menyimpan file dimana aplikasi cloud-aware dalam guest instance dapat mengakses. Sebagai contoh, cloudinit <https://help.ubuntu.com/community/CloudInit> __ adalah paket open source dari Ubuntu, tetapi tersedia di sebagian besar distribusi, yang menangani inisialisasi awal instance cloud yang memanfaatkan pengguna ini data.
Data pengguna ini dapat dimasukkan ke dalam file di sistem lokal Anda dan kemudian diteruskan saat pembuatan dengan flag --user-data <user-data-file>.
Sebagai contoh
$ openstack server create --image ubuntu-cloudimage --flavor 1 \
--user-data mydata.file mydatainstance
Untuk memahami perbedaan antara data pengguna dan metadata, sadari bahwa data pengguna dibuat sebelum instance dimulai. Data pengguna dapat diakses dari dalam instance ketika sedang berjalan. Data pengguna dapat digunakan untuk menyimpan konfigurasi, skrip, atau apa pun yang diinginkan penyewa.
Injeksi file¶
File lokal apaun juga dapat ditempatkan ke dalam sistem file instance pada waktu pembuatan dengan menggunakan opsi ``--file <dst-path = src-path> ``. Anda dapat menyimpan hingga lima file.
Sebagai contoh, katakanlah Anda memiliki file khusus authorized_keys bernama special_authorized_keysfile yang karena alasan tertentu Anda ingin menggunakan instance daripada menggunakan injeksi kunci SSH biasa. Dalam hal ini, Anda dapat menggunakan perintah berikut:
$ openstack server create --image ubuntu-cloudimage --flavor 1 \
--file /root/.ssh/authorized_keys=special_authorized_keysfile \
authkeyinstance
Mengaitkan Grup Keamanan¶
Grup keamanan, seperti yang dibahas sebelumnya, biasanya diperlukan untuk memungkinkan lalu lintas jaringan menjadi sebuah instance, kecuali grup keamanan default untuk suatu proyek telah dimodifikasi agar lebih permisif.
Menambahkan grup keamanan biasanya dilakukan saat boot misalnya. Ketika meluncurkan dari dashboard, Anda melakukan ini pada tab Access & Security pada dialog Launch Instance.
Dimungkinkan juga untuk menambah dan menghapus grup keamanan saat instance sedang berjalan. Saat ini ini hanya tersedia melalui alat command-line. Berikut ini sebuah contoh:
$ openstack server add security group SERVER SECURITY_GROUP_NAME_OR_ID
$ openstack server remove security group SERVER SECURITY_GROUP_NAME_OR_ID
IP mengambang¶
Di mana IP mengambang dikonfigurasikan dalam penyebaran, setiap proyek akan memiliki sejumlah IP mengambang yang dikendalikan oleh kuota. Akan tetapi, ini perlu dialokasikan untuk proyek dari central pool sebelum penggunaannya — biasanya oleh administrator proyek. Untuk mengalokasikan IP mengambang ke proyek, gunakan tombol Allocate IP To Project pada Floating IPs pada halaman Access & Security pada dasbor. Command line juga dapat digunakan:
$ openstack floating ip create NETWORK_NAME_OR_ID
Setelah dialokasikan, IP mengambang dapat ditugaskan untuk menjalankan instance dari dashboard dengan memilih :guilabel: Associate dari tindakan drop-down di sebelah IP pada tab :guilabel:` Floating IPs` pada halaman Access & Security atau dengan membuat pilihan ini di sebelah instance yang ingin Anda kaitkan dengan itu pada halaman Instance. Tindakan terbalik, Dissociate Floating IP, tersedia dari tab Floating IPs pada halaman :guilabel:` Access & Security` dan dari halaman :guilabel:'Instances`.
Untuk mengaitkan atau memisahkan IP mengambang dengan server dari command line, gunakan perintah berikut:
$ openstack server add floating ip SERVER IP_ADDRESS
$ openstack server remove floating ip SERVER IP_ADDRESS
Melampirkan Block Storage¶
Anda dapat melampirkan blokir penyimpanan ke instance dari dasbor pada halaman :guilabel: Volume. Klik tindakan :guilabel: Manage Attachments di sebelah volume yang ingin Anda lampirkan.
Untuk melakukan tindakan ini dari command line, jalankan perintah berikut:
$ openstack server add volume SERVER VOLUME_NAME_OR_ID --device DEVICE
Anda juga dapat menentukan pemetaan perangkat blok saat boot misalnya melalui klien command-line nova dengan set opsi ini:
--block-device-mapping <dev-name=mapping>
Format pemetaan perangkat blok adalah <dev-name>=<id>:<type>:<size(GB)>:<delete-on-terminate>, dimana:
- dev-name
Nama perangkat tempat volume terpasang di sistem di
/dev/dev_name- id
ID volume untuk boot dari, seperti yang ditunjukkan pada output dari openstack volume list
- type
Baik
snap, yang berarti bahwa volume dibuat dari snapshot, atau apa pun selainsnap(string kosong valid). Dalam contoh sebelumnya, volume tidak dibuat dari snapshot, jadi kami membiarkan bidang ini kosong dalam contoh berikut.- ukuran (GB)
Ukuran volume dalam gigabyte. Aman untuk membiarkannya kosong dan meminta Compute Service menyimpulkan ukurannya.
- delete-on-terminate
Boolean untuk menunjukkan apakah volume harus dihapus ketika instance dihentikan. True dapat ditentukan sebagai
Trueatau1. Salah dapat ditentukan sebagaiFalseatau0.
Perintah berikut akan mem-boot instance baru dan melampirkan volume pada saat yang sama. Volume ID 13 akan dilampirkan sebagai /dev/vdc. Itu bukan snapshot, tidak menentukan ukuran, dan tidak akan dihapus ketika instance dihentikan:
$ openstack server create --image 4042220e-4f5e-4398-9054-39fbd75a5dd7 \
--flavor 2 --key-name mykey --block-device-mapping vdc=13:::0 \
boot-with-vol-test
Jika sebelumnya Anda telah menyiapkan penyimpanan blok dengan image sistem file yang dapat di-boot, bahkan dimungkinkan untuk mem-boot dari penyimpanan blok yang persisten. Perintah berikut mem-boot image dari volume yang ditentukan. Ini mirip dengan perintah sebelumnya, tetapi image dihilangkan dan volume sekarang dilampirkan sebagai /dev/vda:
$ openstack server create --flavor 2 --key-name mykey \
--block-device-mapping vda=13:::0 boot-from-vol-test
Baca instruksi yang lebih terperinci untuk meluncurkan instance dari volume yang dapat di-boot di OpenStack End User Guide.
Untuk mem-boot secara normal dari image dan melampirkan penyimpanan blok, petakan ke perangkat selain vda. Anda dapat menemukan instruksi untuk meluncurkan instance dan melampirkan volume ke instance dan untuk menyalin image ke volume terlampir di OpenStack End User Guide.
Pengambilan Snapshots¶
Mekanisme snapshot OpenStack memungkinkan Anda membuat image baru dari menjalankan instance. Ini sangat nyaman untuk memutakhirkan image dasar atau untuk mengambil image yang dipublikasikan dan mengubahnya untuk penggunaan lokal. Untuk memotret instance yang sedang berjalan ke image menggunakan CLI, lakukan ini:
$ openstack image create IMAGE_NAME --volume VOLUME_NAME_OR_ID
Antarmuka dasbor untuk snapshot dapat membingungkan karena snapshot dan image ditampilkan di halaman Images. Namun, instance snapshot is image. Satu-satunya perbedaan antara image yang Anda unggah langsung ke Image Service dan image yang Anda buat dengan snapshot adalah bahwa image yang dibuat oleh snapshot memiliki properti tambahan dalam glance database. Properti ini ditemukan dalam tabel image_properties dan meliputi:
Name |
Value |
|---|---|
|
snapshot |
|
<uuid of instance that was snapshotted> |
|
<uuid of original image of instance that was snapshotted> |
|
snapshot |
Live Snapshot¶
Live snapshot adalah fitur yang memungkinkan pengguna untuk memotret mesin virtual yang sedang berjalan tanpa menjeda mereka. Snapshot ini hanya snapshot disk saja. Snapshotting sebuah instance sekarang dapat dilakukan tanpa downtime (dengan asumsi QEMU 1.3+ dan libvirt 1.0+ digunakan).
Catatan
Jika Anda menggunakan versi libvirt 1.2.2, Anda mungkin mengalami masalah terputus-putus dengan pembuatan snapshot live.
Untuk secara efektif menonaktifkan snapshotting live libvirt, sampai masalah teratasi, tambahkan pengaturan di bawah ini ke nova.conf.
[workarounds]
disable_libvirt_livesnapshot = True
Ensuring Snapshots of Linux Guests Are Consistent
Bagian berikut ini dari Sébastien Han's OpenStack: Perform Consistent Snapshots blog entry.
Sebuah snapshot menangkap status sistem file, tetapi bukan status memori. Karena itu, untuk memastikan snapshot Anda berisi data yang Anda inginkan, sebelum snapshot Anda, Anda perlu memastikan bahwa:
Menjalankan program telah menulis kontennya ke disk
Sistem file tidak memiliki buffer "dirty": di mana program telah mengeluarkan perintah untuk menulis ke disk, tetapi sistem operasi belum melakukan penulisan
Untuk memastikan bahwa layanan penting telah menulis kontennya ke disk (seperti basis data), kami sarankan Anda membaca dokumentasi untuk aplikasi tersebut untuk menentukan perintah yang akan dikeluarkan agar mereka menyinkronkan kontennya ke disk. Jika Anda tidak yakin bagaimana melakukan ini, pendekatan teraman adalah menghentikan layanan yang berjalan ini secara normal.
Untuk menangani masalah buffer "dirty", kami sarankan untuk menggunakan perintah sinkronisasi sebelum snapshotting:
# sync
Menjalankan sync menulis dirty buffer (blok buffered yang telah dimodifikasi tetapi belum ditulis ke blok disk) ke disk.
Menjalankan sync saja tidak cukup untuk memastikan bahwa sistem file konsisten. Kami menyarankan Anda menggunakan alat fsfreeze, yang menghentikan akses baru ke sistem file, dan membuat image stabil pada disk yang cocok untuk snapshotting. Alat fsfreeze mendukung beberapa sistem file, termasuk ext3, ext4, dan XFS. Jika mesin virtual Anda berjalan di Ubuntu, instal paket util-linux untuk mendapatkan fsfreeze:
Catatan
Dalam kasus yang sangat umum di mana snapshot yang mendasarinya dilakukan melalui LVM, pembekuan filesystem secara otomatis ditangani oleh LVM.
# apt-get install util-linux
Jika sistem operasi Anda tidak memiliki versi fsfreeze`, Anda dapat menggunakan xfs_freeze sebagai gantinya, yang tersedia di Ubuntu dalam paket xfsprogs. Terlepas dari "xfs" dalam namanya, xfs_freeze juga berfungsi pada ext3 dan ext4 jika Anda menggunakan kernel Linux versi 2.6.29 atau lebih tinggi, karena ia bekerja pada tingkat virtual file system (VFS) mulai 2.6.29. Versi xfs_freeze mendukung argumen command-line yang sama dengan fsfreeze.
Pertimbangkan contoh di mana Anda ingin mengambil snapshot dari volume penyimpanan blok persisten, yang terdeteksi oleh sistem operasi guest sebagai /dev/vdb dan dipasang pada /mnt. Perintah fsfreeze menerima dua argumen:
- -f
Bekukan sistem
- -u
Lelehkan (mencairkan) sistem
Untuk membekukan volume dalam persiapan untuk snapshotting, Anda akan melakukan hal berikut, sebagai root, di dalam instance:
# fsfreeze -f /mnt
Anda must mount the file system sebelum Anda menjalankan perintah fsfreeze.
Ketika perintah fsfreeze -f dikeluarkan, semua transaksi yang sedang berlangsung dalam sistem file diizinkan untuk diselesaikan, panggilan sistem tulis baru dihentikan, dan panggilan lain yang mengubah sistem file dihentikan. Yang paling penting, semua data kotor (dirty data), metadata, dan informasi log ditulis ke disk.
Setelah volume dibekukan, jangan mencoba membaca dari atau menulis ke volume, karena operasi ini macet. Sistem operasi berhenti setiap operasi I/O dan setiap upaya I/O ditunda sampai sistem file telah dibekukan.
Setelah Anda mengeluarkan perintah :command: fsfreeze, aman untuk melakukan snapshot. Misalnya, jika volume instance Anda bernama mon-volume dan Anda ingin snapshot ke image bernama mon-snapshot, Anda sekarang dapat menjalankan yang berikut:
$ openstack image create mon-snapshot --volume mon-volume
Ketika snapshot selesai, Anda dapat mencairkan sistem file dengan perintah berikut, sebagai root, di dalam instance:
# fsfreeze -u /mnt
Jika Anda ingin membuat cadangan sistem file root, Anda tidak bisa menjalankan perintah sebelumnya karena itu akan membekukan prompt. Sebagai gantinya, jalankan one-liner berikut, sebagai root, di dalam instance:
# fsfreeze -f / && read x; fsfreeze -u /
Setelah perintah ini, praktik umum (common practice) memanggil openstack image create dari workstation Anda, dan setelah selesai tekan enter pada instance instance Anda untuk mencairkannya. Jelas Anda bisa mengotomatiskan ini, tetapi setidaknya itu akan membiarkan Anda menyinkronkan dengan benar.
Ensuring Snapshots of Windows Guests Are Consistent
Memperoleh snapshot yang konsisten dari Windows VMs secara konseptual mirip dengan memperoleh snapshot yang konsisten dari Linux VMs, walaupun itu membutuhkan utilitas tambahan untuk berkoordinasi dengan subsistem Windows-only yang dirancang untuk memfasilitasi backup yang konsisten.
Windows XP dan rilis selanjutnya menyertakan Volume Shadow Copy Service (VSS) yang menyediakan kerangka kerja sehingga aplikasi yang sesuai dapat secara konsisten didukung pada sistem file live. Untuk menggunakan kerangka kerja ini, pemohon VSS dijalankan. Ini memberi sinyal ke layanan VSS bahwa cadangan yang konsisten diperlukan. Layanan VSS memberi tahu aplikasi yang patuh (disebut penulis VSS) untuk menghentikan aktivitas data mereka. Layanan VSS kemudian memberi tahu penyedia salinan untuk membuat snapshot. Setelah snapshot dibuat, layanan VSS tidak lagi menulis penulis VSS dan aktivitas I/O normal dilanjutkan.
QEMU menyediakan agen tamu (guest agent) yang dapat dijalankan pada tamu yang menggunakan hypervisor KVM. Agen tamu ini, pada Windows VM, berkoordinasi dengan layanan Windows VSS untuk memfasilitasi alur kerja yang memastikan snapshot yang konsisten. Fitur ini membutuhkan setidaknya QEMU 1.7. Perintah agen tamu yang relevan adalah:
- guest-file-flush
Tulis buffer "dirty" ke disk, mirip dengan operasi Linux
sync.- guest-fsfreeze
Tangguhkan I/O ke disk, mirip dengan operasi Linux
fsfreeze -f.- guest-fsfreeze-thaw
Lanjutkan I/O ke disk, mirip dengan operasi Linux
fsfreeze -u.
Untuk mendapatkan snapshots dari VM Windows perintah ini dapat dituliskan secara berurutan: flush the filesystems, freeze the filesystems, snapshot the filesystems, kemudian unfreeze the filesystems. Seperti halnya skrip alur kerja serupa terhadap Linux VM, kehati-hatian harus digunakan saat menulis skrip tersebut untuk memastikan penanganan kesalahan menyeluruh dan sistem file tidak akan dibiarkan dalam keadaan beku.
Instance dalam Database¶
Sementara informasi instance disimpan dalam sejumlah tabel database, tabel yang kemungkinan besar perlu Anda lihat terkait dengan instance pengguna adalah tabel instance.
Tabel instance ini membawa sebagian besar informasi yang terkait dengan instance yang berjalan dan yang dihapus. Tabel ini memiliki array field yang membingungkan; untuk daftar lengkap, lihat database. Tabel ini adalah field yang paling berguna bagi operator yang ingin membentuk kueri:
Field
deleteddisetel ke1jika instance dihapus danNULLjika belum dihapus. Field ini penting untuk mengecualikan instance yang dihapus dari kueri Anda.Field `` uuid`` adalah UUID dari instance dan digunakan di seluruh tabel lain dalam database sebagai foreign key. ID ini juga dilaporkan dalam log, dasbor, dan alat command-line untuk mengidentifikasi secara unik sebuah instance.
A collection of foreign keys are available to find relations to the instance. The most useful of these —
user_idandproject_idare the UUIDs of the user who launched the instance and the project it was launched in.Field
hostmemberi tahu compute node mana yang menjadi hosting instance.Field
hostnamemenyimpan nama instance saat diluncurkan. Nama tampilan awalnya sama dengan nama host tetapi dapat diatur ulang menggunakan perintah ganti nama nova.
Sejumlah field terkait waktu berguna untuk melacak ketika perubahan kondisi terjadi pada sebuah instance:
created_atupdated_atdeleted_atscheduled_atlaunched_atterminated_at
Semoga berhasil!¶
Bagian ini dimaksudkan sebagai pengantar singkat untuk beberapa perintah OpenStack yang paling berguna. Untuk daftar lengkap, silakan merujuk ke OpenStack Administrator Guide <https://docs.openstack.org/admin-guide/> __. Kami berharap pengguna Anda tetap bahagia dan mengenali kerja keras Anda! (Untuk kerja keras lebih lanjut, alihkan halaman ke bab berikutnya, tempat kami membahas operasi system-facing: pemeliharaan, kegagalan, dan debugging.)
