Ketersediaan aplikasi di Azure Kubernetes Service di Azure Stack HCI dan Windows Server

Azure Kubernetes Service (AKS) di Azure Stack HCI dan Windows Server merupakan platform kontainer yang didukung penuh di mana Anda dapat menjalankan aplikasi cloud-native di Kubernetes, yang didasarkan pada platform orkestrasi kontainer Kubernetes. Arsitektur ini mendukung eksekusi beban kerja Windows dan Linux virtual di atas Azure Stack HCI dan Windows Server.

Arsitektur AKS di Azure Stack HCI dan Windows Server saat ini dibangun dengan pengklusteran failover serta migrasi langsung yang diaktifkan secara otomatis untuk kluster target (beban kerja). Selama berbagai peristiwa gangguan, mesin virtual yang menjadi tuan rumah beban kerja pelanggan akan bebas bergerak tanpa waktu henti aplikasi. Hal ini berarti bahwa pelanggan perusahaan tradisional yang mengangkat dan menggeser aplikasi lama sebagai database tunggal ke AKS di Azure Stack HCI dan Windows Server akan mendapatkan waktu aktif yang sama (atau lebih baik) daripada yang saat ini dialami saat menjalankan aplikasi lama di VM.

Topik ini menjelaskan sejumlah konsep dasar bagi pengguna yang ingin menjalankan aplikasi kontainer pada AKS di Azure Stack HCI dan Windows Server dengan mengaktifkan migrasi langsung untuk memastikan aplikasi tersedia selama gangguan. Terminologi Kubernetes, seperti gangguan sukarela dan gangguan tak disengaja, digunakan untuk merujuk pada waktu henti aplikasi yang berjalan dalam pod.

Apa itu migrasi langsung?

Migrasi langsung adalah fitur Hyper-V yang memungkinkan Anda memindahkan mesin virtual secara transparan dari satu host Hyper-V ke host lain tanpa waktu henti yang dirasakan. Manfaat utama dari migrasi langsung adalah fleksibilitas; menjalankan mesin virtual tidak terikat pada mesin host tunggal. Hal ini akan memungkinkan tindakan seperti menguras sejumlah mesin virtual tertentu sebelum menonaktifkan atau meningkatkan host. Ketika dipasangkan dengan Windows Pengklusteran Failover, migrasi langsung memungkinkan penciptaan sistem yang sangat tersedia dan toleran terhadap kesalahan.

Arsitektur AKS di Azure Stack HCI dan Windows Server saat ini mengasumsikan bahwa pelanggan mengaktifkan migrasi langsung di kluster lingkungan Azure Stack HCI mereka. Dalam hal ini, semua mesin virtual simpul pekerja Kubernetes akan dibuat dengan migrasi langsung yang dikonfigurasi. Node ini dapat dipindahkan di sekitar host fisik jika terjadi gangguan untuk memastikan platform sangat tersedia.

Diagram showing AKS on Azure Stack HCI and Windows Server with Failover Clustering enabled

Untuk pelanggan yang menjalankan aplikasi lama sebagai database tunggal di atas Kubernetes, arsitektur ini akan memenuhi kebutuhan ketersediaannya yang tinggi. Kubernetes akan mengelola penjadwalan pod pada node pekerja yang tersedia sementara migrasi langsung akan mengelola penjadwalan VM node pekerja pada host fisik yang tersedia.

Diagram showing an example legacy application running as a singleton

Skenario gangguan aplikasi

Studi komparatif tentang waktu pemulihan untuk aplikasi yang berjalan di VM pada AKS di Azure Stack HCI dan Windows Server dengan jelas menunjukkan bahwa ada dampak minimal pada aplikasi ketika peristiwa gangguan umum terjadi. Tiga contoh skenario gangguan meliputi:

  • Menerapkan pembaruan yang menghasilkan reboot mesin fisik.
  • Menerapkan pembaruan yang melibatkan pembuatan ulang node pekerja.
  • Kegagalan perangkat keras yang tidak direncanakan dari mesin fisik.

Catatan

Skenario ini mengasumsikan bahwa pemilik aplikasi masih menggunakan pengaturan afinitas dan anti-afinitas Kubernetes untuk memastikan penjadwalan pod yang tepat di seluruh node pekerja.

Peristiwa gangguan Menjalankan aplikasi di VM di Azure Stack HCI Menjalankan aplikasi di VM di AKS di Azure Stack HCI dan Windows Server
Menerapkan pembaruan yang menghasilkan reboot mesin fisik Tidak ada dampak Tidak ada dampak
Menerapkan pembaruan yang melibatkan pembuatan ulang node pekerja (atau me-reboot VM) Tidak ada dampak Bervariasi
Kegagalan perangkat keras yang tidak direncanakan dari mesin fisik 6-8 menit 6 –8 menit

Menerapkan pembaruan yang menghasilkan reboot mesin fisik

Selama acara pemeliharaan host fisik, seperti menerapkan pembaruan yang menghasilkan reboot mesin host, tidak ada dampak yang diharapkan untuk aplikasi yang berjalan di kluster. Administrator kluster akan menguras host dan memastikan bahwa semua VM akan bermigrasi langsung sebelum menerapkan pembaruan.

Menerapkan pembaruan yang melibatkan pembuatan ulang node pekerja

Skenario ini melibatkan menurunkan VM node pekerja untuk melakukan pemeliharaan rutin. Untuk mempersiapkan pembaruan, administrator kluster akan menguras dan mengisolasi node, sehingga semua pod digusur ke node pekerja yang tersedia sebelum menerapkan pembaruan. Setelah pembaruan selesai, node pekerja akan bergabung kembali dan tersedia untuk penjadwalan.

Catatan

Ketersediaan aplikasi akan bervariasi karena akan mencakup waktu yang dibutuhkan untuk mengunduh gambar kontainer dasar, terutama untuk gambar yang lebih besar yang disimpan di cloud publik. Oleh karena itu, disarankan Anda menggunakan gambar kontainer dasar kecil, dan untuk kontainer Windows, menggunakan gambar dasar nano server dianjurkan.

Kegagalan perangkat keras yang tidak direncanakan dari mesin fisik

Dalam skenario ini, peristiwa gangguan tak disengaja terjadi pada mesin fisik yang menampung kontainer/pod aplikasi lama di salah satu VM node pekerja. Pengklusteran failover akan menempatkan host dalam keadaan Terisolasi, dan kemudian setelah periode 6 hingga 8 menit, mulailah proses migrasi langsung VM ini ke host yang masih hidup. Dalam hal ini, waktu henti aplikasi setara dengan waktu yang dibutuhkan untuk me-restart VM node host dan worker.

Kesimpulan

Teknologi AKS di Azure Stack HCI dan Windows Server serta pengklusteran failover dirancang untuk memastikan bahwa lingkungan komputasi sangat tersedia dan toleran terhadap kesalahan. Namun, pemilik aplikasi masih harus mengkonfigurasi penyebaran untuk menggunakan fitur Kubernetes, seperti Deployments, Affinity Mapping, RelicaSets, untuk memastikan bahwa pod tangguh dalam skenario gangguan.