Tales From the Cryp^H^H^H^H Cloud¶

Di sinilah letak berbagai kisah dari operator cloud OpenStack. Baca, dan belajarlah dari kebijaksanaan mereka.

VLAN ganda¶

Saya ada di lokasi di Kelowna, British Columbia, Kanada menyiapkan cloud OpenStack baru. Penyebaran sepenuhnya otomatis: Cobbler mengerahkan OS pada bare metal, bootstrap, dan Puppet mengambil alih dari sana. Saya telah menjalankan skenario penyebaran berkali-kali dalam praktik dan menerima begitu saja bahwa semuanya bekerja.

Pada hari terakhir saya di Kelowna, saya melakukan panggilan konferensi dari hotel saya. Di latar belakang, aku bermain-main di awan baru. Saya meluncurkan sebuah instance dan masuk. Semuanya tampak baik-baik saja. Karena bosan, saya jalankan :command: ps aux dan tiba-tiba instancenya terkunci.

Berpikir itu hanya masalah satu kali, saya menghentikan instance dan meluncurkan yang baru. Pada saat itu, panggilan konferensi berakhir dan saya pergi ke pusat data.

Di pusat data, saya menyelesaikan beberapa tugas dan mengingat pengunciannya. Saya masuk ke instance baru dan menjalankan: command: ps aux lagi. Itu berhasil. Fiuh. Saya memutuskan untuk menjalankannya sekali lagi. Terkunci.

Setelah mereproduksi masalah beberapa kali, saya sampai pada kesimpulan yang tidak menguntungkan bahwa cloud ini memang memiliki masalah. Lebih buruk lagi, waktu saya habis di Kelowna dan saya harus kembali ke Calgary.

Di mana Anda bahkan mulai memecahkan masalah seperti ini? instance yang hanya terkunci secara acak ketika perintah dikeluarkan. Apakah itu image? Tidak — ini terjadi pada semua image. Apakah ini node komputasi? Tidak — semua node. Apakah instance terkunci? Tidak! Koneksi SSH baru berfungsi dengan baik!

Kami mencari bantuan. Seorang insinyur jaringan menyarankan itu adalah masalah MTU. Besar! MTU! Sesuatu untuk terus berlanjut! Apa itu MTU dan mengapa itu menyebabkan masalah?

MTU adalah unit transmisi maksimum. Ini menentukan jumlah maksimum byte yang diterima antarmuka untuk setiap paket. Jika dua antarmuka memiliki dua MTU yang berbeda, byte mungkin akan terpotong dan hal-hal aneh terjadi - seperti penguncian sesi acak.

Catatan

Tidak semua paket memiliki ukuran 1500. Menjalankan perintah ls di atas SSH mungkin hanya membuat paket tunggal kurang dari 1500 byte. Namun, menjalankan perintah dengan output yang berat, seperti ps aux membutuhkan beberapa paket 1500 byte.

Oke, jadi dari mana datangnya masalah MTU? Mengapa kami belum melihat ini di penyebaran lain? Apa yang baru dalam situasi ini? Nah, pusat data baru, uplink baru, switch baru, model switch baru, server baru, pertama kali menggunakan model server ini ... jadi, pada dasarnya semuanya baru. Hebat. Kami bermain-main dengan menaikkan MTU di berbagai bidang: sakelar, NIC pada node komputasi, NIC virtual dalam instance, kami bahkan meminta pusat data menaikkan MTU untuk antarmuka uplink kami. Beberapa perubahan berhasil, beberapa tidak. Baris pemecahan masalah (line of troubleshooting) ini rasanya tidak benar. Kita tidak harus mengubah MTU di area ini.

Sebagai upaya terakhir, admin jaringan kami (Alvaro) dan saya sendiri duduk dengan empat windows terminal, pensil, dan selembar kertas. Di satu jendela, kami menjalankan ping. Di windows kedua, kami menjalankan tcpdump pada pengontrol cloud. Pada yang ketiga, tcpdump pada compute node. Dan keempat memiliki tcpdump pada instance. Sebagai latar belakang, cloud ini merupakan pengaturan multi-node, non-multi-host.

Satu pengendali cloud bertindak sebagai gateway ke semua node komputasi. VlanManager digunakan untuk konfigurasi jaringan. Ini berarti bahwa pengontrol cloud dan semua node komputasi memiliki VLAN yang berbeda untuk setiap proyek OpenStack. Kami menggunakan opsi -s dari ping untuk mengubah ukuran paket. Kami menyaksikan kadang-kadang paket akan kembali sepenuhnya, kadang-kadang mereka hanya bisa keluar dan tidak pernah kembali, dan kadang-kadang paket akan berhenti secara acak. Kami mengubah tcpdump untuk mulai menampilkan dump hex paket. Kami melakukan ping di antara setiap kombinasi luar, pengontrol, komputasi, dan instance.

Akhirnya, Alvaro memperhatikan sesuatu. Ketika sebuah paket dari luar mengenai pengendali cloud, itu tidak harus dikonfigurasikan dengan VLAN. Kami memverifikasi ini sebagai benar. Ketika paket pergi dari cloud controller ke compute node, seharusnya hanya memiliki VLAN jika ditakdirkan untuk instance. Ini masih benar. Ketika balasan ping dikirim dari instance, itu harus dalam VLAN. Benar. Ketika kembali ke pengontrol cloud dan dalam perjalanan keluar ke Internet, seharusnya tidak lagi memiliki VLAN. Salah. Uh oh. Tampaknya bagian VLAN dari paket itu tidak dihapus.

Itu tidak masuk akal.

Saat memantulkan ide ini di kepala kami, saya mengetik perintah secara acak di compute node:

$ ip a
…
10: vlan100@vlan20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br100 state UP
…

"Hey Alvaro, can you run a VLAN on top of a VLAN?"

"If you did, you'd add an extra 4 bytes to the packet…"

Kemudian semuanya masuk akal ...

$ grep vlan_interface /etc/nova/nova.conf
vlan_interface=vlan20

Dalam nova.conf, vlan_interface menentukan antarmuka apa yang harus diikat (attach) OpenStack dengan semua VLAN. Pengaturan yang benar seharusnya:

vlan_interface=bond0

Karena ini akan menjadi NIC yang terikat pada server.

vlan20 adalah VLAN yang diberikan pusat data kepada kami untuk akses Internet keluar. Ini adalah VLAN yang benar dan juga melekat pada bond0.

Secara tidak sengaja, saya mengkonfigurasi OpenStack untuk melampirkan semua tenant VLAN ke vlan20 dan bukannya bond0 sehingga menumpuk satu VLAN di atas yang lain. Ini menambahkan 4 byte tambahan untuk setiap paket dan menyebabkan paket 1504 byte dikirim yang akan menyebabkan masalah ketika tiba di antarmuka yang hanya menerima 1500.

Segera setelah pengaturan ini diperbaiki, semuanya bekerja.

"The Issue"¶

Pada akhir Agustus 2012, sebuah sekolah pasca sekolah menengah di Alberta, Kanada memigrasikan infrastrukturnya ke cloud OpenStack. Seperti keberuntungan, dalam hari pertama atau kedua berjalan, salah satu server mereka hilang dari jaringan. Blip. Hilang.

Setelah memulai kembali instance, semuanya kembali dan berjalan. Kami meninjau log dan melihat bahwa pada titik tertentu, komunikasi jaringan berhenti dan kemudian semuanya menjadi menganggur. Kami mencatat ini hingga kejadian acak.

Beberapa malam kemudian, itu terjadi lagi.

Kami meninjau kedua set log. Satu hal yang paling menonjol adalah DHCP. Pada saat itu, OpenStack, secara default, mengatur penyewaan DHCP selama satu menit (sekarang dua menit). Ini berarti bahwa setiap instance menghubungi pengendali cloud (server DHCP) untuk memperbarui IP tetapnya. Untuk beberapa alasan, instance ini tidak dapat memperbarui IP-nya. Kami mengkorelasikan log instance dengan log pada pengontrol cloud dan membuat percakapan:

Instance mencoba memperbarui IP.
Pengontrol cloud menerima permintaan pembaruan dan mengirim respons.
Instance "ignores" respons dan mengirim kembali permintaan pembaruan.
Pengontrol cloud menerima permintaan kedua dan mengirimkan respons baru.
Mesin virtual mulai mengirim permintaan pembaruan ke `` 255.255.255.255`` karena belum mendapat balasan dari pengendali cloud.
Pengontrol cloud menerima permintaan `` 255.255.255.255`` dan mengirimkan respons ketiga.
Instance akhirnya menyerah.

Dengan informasi ini di tangan, kami yakin bahwa masalahnya ada pada DHCP. Kami berpikir bahwa karena alasan tertentu, mesin virtual tidak mendapatkan alamat IP baru dan tanpa IP, itu mematikan sendiri dari jaringan.

Pencarian Google cepat muncul ini: DHCP lease errors in VLAN mode yang selanjutnya mendukung teori DHCP kami.

Gagasan awal adalah hanya menambah waktu sewa. Jika instance hanya diperbarui sekali setiap minggu, peluang terjadinya masalah ini akan jauh lebih kecil daripada setiap menit. Tapi ini tidak menyelesaikan masalah. Itu hanya menutupi masalah.

Kami memutuskan untuk menjalankan tcpdump pada instance ini dan melihat apakah kami dapat menjalankannya kembali. Cukup yakin, kami melakukannya.

tcpdump terlihat sangat, sangat aneh. Singkatnya, sepertinya komunikasi jaringan terhenti sebelum instance mencoba memperbarui IP-nya. Karena ada begitu banyak obrolan DHCP dari sewa satu menit, sangat sulit untuk mengkonfirmasinya, tetapi bahkan dengan hanya perbedaan milidetik antara paket, jika satu paket tiba terlebih dahulu, itu tiba terlebih dahulu, dan jika paket itu melaporkan masalah jaringan, maka ia memiliki telah terjadi sebelum DHCP.

Selain itu, instance ini bertanggung jawab atas pekerjaan backup yang sangat, sangat besar setiap malam. Sementara "The Issue" (seperti yang kita sebut sekarang) tidak terjadi tepat ketika backup terjadi, itu cukup dekat (beberapa jam) sehingga kami tidak bisa mengabaikannya.

Hari-hari selanjutnya berlalu dan kami terus menangkap isu ini. Kami menemukan bahwa dhclient tidak berjalan setelah The Issue terjadi. Sekarang kita kembali berpikir itu masalah DHCP. Menjalankan restart /etc/init.d/networking membawa semuanya kembali dan berjalan.

Pernahkah mengalami salah satu dari hari-hari itu di mana tiba-tiba Anda mendapatkan hasil Google yang Anda cari? Nah, itulah yang terjadi di sini. Saya mencari informasi tentang dhclient dan mengapa ia mati ketika ia tidak dapat memperpanjang sewa dan tiba-tiba saya menemukan banyak diskusi OpenStack dan dnsmasq yang identik dengan masalah yang kami lihat!

Problem with Heavy Network IO and Dnsmasq.

instances losing IP address while running, due to No DHCPOFFER.

Serius, Google.

Laporan bug ini adalah kunci dari segalanya: KVM images lose connectivity with bridged network.

Lucu membaca laporan itu. Itu penuh dengan orang yang memiliki beberapa masalah jaringan aneh tetapi tidak cukup menjelaskannya dengan cara yang sama.

Jadi itu adalah bug qemu/kvm.

Pada saat yang sama menemukan laporan bug, rekan kerja berhasil mereproduksi The Issue! How? Dia menggunakan iperf untuk memuntahkan satu ton bandwidth pada sebuah instance. Dalam 30 menit, instance baru saja menghilang dari jaringan.

Dipersenjatai dengan qemu yang di-patch dan cara untuk mereproduksi, kami berangkat untuk melihat apakah kami akhirnya telah menyelesaikan The Issue. Setelah 48 jam terus-menerus memukul instance dengan bandwidth, kami yakin. Sisanya (the rest) adalah sejarah. Anda dapat mencari "bug" laporan bug untuk menemukan komentar saya dan tes yang sebenarnya.

Gambar yang hilang¶

Pada akhir 2012, Cybera (sebuah organisasi nirlaba dengan mandat untuk mengawasi pengembangan infrastruktur cyber di Alberta, Kanada) mengerahkan OpenStack cloud yang diperbarui untuk proyek mereka DAIR project <https://www.canarie.ca/cloud/> _ . Beberapa hari setelah produksi, sebuah node komputasi terkunci. Setelah me-reboot node, saya memeriksa untuk melihat instance apa yang di-host pada node itu sehingga saya bisa mem-bootnya atas nama pelanggan. Untungnya, hanya satu instance.

Perintah :command: nova reboot tidak berfungsi, jadi saya gunakan virsh, tetapi segera kembali dengan kesalahan yang mengatakan itu tidak dapat menemukan backing disk. Dalam hal ini, disk pendukung adalah Glance image yang disalin ke /var/lib/nova/instances/_base saat image digunakan untuk pertama kalinya. Mengapa tidak bisa menemukannya? Saya memeriksa direktori dan cukup yakin sudah hilang.

Saya meninjau basis data nova dan melihat entri instance di tabel nova.instances. Image yang menggunakan instance cocok dengan apa yang dilaporkan virsh, jadi tidak ada ketidakkonsistenan di sana.

Saya memeriksa Glance dan memperhatikan bahwa image ini adalah snapshot yang dibuat pengguna. Setidaknya itu adalah kabar baik — pengguna ini akan menjadi satu-satunya pengguna yang terpengaruh.

Akhirnya, saya memeriksa StackTach dan meninjau acara pengguna. Mereka telah membuat dan menghapus beberapa foto — kemungkinan besar bereksperimen. Meskipun timestamp tidak cocok, kesimpulan saya adalah bahwa mereka meluncurkan instance mereka dan kemudian menghapus snapshot dan entah bagaimana dihapus dari /var/lib/nova/instances/_base. Tidak ada yang masuk akal, tapi itu yang terbaik yang bisa saya lakukan.

Ternyata alasan bahwa simpul komputasi ini terkunci adalah masalah perangkat keras. Kami menghapusnya dari cloud DAIR dan memanggil Dell untuk diservis. Dell tiba dan mulai bekerja. Entah bagaimana atau yang lain (atau jari yang gemuk), simpul komputasi yang berbeda dihancurkan (bumped) dan di-boot ulang. Great.

Ketika node ini sepenuhnya boot, saya menjalankan skenario yang sama untuk melihat instance apa yang sedang berjalan sehingga saya bisa menyalakannya kembali. Ada total empat. Tiga boot dan satu memberikan kesalahan. Itu kesalahan yang sama seperti sebelumnya: tidak dapat menemukan backing disk. Serius, apa?

Sekali lagi, ternyata image itu adalah snapshot. Tiga instance lain yang berhasil dimulai adalah image cloud standar. Apakah itu masalah dengan foto? Itu tidak masuk akal.

Catatan tentang arsitektur DAIR: /var/lib/nova/instances adalah mount NFS bersama. Ini berarti bahwa semua node komputasi memiliki akses ke sana, yang mencakup direktori _base. Area terpusat lainnya adalah /var/log/rsyslog pada pengontrol cloud. Direktori ini mengumpulkan semua log OpenStack dari semua node komputasi. Saya bertanya-tanya apakah ada entri untuk file yang virsh melaporkan:

dair-ua-c03/nova.log:Dec 19 12:10:59 dair-ua-c03
2012-12-19 12:10:59 INFO nova.virt.libvirt.imagecache
[-] Removing base file:
/var/lib/nova/instances/_base/7b4783508212f5d242cbf9ff56fb8d33b4ce6166_10

Ah-hah! Jadi OpenStack menghapusnya. Tapi kenapa?

Fitur diperkenalkan di Essex untuk secara berkala memeriksa dan melihat apakah ada _base file yang tidak digunakan. Jika ada, OpenStack Compute akan menghapusnya. Gagasan ini kedengarannya cukup polos dan memiliki kualitas yang bagus. Tetapi bagaimana fitur ini akhirnya dihidupkan? Itu dinonaktifkan secara default di Essex. Seperti seharusnya. Dulu decided to be turned on in Folsom. Saya tidak bisa cukup menekankan bahwa:

Actions which delete things should not be enabled by default.

Ruang disk bisa murah hari ini. Pemulihan data akan tidak.

Kedua, direktori /var/lib/nova/instances` bersama DAIR berkontribusi pada masalah. Karena semua node komputasi memiliki akses ke direktori ini, semua node komputasi secara berkala meninjau direktori _base. Jika hanya ada satu instance menggunakan image, dan simpul yang dihidupkan instance turun selama beberapa menit, itu tidak akan dapat menandai image sebagai masih digunakan. Oleh karena itu, image sepertinya tidak digunakan dan dihapus. Ketika node komputasi kembali online, instance yang dihosting pada node itu tidak dapat memulai.

The Valentine's Day Compute Node Massacre (Hari Valentine Menghitung Pembantaian Node)¶

Meskipun judul cerita ini jauh lebih dramatis daripada peristiwa yang sebenarnya, saya tidak berpikir, atau berharap, bahwa saya akan memiliki kesempatan untuk menggunakan "Valentine's Day Massacre" lagi dalam sebuah judul.

Hari Valentine yang lalu, saya menerima peringatan bahwa node komputasi tidak lagi tersedia di cloud — artinya,

$ openstack compute service list

menunjukkan node khusus ini dalam kondisi turun.

Saya masuk ke cloud controller dan bisa ping dan SSH ke node komputasi bermasalah yang tampak sangat aneh. Biasanya jika saya menerima jenis peringatan ini, node komputasi telah benar-benar terkunci dan tidak dapat diakses.

Setelah beberapa menit pemecahan masalah, saya melihat detail berikut:

Seorang pengguna baru-baru ini mencoba meluncurkan instance CentOS pada node itu
Pengguna ini adalah satu-satunya pengguna pada node (node baru)
Muatan naik hingga 8 tepat sebelum saya menerima peringatan
Perangkat jaringan 10gb terikat (bond0) dalam keadaan DOWN
NIC 1GB masih hidup dan aktif

Saya melihat status kedua NIC pada pasangan terikat dan melihat bahwa tidak ada yang dapat berkomunikasi dengan port switch. Melihat bagaimana masing-masing NIC dalam ikatan terhubung ke switch terpisah, saya berpikir bahwa peluang port switch mati pada setiap switch pada saat yang sama cukup mustahil. Saya menyimpulkan bahwa port ganda 10GB NIC telah mati dan perlu diganti. Saya membuat tiket untuk departemen dukungan perangkat keras di pusat data tempat node di-host. Saya merasa beruntung bahwa ini adalah node baru dan belum ada orang lain yang meng-host-nya.

Satu jam kemudian saya menerima peringatan yang sama, tetapi untuk node komputasi lain. Crap. OK, sekarang pasti ada masalah yang terjadi. Sama seperti node asli, saya bisa masuk oleh SSH. Bond0 NIC BAWAH tetapi 1gb NIC aktif.

Dan bagian terbaiknya: pengguna yang sama baru saja mencoba membuat instance CentOS. Apa?

Saya benar-benar bingung pada saat ini, jadi saya mengirim sms admin jaringan kami untuk melihat apakah dia tersedia untuk membantu. Dia login ke kedua switch dan segera melihat masalahnya: switch mendeteksi spanning tree paket yang berasal dari dua node komputasi dan segera menutup port untuk mencegah spanning tree loop:

Feb 15 01:40:18 SW-1 Stp: %SPANTREE-4-BLOCK_BPDUGUARD: Received BPDU packet on Port-Channel35 with BPDU guard enabled. Disabling interface. (source mac fa:16:3e:24:e7:22)
Feb 15 01:40:18 SW-1 Ebra: %ETH-4-ERRDISABLE: bpduguard error detected on Port-Channel35.
Feb 15 01:40:18 SW-1 Mlag: %MLAG-4-INTF_INACTIVE_LOCAL: Local interface Port-Channel35 is link down. MLAG 35 is inactive.
Feb 15 01:40:18 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-Channel35 (Server35), changed state to down
Feb 15 01:40:19 SW-1 Stp: %SPANTREE-6-INTERFACE_DEL: Interface Port-Channel35 has been removed from instance MST0
Feb 15 01:40:19 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet35 (Server35), changed state to down

Dia mengaktifkan kembali port switch dan kedua node komputasi segera hidup kembali.

Sayangnya, cerita ini memiliki akhiran yang terbuka ... kita masih mencari tahu mengapa image CentOS mengirim paket spanning tree. Lebih lanjut, kami sedang meneliti cara yang tepat tentang bagaimana mengurangi hal ini terjadi. Ini masalah yang lebih besar dari yang mungkin dipikirkan. Meskipun sangat penting bagi switch untuk mencegah spanning tree loop, sangat problematis untuk membuat seluruh node komputasi dipotong dari jaringan saat ini terjadi. Jika sebuah node komputasi menampung 100 instance dan salah satunya mengirimkan paket spanning tree, instance tersebut secara efektif telah melakukan DDOS terhadap 99 instance lainnya.

Ini adalah topik yang sedang berlangsung dan panas di lingkaran jaringan — terutama dengan peningkatan virtualisasi dan virtual switch.

Down the Rabbit Hole (masuk kedalam lubang kelinci)¶

Pengguna yang dapat mengambil log konsol dari menjalankan instance adalah anugerah untuk dukungan — sering kali mereka dapat mengetahui apa yang terjadi di dalam instance mereka dan memperbaiki apa yang terjadi tanpa mengganggu Anda. Sayangnya, terkadang logging kegagalan yang terlalu banyak dapat menyebabkan masalah tersendiri.

Sebuah laporan muncul: VM diluncurkan perlahan, atau tidak sama sekali. Beri tanda pada pemeriksaan standar — tidak ada apa pun di Nagios, tetapi ada lonjakan jaringan terhadap master saat ini dari kluster RabbitMQ kami. Investigasi dimulai, tetapi segera bagian-bagian lain dari antrian cluster membocorkan memori seperti saringan (sieve). Kemudian peringatan datang — server master Kelinci down dan koneksi gagal ke slave.

Pada saat itu, layanan kontrol kami dihosting oleh tim lain dan kami tidak memiliki banyak informasi debug untuk menentukan apa yang terjadi dengan master, dan kami tidak dapat mem-boot ulang. Tim itu mencatat bahwa ia gagal tanpa peringatan, tetapi berhasil mem-boot ulangnya. Setelah satu jam, gugus telah kembali ke keadaan normal dan kami pulang untuk hari itu.

Melanjutkan diagnosis keesokan paginya tendangan dimulai (kick started) oleh kegagalan lain yang identik. Kami dengan cepat menjalankan antrean pesan lagi, dan mencoba mencari tahu mengapa Rabbit menderita begitu banyak lalu lintas jaringan. Mengaktifkan debug logging di nova-api dengan cepat membawa pemahaman. tail -f /var/log/nova/nova-api.log bergulir lebih cepat dari yang pernah kami lihat sebelumnya. CTRL+C untuk itu dan kita bisa melihat dengan jelas isi dari kegagalan log sistem yang memuntahkan berulang-ulang - log sistem dari salah satu instance pengguna kami.

Setelah menemukan ID instance kami menuju ke /var/lib/nova/instances untuk menemukan console.log:

adm@cc12:/var/lib/nova/instances/instance-00000e05# wc -l console.log
92890453 console.log
adm@cc12:/var/lib/nova/instances/instance-00000e05# ls -sh console.log
5.5G console.log

Benar saja, pengguna telah secara berkala me-refresh halaman log konsol di dashboard dan file 5G melintasi cluster Rabbit untuk sampai ke dashboard.

Kami memanggil mereka dan meminta mereka untuk berhenti sebentar, dan mereka senang meninggalkan VM yang rusak parah. Setelah itu, kami mulai memonitor ukuran log konsol.

Sampai hari ini, the issue tidak memiliki resolusi permanen, tetapi kami menantikan diskusi di pertemuan berikutnya.

Havana Haunted by the Dead (Havana Dihantui oleh Orang Mati)¶

Felix Lee dari Academia Sinica Grid Computing Center di Taiwan menyumbangkan cerita ini.

Saya baru saja memutakhirkan OpenStack dari Grizzly ke Havana 2013.2-2 menggunakan repositori RDO dan semuanya berjalan cukup baik — kecuali EC2 API.

Saya perhatikan bahwa API akan menderita dari beban yang berat dan merespons dengan lambat permintaan EC2 tertentu seperti RunInances.

Output dari /var/log/nova/nova-api.log pada Havana:

2014-01-10 09:11:45.072 129745 INFO nova.ec2.wsgi.server
[req-84d16d16-3808-426b-b7af-3b90a11b83b0
0c6e7dba03c24c6a9bce299747499e8a 7052bd6714e7460caeb16242e68124f9]
117.103.103.29 "GET
/services/Cloud?AWSAccessKeyId=[something]&Action=RunInstances&ClientToken=[something]&ImageId=ami-00000001&InstanceInitiatedShutdownBehavior=terminate...
HTTP/1.1" status: 200 len: 1109 time: 138.5970151

Permintaan ini membutuhkan waktu dua menit untuk diproses, tetapi dieksekusi dengan cepat pada penyebaran Grizzly yang ada bersama (co-existing) menggunakan perangkat keras dan konfigurasi sistem yang sama.

Output dari /var/log/nova/nova-api.log pada Grizzly:

2014-01-08 11:15:15.704 INFO nova.ec2.wsgi.server
[req-ccac9790-3357-4aa8-84bd-cdaab1aa394e
ebbd729575cb404081a45c9ada0849b7 8175953c209044358ab5e0ec19d52c37]
117.103.103.29 "GET
/services/Cloud?AWSAccessKeyId=[something]&Action=RunInstances&ClientToken=[something]&ImageId=ami-00000007&InstanceInitiatedShutdownBehavior=terminate...
HTTP/1.1" status: 200 len: 931 time: 3.9426181

Saat memantau sumber daya sistem, saya melihat peningkatan konsumsi memori yang signifikan sementara EC2 API memproses permintaan ini. Saya pikir itu tidak menangani memori dengan benar — mungkin tidak melepaskan memori. Jika API menerima beberapa permintaan ini, konsumsi memori cepat tumbuh hingga sistem kehabisan RAM dan mulai menggunakan swap. Setiap node memiliki 48 GB RAM dan proses "nova-api" akan menghabiskan semuanya dalam beberapa menit. Setelah ini terjadi, seluruh sistem akan menjadi sangat lambat sampai saya me-restart layanan nova-api.

Jadi, saya mendapati diri saya bertanya-tanya apa yang berubah dalam EC2 API di Havana yang mungkin menyebabkan ini terjadi. Apakah itu bug atau perilaku normal yang sekarang harus saya atasi?

Setelah menggali kode nova (OpenStack Compute), saya perhatikan dua area di api/ec2/cloud.py yang berpotensi memengaruhi sistem saya:

instances = self.compute_api.get_all(context,
                                     search_opts=search_opts,
                                     sort_dir='asc')

sys_metas = self.compute_api.get_all_system_metadata(
    context, search_filts=[{'key': ['EC2_client_token']},
                           {'value': [client_token]}])

Karena basis data saya berisi banyak catatan — lebih dari 1 juta catatan metadata dan lebih dari 300.000 catatan instance dalam status "deleted" atau "errored" - setiap pencarian membutuhkan waktu lama. Saya memutuskan untuk membersihkan database dengan terlebih dahulu mengarsipkan salinan untuk cadangan dan kemudian melakukan beberapa penghapusan menggunakan klien MySQL. Sebagai contoh, saya menjalankan perintah SQL berikut untuk menghapus deretan instance yang dihapus selama lebih dari setahun:

mysql> delete from nova.instances where deleted=1 and terminated_at < (NOW() - INTERVAL 1 YEAR);

Performa meningkat pesat setelah menghapus catatan lama dan penerapan baru saya terus berperilaku baik.

Tales From the Cryp^H^H^H^H Cloud