Layanan Metadata Azure: Peristiwa Terjadwal untuk VM Linux

Berlaku untuk: ✔️ VM Linux ✔️Set skala fleksibel ✔️ Set skala seragam

Acara Terjadwal adalah Metadata Service Azure yang memberikan waktu bagi aplikasi Anda untuk mempersiapkan pemeliharaan komputer virtual (VM). Acara terjadwal memberikan informasi tentang acara pemeliharaan yang akan datang (misalnya, reboot) sehingga aplikasi Anda dapat mempersiapkannya dan membatasi gangguan. Acara terjadwal tersedia untuk semua jenis Komputer Virtual Azure, termasuk PaaS dan IaaS di Windows dan Linux.

Untuk informasi tentang Peristiwa Terjadwal di Windows, lihat Peristiwa Terjadwal untuk komputer virtual Windows.

Peristiwa terjadwal menyediakan pemberitahuan proaktif tentang peristiwa mendatang, untuk informasi reaktif tentang peristiwa yang telah terjadi lihat informasi ketersediaan VM di Azure Resource Graph dan Membuat aturan pemberitahuan ketersediaan untuk komputer virtual Azure.

Mengapa menggunakan Peristiwa Terjadwal?

Banyak aplikasi dapat mengambil manfaat dari waktu untuk mempersiapkan pemeliharaan komputer virtual. Waktu ini dapat digunakan untuk melakukan tugas khusus aplikasi yang meningkatkan ketersediaan, keandalan, dan kemampuan layanan, termasuk:

• Titik pemeriksaan dan pemulihan.
• Pengosongan koneksi.
• Kegagalan replika utama.
• Penghapusan dari kumpulan penyeimbang muatan.
• Pengelogan peristiwa.
• Pematian ringan.

Dengan Peristiwa Terjadwal, aplikasi Anda dapat menemukan kapan pemeliharaan akan terjadi dan memicu tugas untuk membatasi dampaknya.

Peristiwa Terjadwal memberikan peristiwa dalam kasus penggunaan berikut:

• Pemeliharaan yang dimulai platform (misalnya, reboot VM, migrasi langsung, atau pembaruan penyimpanan memori untuk host).
• Komputer virtual berjalan pada perangkat keras host terdegradasi yang diprediksi akan segera gagal.
• Mesin virtual berjalan di host yang mengalami kegagalan perangkat keras.
• Pemeliharaan yang dimulai pengguna (misalnya, pengguna memulai ulang atau menyebarkan ulang VM).
• Pembersihan instans komputer virtual Spot dan set skala Spot.

Dasar-dasarnya

Metadata Service memaparkan informasi tentang menjalankan komputer virtual menggunakan titik akhir REST yang dapat diakses dari dalam komputer virtual. Informasi tersedia melalui IP yang tidak dapat dialihkan dan tidak diekspos di luar VM.

Cakupan

Peristiwa terjadwal dikirimkan ke dan dapat diakui oleh:

• Virtual Machines Mandiri.
• Semua VM di layanan cloud Azure (klasik).
• Semua VM dalam set ketersediaan.
• Semua komputer virtual di grup penempatan set skala.

Peristiwa Terjadwal untuk semua komputer virtual (VM) di seluruh Set Ketersediaan atau Grup Penempatan untuk Set Skala Komputer Virtual dikirimkan ke semua VM lain dalam grup yang sama atau diatur terlepas dari penggunaan Zona Ketersediaan.

Akibatnya, periksa bidang Resources pada peristiwa tersebut untuk mengidentifikasi VM mana yang terpengaruh.

Penemuan titik akhir

Untuk VM dengan dukungan VNET, Metadata Service tersedia dari IP statis yang tidak dapat dirutekan, 169.254.169.254. Titik akhir lengkap untuk versi terbaru Aktivitas Terjadwal adalah:

http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Jika VM tidak dibuat dalam Virtual Network, kasus default untuk layanan cloud dan VM klasik, logika tambahan diperlukan untuk menemukan alamat IP yang akan digunakan. Untuk mempelajari cara menemukan titik akhir host, lihat sampel ini.

Ketersediaan versi dan wilayah

Layanan Peristiwa Terjadwal berversi. Versi adalah wajib; versi saat ini adalah 2020-07-01.

Mengaktifkan dan menonaktifkan Peristiwa Terjadwal

Peristiwa Terjadwal diaktifkan untuk layanan Anda saat pertama kali mengajukan permintaan untuk peristiwa. Anda akan mengharapkan respons tertunda dalam panggilan pertama Anda hingga dua menit dan Anda akan mulai menerima peristiwa dalam waktu 5 menit. Peristiwa Terjadwal dinonaktifkan untuk layanan Anda jika tidak membuat permintaan ke titik akhir selama 24 jam.

Pemeliharaan yang dimulai pengguna

Pemeliharaan VM yang dimulai pengguna melalui portal Azure, API, CLI, atau PowerShell menghasilkan peristiwa terjadwal. Anda kemudian dapat menguji logika persiapan pemeliharaan di aplikasi Anda dan aplikasi Anda dapat mempersiapkan pemeliharaan yang dimulai pengguna.

Jika Anda menghidupkan ulang VM, peristiwa dengan jenis Reboot akan dijadwalkan. Jika Anda menyebarkan ulang VM, peristiwa dengan jenis Redeploy akan dijadwalkan. Biasanya peristiwa dengan sumber peristiwa pengguna dapat segera disetujui untuk menghindari keterlambatan pada tindakan yang dimulai pengguna. Kami menyarankan agar VM primer dan sekunder berkomunikasi dan menyetujui peristiwa terjadwal yang dihasilkan pengguna jika VM utama menjadi tidak responsif. Segera menyetujui peristiwa mencegah keterlambatan dalam memulihkan aplikasi Anda kembali ke keadaan yang baik.

Peristiwa terjadwal untuk peningkatan atau reimage OS Tamu Set Skala Komputer Virtual didukung untuk ukuran VM tujuan umum yang hanya mendukung pembaruan yang mempertahankan memori. Ini tidak bekerja untuk seri G, M, N, dan H. Peristiwa terjadwal untuk peningkatan dan reimage OS Tamu Set Skala Komputer Virtual dinonaktifkan secara default. Untuk mengaktifkan peristiwa terjadwal untuk operasi ini pada ukuran VM yang didukung, pertama-tama aktifkan menggunakan OSImageNotificationProfile.

Gunakan API

Gambaran umum tingkat tinggi

Ada dua komponen utama untuk menangani Peristiwa Terjadwal, persiapan, dan pemulihan. Semua peristiwa terjadwal saat ini yang berdampak pada VM tersedia untuk dibaca melalui titik akhir Peristiwa Terjadwal IMDS. Ketika peristiwa telah mencapai status terminal, peristiwa tersebut dihapus dari daftar peristiwa. Diagram berikut menunjukkan berbagai transisi status yang dapat dialami oleh satu peristiwa terjadwal:

Untuk peristiwa dalam status EventStatus:"Scheduled", Anda harus mengambil langkah-langkah untuk menyiapkan beban kerja Anda. Setelah persiapan selesai, Anda kemudian harus menyetujui acara menggunakan API peristiwa terjadwal. Jika tidak, peristiwa secara otomatis disetujui ketika waktu NotBefore tercapai. Jika VM berada pada infrastruktur bersama, sistem kemudian akan menunggu semua penyewa lain pada perangkat keras yang sama untuk juga menyetujui pekerjaan atau batas waktu. Setelah persetujuan dikumpulkan dari semua VM yang terkena dampak atau waktu NotBefore tercapai, Azure menghasilkan payload peristiwa terjadwal baru dengan EventStatus:"Started" dan memicu dimulainya peristiwa pemeliharaan. Ketika peristiwa telah mencapai status terminal, peristiwa tersebut dihapus dari daftar peristiwa. Itu berfungsi sebagai sinyal bagi pelanggan untuk memulihkan VM mereka.

Di bawah ini adalah kode psudeo yang menunjukkan proses tentang cara membaca dan mengelola peristiwa terjadwal di aplikasi Anda:

current_list_of_scheduled_events = get_latest_from_se_endpoint()
#prepare for new events
for each event in current_list_of_scheduled_events:
  if event not in previous_list_of_scheduled_events:
    prepare_for_event(event)
#recover from completed events
for each event in previous_list_of_scheduled_events:
  if event not in current_list_of_scheduled_events:
    receover_from_event(event)
#prepare for future jobs
previous_list_of_scheduled_events = current_list_of_scheduled_events

Karena peristiwa terjadwal sering digunakan untuk aplikasi dengan persyaratan ketersediaan tinggi, ada beberapa kasus luar biasa yang harus dipertimbangkan:

1. Setelah acara terjadwal selesai dan dihapus dari array, tidak akan ada dampak lebih lanjut tanpa peristiwa baru termasuk peristiwa EventStatus:"Terjadwal" lain
2. Azure memantau operasi pemeliharaan di seluruh armada dan dalam keadaan yang jarang terjadi menentukan bahwa operasi pemeliharaan berisiko terlalu tinggi untuk diterapkan. Dalam hal ini acara terjadwal akan langsung dari "Terjadwal" ke dihapus dari array peristiwa
3. Dalam kasus kegagalan perangkat keras, Azure melewati status "Terjadwal" dan segera pindah ke status EventStatus:"Started".
4. Meskipun peristiwa masih dalam status EventStatus:"Started", mungkin ada dampak lain dari durasi yang lebih pendek daripada apa yang diiklankan dalam peristiwa terjadwal.

Sebagai bagian dari jaminan ketersediaan Azure, VM di domain kesalahan yang berbeda tidak akan terpengaruh oleh operasi pemeliharaan rutin secara bersamaan. Namun, mereka mungkin memiliki operasi yang diserialisasikan satu demi satu. VM dalam satu domain kesalahan dapat menerima peristiwa terjadwal dengan EventStatus:"Terjadwal" segera setelah pemeliharaan domain kesalahan lain selesai. Terlepas dari arsitektur apa yang Anda pilih, selalu terus periksa peristiwa baru yang tertunda terhadap VM Anda.

Meskipun waktu kejadian yang tepat bervariasi, diagram berikut memberikan pedoman kasar tentang bagaimana operasi pemeliharaan umum berlangsung:

• EventStatus:"Scheduled" untuk Batas Waktu Persetujuan: 15 menit
• Durasi Dampak: 7 detik
• EventStatus:"Started" to Completed (peristiwa dihapus dari Array peristiwa): 10 menit

Semua operasi yang berdampak pada ketersediaan VM akan mengakibatkan peristiwa terjadwal, namun tidak semua peristiwa terjadwal akan muncul di permukaan Azure lainnya seperti Log Aktivitas Azure atau Kesehatan Sumber Daya. Memeriksa peristiwa terjadwal secara teratur akan memastikan bahwa Anda memiliki informasi terbaru tentang dampak yang akan datang ke VM Anda.

Header

Saat meminta Metadata Service, Anda harus memberikan header Metadata:true untuk memastikan permintaan tidak dialihkan secara tidak sengaja. Header Metadata:true diperlukan untuk semua permintaan peristiwa terjadwal. Kegagalan untuk menyertakan header dalam permintaan menghasilkan respons "Permintaan Buruk" dari Metadata Service.

Permintaan untuk peristiwa

Anda bisa meminta peristiwa terjadwal dengan melakukan panggilan berikut:

Sampel bash

curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Sampel PowerShell

Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -Uri "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" | ConvertTo-Json -Depth 64

Sampel Python

import json
import requests

metadata_url ="http://169.254.169.254/metadata/scheduledevents"
header = {'Metadata' : 'true'}
query_params = {'api-version':'2020-07-01'}

def get_scheduled_events():           
    resp = requests.get(metadata_url, headers = header, params = query_params)
    data = resp.json()
    return data

Respons berisi array aktivitas terjadwal. Array yang kosong berarti saat ini tidak ada peristiwa yang dijadwalkan. Dalam kasus di mana ada aktivitas terjadwal, respons berisi array aktivitas.

{
    "DocumentIncarnation": {IncarnationID},
    "Events": [
        {
            "EventId": {eventID},
            "EventType": "Reboot" | "Redeploy" | "Freeze" | "Preempt" | "Terminate",
            "ResourceType": "VirtualMachine",
            "Resources": [{resourceName}],
            "EventStatus": "Scheduled" | "Started",
            "NotBefore": {timeInUTC},       
            "Description": {eventDescription},
            "EventSource" : "Platform" | "User",
            "DurationInSeconds" : {timeInSeconds},
        }
    ]
}

Properti kejadian

Penjadwalan peristiwa

Setiap peristiwa dijadwalkan dengan jumlah waktu minimum di masa mendatang berdasarkan jenis peristiwa. Waktu ini tercermin dalam properti NotBefore peristiwa.

Ini berarti Anda dapat mendeteksi jadwal peristiwa di masa mendatang setidaknya dengan waktu pemberitahuan minimum sebelum peristiwa terjadi. Setelah acara dijadwalkan, acara akan berpindah ke status Started setelah disetujui atau NotBefore waktu berlalu. Namun, dalam kasus yang jarang terjadi, operasi akan dibatalkan oleh Azure sebelum dimulai. Dalam hal ini peristiwa akan dihapus dari array Peristiwa, dan dampaknya tidak akan terjadi seperti yang dijadwalkan sebelumnya.

Frekuensi polling

Anda dapat melakukan polling titik akhir untuk pembaruan sesering atau sejarang seperti yang Anda suka. Namun, semakin lama waktu antar permintaan, semakin banyak waktu yang berpotensi hilang untuk bereaksi terhadap peristiwa yang akan datang. Sebagian besar peristiwa memiliki pemberitahuan 5 hingga 15 menit sebelumnya, meskipun dalam beberapa kasus pemberitahuan sebelumnya mungkin hanya 30 detik. Untuk memastikan bahwa Anda memiliki waktu sebanyak mungkin untuk mengambil tindakan mitigasi, sebaiknya lakukan polling layanan sekali per detik.

Memulai peristiwa

Setelah mempelajari peristiwa yang akan datang dan menyelesaikan logika Anda untuk pematian yang lancar, Anda dapat menyetujui peristiwa yang belum selesai dengan membuat panggilan POST ke Metadata Service dengan EventId. Panggilan ini menunjukkan kepada Azure bahwa panggilan tersebut dapat mempersingkat waktu pemberitahuan minimum (jika memungkinkan). Peristiwa mungkin tidak segera dimulai setelah disetujui, dalam beberapa kasus Azure memerlukan persetujuan semua VM yang dihosting pada simpul sebelum melanjutkan acara.

Sampel JSON berikut diharapkan dalam isi permintaan POST. Permintaan harus berisi daftar StartRequests. Masing-masing StartRequest berisi EventId untuk peristiwa yang ingin Anda percepat:

{
	"StartRequests" : [
		{
			"EventId": {EventId}
		}
	]
}

Layanan selalu mengembalikan 200 kode keberhasilan jika melewati ID peristiwa yang valid, bahkan jika VM lain sudah menyetujui peristiwa tersebut. Kode kesalahan 400 menunjukkan bahwa header permintaan atau payload salah format.

Sampel bash

curl -H Metadata:true -X POST -d '{"StartRequests": [{"EventId": "f020ba2e-3bc0-4c40-a10b-86575a9eabd5"}]}' http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01

Sampel PowerShell

Invoke-RestMethod -Headers @{"Metadata" = "true"} -Method POST -body '{"StartRequests": [{"EventId": "5DD55B64-45AD-49D3-BBC9-F57D4EA97BD7"}]}' -Uri http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01 | ConvertTo-Json -Depth 64

Sampel Python

import json
import requests

def confirm_scheduled_event(event_id):  
   # This payload confirms a single event with id event_id
   payload = json.dumps({"StartRequests": [{"EventId": event_id }]})
   response = requests.post("http://169.254.169.254/metadata/scheduledevents", 
                            headers =  {'Metadata' : 'true'}, 
                            params = {'api-version':'2020-07-01'}, 
                            data = payload)    
   return response.status_code

Contoh respons

Peristiwa berikut adalah contoh yang dilihat oleh dua VM yang dimigrasikan langsung ke node lain.

DocumentIncarnation berubah setiap kali ada informasi baru di Events. Persetujuan peristiwa akan memungkinkan pembekuan untuk melanjutkan WestNO_0 dan WestNO_1. Dari DurationInSeconds -1 menunjukkan bahwa platform tidak tahu berapa lama operasi akan berlangsung.

{
    "DocumentIncarnation":  1,
    "Events":  [
               ]
}

{
    "DocumentIncarnation":  2,
    "Events":  [
                   {
                       "EventId":  "C7061BAC-AFDC-4513-B24B-AA5F13A16123",
                       "EventStatus":  "Scheduled",
                       "EventType":  "Freeze",
                       "ResourceType":  "VirtualMachine",
                       "Resources":  [
                                         "WestNO_0",
                                         "WestNO_1"
                                     ],
                       "NotBefore":  "Mon, 11 Apr 2022 22:26:58 GMT",
                       "Description":  "Virtual machine is being paused because of a memory-preserving Live Migration operation.",
                       "EventSource":  "Platform",
                       "DurationInSeconds":  5
                   }
               ]
}

{
    "DocumentIncarnation":  3,
    "Events":  [
                   {
                       "EventId":  "C7061BAC-AFDC-4513-B24B-AA5F13A16123",
                       "EventStatus":  "Started",
                       "EventType":  "Freeze",
                       "ResourceType":  "VirtualMachine",
                       "Resources":  [
                                         "WestNO_0",
                                         "WestNO_1"
                                     ],
                       "NotBefore":  "",
                       "Description":  "Virtual machine is being paused because of a memory-preserving Live Migration operation.",
                       "EventSource":  "Platform",
                       "DurationInSeconds":  5
                   }
               ]
}

{
    "DocumentIncarnation":  4,
    "Events":  [
               ]
}

Sampel Python

Sampel berikut meminta Metadata Service untuk peristiwa terjadwal dan menyetujui setiap peristiwa yang belum selesai:

#!/usr/bin/python
import json
import requests
from time import sleep

# The URL to access the metadata service
metadata_url ="http://169.254.169.254/metadata/scheduledevents"
# This must be sent otherwise the request will be ignored
header = {'Metadata' : 'true'}
# Current version of the API
query_params = {'api-version':'2020-07-01'}

def get_scheduled_events():           
    resp = requests.get(metadata_url, headers = header, params = query_params)
    data = resp.json()
    return data

def confirm_scheduled_event(event_id):  
    # This payload confirms a single event with id event_id
    # You can confirm multiple events in a single request if needed      
    payload = json.dumps({"StartRequests": [{"EventId": event_id }]})
    response = requests.post(metadata_url, 
                            headers= header,
                            params = query_params, 
                            data = payload)    
    return response.status_code

def log(event): 
    # This is an optional placeholder for logging events to your system 
    print(event["Description"])
    return

def advanced_sample(last_document_incarnation): 
    # Poll every second to see if there are new scheduled events to process
    # Since some events may have necessarily short warning periods, it is 
    # recommended to poll frequently
    found_document_incarnation = last_document_incarnation
    while (last_document_incarnation == found_document_incarnation):
        sleep(1)
        payload = get_scheduled_events()    
        found_document_incarnation = payload["DocumentIncarnation"]        
        
    # We recommend processing all events in a document together, 
    # even if you won't be actioning on them right away
    for event in payload["Events"]:

        # Events that have already started, logged for tracking
        if (event["EventStatus"] == "Started"):
            log(event)
            
        # Approve all user initiated events. These are typically created by an 
        # administrator and approving them immediately can help to avoid delays 
        # in admin actions
        elif (event["EventSource"] == "User"):
            confirm_scheduled_event(event["EventId"])            
            
        # For this application, freeze events less that 9 seconds are considered
        # no impact. This will immediately approve them
        elif (event["EventType"] == "Freeze" and 
            int(event["DurationInSeconds"]) >= 0  and 
            int(event["DurationInSeconds"]) < 9):
            confirm_scheduled_event(event["EventId"])
            
        # Events that may be impactful (for example, reboot or redeploy) may need custom 
        # handling for your application
        else: 
            #TODO Custom handling for impactful events
            log(event)
    print("Processed events from document: " + str(found_document_incarnation))
    return found_document_incarnation

def main():
    # This will track the last set of events seen 
    last_document_incarnation = "-1"

    input_text = "\
        Press 1 to poll for new events \n\
        Press 2 to exit \n "
    program_exit = False 

    while program_exit == False:
        user_input = input(input_text)    
        if (user_input == "1"):                        
            last_document_incarnation = advanced_sample(last_document_incarnation)
        elif (user_input == "2"):
            program_exit = True       

if __name__ == '__main__':
    main()

Langkah berikutnya

• Tinjau sampel kode Peristiwa Terjadwal di repositori GitHub Peristiwa Terjadwal Azure Instance Metadata.
• Tinjau contoh kode Peristiwa Terjadwal Node.js di GitHub Sampel Azure.
• Baca selengkapnya tentang API yang tersedia di Instance Metadata Service.
• Pelajari tentang pemeliharaan terencana untuk komputer virtual Linux di Azure.
• Pelajari cara mencatat peristiwa terjadwal dengan menggunakan Azure Event Hubs di Repositori GitHub Sampel Azure.