Perencanaan dan failover pemulihan bencana penyimpanan Azure

  • Artikel

Microsoft berusaha untuk memastikan bahwa layanan Azure selalu tersedia. Namun, pemadaman layanan yang tidak direncanakan dapat terjadi. Komponen utama dari rencana pemulihan bencana yang baik mencakup strategi untuk:

Artikel ini berfokus pada failover untuk akun penyimpanan yang berlebihan secara global (GRS, GZRS, dan RA-GZRS), dan cara merancang aplikasi Anda agar sangat tersedia jika ada pemadaman dan failover berikutnya.

Pilih opsi redundansi yang tepat

Azure Storage menyimpan beberapa salinan akun penyimpanan Anda untuk memastikan ketahanan dan ketersediaan tinggi. Opsi redundansi mana yang Anda pilih untuk akun Anda tergantung pada tingkat ketahanan yang Anda butuhkan untuk aplikasi Anda.

Dengan penyimpanan redundan lokal (LRS), tiga salinan akun penyimpanan Anda secara otomatis disimpan dan direplikasi dalam satu pusat data. Dengan penyimpanan zona redundan (ZRS), salinan disimpan dan direplikasi di masing-masing dari tiga zona ketersediaan terpisah dalam wilayah yang sama. Untuk informasi selengkapnya tentang zona ketersediaan, lihat Zona ketersediaan Azure.

Pemulihan satu salinan akun penyimpanan terjadi secara otomatis dengan LRS dan ZRS.

Penyimpanan dan failover yang berlebihan secara global

Dengan penyimpanan yang berlebihan secara global (GRS, GZRS, dan RA-GZRS), Azure menyalin data Anda secara asinkron ke wilayah geografis sekunder setidaknya ratusan mil jauhnya. Ini memungkinkan Anda memulihkan data jika ada pemadaman di wilayah utama. Fitur yang membedakan penyimpanan redundan global dari LRS dan ZRS adalah kemampuan untuk melakukan failover ke wilayah sekunder jika ada pemadaman di wilayah utama. Proses failover memperbarui entri DNS untuk titik akhir layanan akun penyimpanan Anda sehingga titik akhir untuk wilayah sekunder menjadi titik akhir utama baru untuk akun penyimpanan Anda. Setelah failover selesai, klien dapat mulai menulis ke titik akhir utama baru.

Konfigurasi redundansi RA-GRS dan RA-GZRS menyediakan penyimpanan geo-redundan dengan manfaat tambahan akses baca ke titik akhir sekunder jika ada pemadaman di wilayah utama. Jika pemadaman terjadi di titik akhir utama, aplikasi yang dikonfigurasi untuk akses baca ke wilayah sekunder dan dirancang untuk ketersediaan tinggi dapat terus membaca dari titik akhir sekunder. Microsoft merekomendasikan RA-GZRS untuk ketersediaan dan durabilitas maksimum akun penyimpanan Anda.

Untuk informasi selengkapnya tentang redundansi di Azure Storage, lihat Redundansi Azure Storage.

Merencanakan failover akun penyimpanan

Akun Azure Storage mendukung dua jenis failover:

  • Failover yang dikelola pelanggan - Pelanggan dapat mengelola failover akun penyimpanan jika ada pemadaman layanan yang tidak terduga.
  • Failover yang dikelola Microsoft - Berpotensi dimulai oleh Microsoft hanya dalam kasus bencana parah di wilayah utama. 1,2

1Failover yang dikelola Microsoft tidak dapat dimulai untuk akun penyimpanan individu, langganan, atau penyewa. Untuk detail selengkapnya, lihat Failover yang dikelola Microsoft.
2 Rencana pemulihan bencana Anda harus didasarkan pada failover yang dikelola pelanggan. Jangan mengandalkan failover yang dikelola Microsoft, yang hanya akan digunakan dalam keadaan ekstrem.

Setiap jenis failover memiliki serangkaian kasus penggunaan yang unik, harapan yang sesuai untuk kehilangan data, dan dukungan untuk akun dengan namespace hierarki yang diaktifkan (Azure Data Lake Storage Gen2). Tabel ini meringkas aspek-aspek dari setiap jenis failover :

Jenis Cakupan Failover Gunakan huruf besar Kehilangan data yang diharapkan HNS didukung
Dikelola Pelanggan Akun Penyimpanan Titik akhir layanan penyimpanan untuk wilayah utama menjadi tidak tersedia, tetapi wilayah sekunder tersedia.

Anda menerima Azure Advisory di mana Microsoft menyarankan Anda untuk melakukan operasi failover akun penyimpanan yang berpotensi terpengaruh oleh pemadaman.		 Ya Ya (Dalam pratinjau)
Dikelola Microsoft Seluruh wilayah atau unit skala Wilayah utama menjadi benar-benar tidak tersedia karena bencana yang signifikan, tetapi wilayah sekunder tersedia. Ya Ya

Failover yang dikelola pelanggan

Jika titik akhir data untuk layanan penyimpanan di akun penyimpanan Anda menjadi tidak tersedia di wilayah utama, Anda dapat melakukan failover ke wilayah sekunder. Setelah failover selesai, wilayah sekunder menjadi primer baru dan pengguna dapat melanjutkan untuk mengakses data di wilayah utama baru.

Untuk sepenuhnya memahami dampak kegagalan akun yang dikelola pelanggan terhadap pengguna dan aplikasi Anda, sangat membantu untuk mengetahui apa yang terjadi selama setiap langkah proses failover dan failback. Untuk detail tentang cara kerja proses, lihat Cara kerja failover akun penyimpanan yang dikelola pelanggan.

Failover yang dikelola Microsoft

Dalam keadaan ekstrem di mana wilayah utama asli dianggap tidak dapat dipulihkan dalam jumlah waktu yang wajar karena bencana besar, Microsoft dapat memulai failover regional. Dalam hal ini, Anda tidak perlu melakukan tindakan apa pun. Hingga kegagalan yang dikelola Microsoft selesai, Anda tidak akan memiliki akses tulis ke akun penyimpanan Anda. Aplikasi Anda dapat membaca dari wilayah sekunder jika akun penyimpanan Anda dikonfigurasi untuk RA-GRS atau RA-GZRS.

Penting

Rencana pemulihan bencana Anda harus didasarkan pada failover yang dikelola pelanggan. Jangan mengandalkan failover yang dikelola Microsoft, yang mungkin hanya digunakan dalam keadaan ekstrem. Failover yang dikelola Microsoft akan dimulai untuk seluruh unit fisik, seperti wilayah atau unit skala. Ini tidak dapat dimulai untuk akun penyimpanan individu, langganan, atau penyewa. Untuk kemampuan untuk secara selektif melakukan failover akun penyimpanan individual Anda, gunakan failover akun yang dikelola pelanggan.

Mengantisipasi kehilangan data dan inkonsistensi

Perhatian

Failover akun penyimpanan biasanya melibatkan beberapa kehilangan data, dan berpotensi inkonsistensi file dan data. Dalam rencana pemulihan bencana Anda, penting untuk mempertimbangkan dampak yang akan terjadi pada failover akun pada data Anda sebelum memulainya.

Karena data ditulis secara asinkron dari wilayah utama ke wilayah sekunder, selalu ada penundaan sebelum penulisan ke wilayah utama disalin ke sekunder. Jika wilayah utama menjadi tidak tersedia, tulisan terbaru mungkin belum disalin ke sekunder.

Ketika failover terjadi, semua data di wilayah utama hilang karena wilayah sekunder menjadi primer baru. Semua data yang sudah disalin ke sekunder dipertahankan ketika kegagalan terjadi. Namun, data apa pun yang ditulis ke primer yang belum juga disalin ke wilayah sekunder hilang secara permanen.

Wilayah utama baru dikonfigurasi menjadi redundan lokal (LRS) setelah failover.

Anda juga mungkin mengalami inkonsistensi file atau data jika akun penyimpanan Anda mengaktifkan satu atau beberapa hal berikut:

Waktu sinkronasi terakhir

Properti Waktu Sinkronisasi Terakhir menunjukkan waktu terbaru bahwa data dari wilayah utama dijamin telah ditulis ke wilayah sekunder. Untuk akun yang memiliki namespace hierarkis, properti Waktu Sinkronisasi Terakhir yang sama juga berlaku untuk metadata yang dikelola oleh namespace hierarkis, termasuk ACL. Semua data dan metadata yang ditulis sebelum waktu sinkronisasi terakhir tersedia pada sekunder, sementara data dan metadata yang ditulis setelah waktu sinkronisasi terakhir mungkin tidak ditulis ke sekunder, dan mungkin hilang. Gunakan properti ini jika ada pemadaman untuk memperkirakan jumlah kehilangan data yang mungkin Anda timbulkan dengan memulai failover akun.

Sebagai praktik terbaik, rancang aplikasi Anda sehingga Anda dapat menggunakan waktu sinkronisasi terakhir untuk mengevaluasi hilangnya data yang diharapkan. Misalnya, jika Anda mencatat semua operasi tulis, maka Anda dapat membandingkan waktu operasi tulis terakhir Anda dengan waktu sinkronisasi terakhir untuk menentukan penulisan mana yang belum disinkronkan ke sekunder.

Untuk informasi selengkapnya tentang memeriksa properti Waktu Sinkronisasi Terakhir, lihat Memeriksa properti Waktu Sinkronisasi Terakhir untuk akun penyimpanan.

Konsistensi file untuk Azure Data Lake Storage Gen2

Replikasi untuk akun penyimpanan dengan namespace hierarkis diaktifkan (Azure Data Lake Storage Gen2) terjadi di tingkat file. Ini berarti jika pemadaman di wilayah utama terjadi, ada kemungkinan hanya beberapa file dalam kontainer atau direktori yang mungkin berhasil direplikasi ke wilayah sekunder. Konsistensi untuk semua file dalam kontainer atau direktori setelah failover akun penyimpanan tidak dijamin.

Mengubah inkonsistensi data umpan dan blob

Failover akun penyimpanan akun penyimpanan geo-redundan dengan umpan perubahan diaktifkan dapat mengakibatkan inkonsistensi antara log umpan perubahan dan data blob dan/atau metadata. Inkonsistensi tersebut dapat dihasilkan dari sifat asinkron dari kedua pembaruan pada log perubahan dan replikasi data blob dari wilayah utama ke sekunder. Satu-satunya situasi di mana inkonsistensi tidak akan diharapkan adalah ketika semua rekaman log saat ini telah berhasil dihapuskan ke file log, dan semua data penyimpanan telah berhasil direplikasi dari wilayah utama ke sekunder.

Untuk informasi tentang cara kerja umpan perubahan, lihat Cara kerja umpan perubahan.

Perlu diingat bahwa fitur akun penyimpanan lainnya mengharuskan umpan perubahan diaktifkan seperti pencadangan operasional Azure Blob Storage, Replikasi objek, dan pemulihan Point-in-time untuk blob blok.

Inkonsistensi pemulihan titik waktu

Failover yang dikelola pelanggan didukung untuk akun penyimpanan tingkat standar v2 tujuan umum yang menyertakan blob blok. Namun, melakukan failover yang dikelola pelanggan pada akun penyimpanan mengatur ulang titik pemulihan paling awal yang mungkin untuk akun tersebut. Data untuk pemulihan Point-in-time untuk blob blok hanya konsisten hingga waktu penyelesaian failover. Akibatnya, Anda hanya dapat memulihkan blob blok ke titik waktu tidak lebih awal dari waktu penyelesaian failover. Anda dapat memeriksa waktu penyelesaian failover di tab redundansi akun penyimpanan Anda di Portal Microsoft Azure.

Misalnya, Anda telah menetapkan periode penyimpanan ke 30 hari. Jika telah berlalu lebih dari 30 hari sejak failover, Anda dapat memulihkan ke titik mana pun dalam 30 hari tersebut. Namun, jika kurang dari 30 hari telah berlalu sejak failover, maka Anda tidak dapat memulihkan ke titik sebelum failover, terlepas dari periode retensi. Misalnya, jika sudah lebih dari 10 hari sejak failover, titik pemulihan paling awal adalah 10 hari sebelumnya, bukan 30 hari di masa lalu.

Waktu dan biaya failover

Waktu yang diperlukan untuk failover selesai setelah dimulai dapat bervariasi, meskipun biasanya membutuhkan waktu kurang dari satu jam.

Failover yang dikelola pelanggan kehilangan geo-redundansinya setelah failover (dan failback). Akun penyimpanan Anda secara otomatis dikonversi ke penyimpanan redundan lokal (LRS) di wilayah utama baru selama failover, dan akun penyimpanan di wilayah utama asli dihapus.

Anda dapat mengaktifkan kembali penyimpanan geo-redundan (GRS) atau penyimpanan geo-redundan akses baca (RA-GRS) untuk akun tersebut, tetapi perhatikan bahwa mengonversi dari LRS ke GRS atau RA-GRS dikenakan biaya tambahan. Biaya tersebut ditimbulkan oleh biaya pengambilan data dari jaringan untuk mereplikasi ulang data ke wilayah sekunder baru. Selain itu, semua blob yang diarsipkan perlu direhidrasi ke tingkat online sebelum akun dapat dikonfigurasi untuk geo-redundansi, yang akan dikenakan biaya. Untuk informasi selengkapnya tentang harga, lihat:

Setelah mengaktifkan kembali GRS untuk akun penyimpanan Anda, Microsoft mulai mereplikasi data di akun Anda ke wilayah sekunder yang baru. Waktu replikasi tergantung pada banyak faktor, antara lain:

  • Jumlah dan ukuran objek di akun penyimpanan. Mereplikasi banyak objek kecil dapat memakan waktu lebih lama daripada mereplikasi objek yang lebih sedikit dan lebih besar.
  • Sumber daya yang tersedia untuk replikasi latar belakang, seperti CPU, memori, disk, dan kapasitas WAN. Lalu lintas langsung lebih diprioritaskan daripada replikasi geografis.
  • Jika akun penyimpanan Anda berisi blob, jumlah rekam jepret per blob.
  • Jika akun penyimpanan Anda berisi tabel, strategi pemartisian data. Proses replikasi tidak dapat diskalakan melebihi jumlah kunci partisi yang Anda gunakan.

Jenis akun penyimpanan yang didukung

Semua penawaran geo-redundan mendukung failover yang dikelola Microsoft. Selain itu, beberapa jenis akun mendukung failover akun yang dikelola pelanggan, seperti yang diperlihatkan dalam tabel berikut:

Jenis failover GRS/RA-GRS GZRS/RA-GZRS
Failover yang dikelola pelanggan Akun tujuan umum v2
Akun tujuan umum v1
Akun warisan Blob Storage		 Akun tujuan umum v2
Failover yang dikelola Microsoft Semua jenis akun Akun tujuan umum v2

Akun penyimpanan klasik

Penting

Failover akun yang dikelola pelanggan hanya didukung untuk akun penyimpanan yang disebarkan menggunakan model penyebaran Azure Resource Manager (ARM). Model penyebaran Azure Service Manager (ASM), juga dikenal sebagai klasik, tidak didukung. Untuk membuat akun penyimpanan klasik memenuhi syarat untuk failover akun yang dikelola pelanggan, akun tersebut harus terlebih dahulu dimigrasikan ke model ARM. Akun penyimpanan Anda harus dapat diakses untuk melakukan peningkatan, sehingga wilayah utama saat ini tidak dapat berada dalam status gagal.

jika ada bencana yang memengaruhi wilayah utama, Microsoft akan mengelola failover untuk akun penyimpanan klasik. Untuk informasi lebih lanjut, lihat Failover yang dikelola Microsoft.

Azure Data Lake Storage Gen2

Penting

Failover akun yang dikelola pelanggan untuk akun yang memiliki namespace hierarkis (Azure Data Lake Storage Gen2) saat ini dalam PRATINJAU dan hanya didukung di wilayah berikut:

  • (Asia Pasifik) India Tengah
  • (Asia Pasifik) Asia Tenggara
  • (Eropa) Eropa Utara
  • (Eropa) Swiss Utara
  • (Eropa) Swiss Barat
  • (Eropa) Eropa Barat
  • (Amerika Utara) Kanada Tengah
  • (Amerika Utara): US Timur 2
  • (Amerika Utara) US Tengah Selatan

Untuk ikut serta dalam pratinjau, lihat Menyiapkan fitur pratinjau di langganan Azure dan menentukan AllowHNSAccountFailover sebagai nama fitur.

Lihat Ketentuan Penggunaan Tambahan untuk Pratinjau Microsoft Azure untuk persyaratan hukum yang berlaku pada fitur Azure dalam versi beta, pratinjau, atau belum dirilis secara umum.

jika ada bencana signifikan yang memengaruhi wilayah utama, Microsoft akan mengelola failover untuk akun dengan namespace hierarkis. Untuk informasi lebih lanjut, lihat Failover yang dikelola Microsoft.

Fitur dan layanan yang tidak didukung

Fitur dan layanan berikut tidak didukung untuk failover akun:

  • Azure File Sync tidak mendukung failover akun penyimpanan yang dimulai pelanggan. Akun penyimpanan yang berisi berbagi file Azure yang digunakan sebagai titik akhir cloud di Azure File Sync seharusnya tidak gagal. Melakukannya akan menyebabkan sinkronisasi berhenti berfungsi dan mungkin juga menyebabkan kehilangan data yang tidak terduga dalam kasus file yang baru diberi tingkat. Untuk informasi selengkapnya, lihat Praktik terbaik untuk pemulihan bencana dengan Azure File Sync untuk detailnya.
  • Akun penyimpanan yang berisi blob blok premium tidak dapat di-failover. Akun penyimpanan yang mendukung blob blok premium saat ini tidak mendukung geo-redundansi.
  • Failover yang dikelola pelanggan tidak didukung untuk akun sumber atau tujuan dalam kebijakan replikasi objek.
  • Untuk failover akun dengan SSH File Transfer Protocol (SFTP) diaktifkan, Anda harus terlebih dahulu menonaktifkan SFTP untuk akun tersebut. Jika Anda ingin melanjutkan menggunakan SFTP setelah failover selesai, cukup aktifkan kembali.
  • Network File System (NFS) 3.0 (NFSv3) tidak didukung untuk failover akun penyimpanan. Anda tidak dapat membuat akun penyimpanan yang dikonfigurasi untuk redundansi global dengan NFSv3 diaktifkan.

Failover bukan untuk migrasi akun

Failover akun penyimpanan tidak boleh digunakan sebagai bagian dari strategi migrasi data Anda. Failover adalah solusi sementara untuk pemadaman layanan. Untuk informasi tentang cara memigrasikan akun penyimpanan Anda, lihat Gambaran umum migrasi Azure Storage.

Akun penyimpanan yang berisi blob yang diarsipkan

Akun penyimpanan yang berisi kegagalan akun dukungan blob yang diarsipkan. Namun, setelah failover yang dikelola pelanggan selesai, semua blob yang diarsipkan perlu direhidrasi ke tingkat online sebelum akun dapat dikonfigurasi untuk geo-redundansi.

Penyedia sumber daya penyimpanan

Microsoft menyediakan dua REST API untuk bekerja dengan sumber daya Azure Storage. API ini merupakan dasar dari semua tindakan yang dapat Anda lakukan terhadap Azure Storage. Azure Storage REST API memungkinkan Anda bekerja dengan data di akun penyimpanan Anda, termasuk data blob, antrean, file, dan tabel. REST API penyedia sumber daya Azure Storage memungkinkan Anda mengelola akun penyimpanan dan sumber daya terkait.

Setelah kegagalan selesai, klien dapat kembali membaca dan menulis data Azure Storage di wilayah utama baru. Namun, penyedia sumber daya Azure Storage tidak gagal, sehingga operasi manajemen sumber daya masih harus berlangsung di wilayah utama. Jika wilayah utama tidak tersedia, Anda tidak akan dapat melakukan operasi manajemen pada akun penyimpanan.

Karena penyedia sumber daya Azure Storage tidak gagal, properti Lokasi akan mengembalikan lokasi utama asli setelah kegagalan selesai.

Komputer virtual Azure

Komputer virtual (VM) Azure tidak gagal sebagai bagian dari failover akun. Jika wilayah utama menjadi tidak tersedia, dan Anda gagal ke wilayah sekunder, maka Anda harus membuat ulang VM setelah kegagalan. Selain itu, ada potensi kehilangan data yang terkait dengan failover akun. Microsoft merekomendasikan untuk mengikuti panduan ketersediaan tinggi dan pemulihan bencana khusus untuk komputer virtual di Azure.

Perlu diingat bahwa data apa pun yang disimpan dalam disk sementara hilang saat VM dimatikan.

Disk tidak terkelola Azure

Sebagai praktik terbaik, Microsoft merekomendasikan untuk mengonversi disk yang tidak dikelola ke disk terkelola. Namun, jika Anda perlu menggagalkan akun yang berisi disk yang tidak dikelola yang terpasang pada Azure VM, Anda harus mematikan VM sebelum memulai kegagalan.

Disk yang tidak dikelola disimpan sebagai blob halaman di Azure Storage. Saat VM berjalan di Azure, disk apa pun yang tidak dikelola yang terpasang pada VM disewakan. Failover akun tidak dapat dilanjutkan ketika ada sewa pada blob. Untuk melakukan kegagalan, ikuti langkah-langkah berikut:

  1. Sebelum Anda mulai, perhatikan nama disk yang tidak dikelola, nomor unit logis (LUN), dan VM yang dilampirkan. Melakukannya akan membuatnya lebih mudah untuk melampirkan ulang disk setelah kegagalan.
  2. Matikan VM-nya.
  3. Hapus VM, tetapi pertahankan file VHD untuk disk yang tidak dikelola. Perhatikan waktu saat Anda menghapus VM.
  4. Tunggu hingga Waktu Sinkronisasi Terakhir telah diperbarui, dan lebih baru dari waktu Anda menghapus VM. Langkah ini penting, karena jika titik akhir sekunder belum sepenuhnya diperbarui dengan file VHD ketika failover terjadi, maka VM mungkin tidak berfungsi dengan baik di wilayah utama baru.
  5. Memulai kegagalan akun.
  6. Tunggu hingga kegagalan akun selesai dan wilayah sekunder telah menjadi wilayah utama baru.
  7. Buat VM di wilayah utama baru dan melampirkan ulang VHD.
  8. Mulai VM baru.

Perlu diingat bahwa data apa pun yang disimpan dalam disk sementara hilang saat VM dimatikan.

Menyalin data sebagai alternatif untuk failover

Jika akun penyimpanan Anda dikonfigurasi untuk akses baca ke wilayah sekunder, maka Anda dapat merancang aplikasi Anda untuk dibaca dari titik akhir sekunder. Jika Anda lebih suka tidak melakukan failover jika ada pemadaman di wilayah utama, Anda dapat menggunakan alat seperti AzCopy atau Azure PowerShell untuk menyalin data dari akun penyimpanan Anda di wilayah sekunder ke akun penyimpanan lain di wilayah yang tidak terpengaruh. Anda kemudian dapat mengarahkan aplikasi ke akun penyimpanan tersebut untuk ketersediaan baca dan tulis.

Desain untuk ketersediaan tinggi

Penting untuk merancang aplikasi Anda untuk ketersediaan tinggi sejak awal. Lihat sumber daya Azure ini untuk panduan dalam mendesain aplikasi dan perencanaan Anda untuk pemulihan bencana:

Perlu diingat praktik terbaik ini untuk mempertahankan ketersediaan tinggi untuk data Azure Storage Anda:

  • Disks: Gunakan Azure Backup untuk mencadangkan disk VM yang digunakan oleh komputer virtual Azure Anda. Pertimbangkan juga untuk menggunakan Azure Site Recovery untuk melindungi VM Anda jika ada bencana regional.
  • Blob blok: Aktifkan penghapusan sementara untuk melindungi dari penghapusan dan penjaminan tingkat objek, atau salin blob blok ke akun penyimpanan lain di wilayah lain menggunakan AzCopy, Azure PowerShell, atau pustaka Azure Data Movement.
  • File: Gunakan Azure Backup untuk mencadangkan berbagi file Anda. Aktifkan juga penghapusan sementara untuk melindungi dari penghapusan berbagi file yang tidak disengaja. Untuk geo-redundansi saat GRS tidak tersedia, gunakan AzCopy atau Azure PowerShell untuk menyalin file Anda ke akun penyimpanan lain di wilayah lain.
  • Tabel: gunakan AzCopy untuk mengekspor data tabel ke akun penyimpanan lain di wilayah lain.

Melacak pemadaman

Pelanggan dapat berlangganan Dasbor Azure Service Health Dashboard untuk melacak kesehatan dan status Azure Storage dan layanan Azure lainnya.

Microsoft juga menyarankan agar Anda merancang aplikasi untuk mempersiapkan kemungkinan kegagalan tulis. Aplikasi Anda harus mengekspos kegagalan tulis dengan cara yang memperingatkan Anda tentang kemungkinan pemadaman di wilayah utama.

Lihat juga