Bagikan melalui

Migrasi sumber daya database ke Azure global

  • Artikel

Penting

Sejak Agustus 2018, kami belum menerima pelanggan baru atau menyebarkan fitur dan layanan baru ke lokasi asli Cloud Microsoft Jerman.

Berdasarkan evolusi kebutuhan pelanggan, kami baru-baru ini meluncurkan dua wilayah pusat data baru di Jerman, yang menawarkan residensi data pelanggan, konektivitas penuh ke jaringan cloud global Microsoft, serta harga pasar yang kompetitif.

Selain itu, pada 30 September 2020, kami mengumumkan bahwa Cloud Microsoft Jerman akan dihentikan pada 29 Oktober 2021. Detail selengkapnya tersedia di sini: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Manfaatkan luasnya fungsionalitas, keamanan tingkat perusahaan, dan fitur lengkap yang tersedia di wilayah pusat data Jerman kami yang baru dengan bermigrasi hari ini.

Artikel ini berisi informasi yang dapat membantu Anda memigrasikan sumber daya database Azure dari Azure Jerman ke Azure global.

SQL Database

Untuk memigrasikan beban kerja Azure SQL Database yang lebih kecil, tanpa menyimpan database yang dimigrasikan secara online, gunakan fungsi ekspor untuk membuat file BACPAC. File BACPAC adalah file terkompresi (zip) yang berisi metadata dan data dari database SQL Server. Setelah membuat file BACPAC, Anda dapat menyalin file ke lingkungan target (misalnya, dengan menggunakan AzCopy) dan menggunakan fungsi impor untuk menyusun ulang database. Perhatikan pertimbangan berikut:

  • Agar ekspor konsisten secara transaksional, pastikan salah satu kondisi berikut terpenuhi:
    • Tidak ada aktivitas tulis selama ekspor.
    • Anda mengekspor dari salinan database SQL yang konsisten secara transaksional.
  • Untuk mengekspor ke penyimpanan Azure Blob, ukuran file BACPAC dibatasi hingga 200 GB. Untuk mengarsipkan file BACPAC yang lebih besar, ekspor ke penyimpanan lokal.
  • Jika operasi ekspor dari SQL Database memerlukan waktu lebih dari 20 jam, operasi ini mungkin dibatalkan. Lihat artikel berikut untuk tips tentang cara meningkatkan performa.

Catatan

String koneksi berubah setelah operasi ekspor karena nama DNS server berubah selama ekspor.

Untuk informasi selengkapnya:

Catatan

Sebaiknya Anda menggunakan modul Azure Az PowerShell untuk berinteraksi dengan Azure. Lihat Menginstal Azure PowerShell untuk memulai. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Memigrasi SQL Database menggunakan geo-replikasi aktif

Untuk database yang terlalu besar untuk file BACPAC, atau untuk migrasi dari satu cloud ke cloud lainnya dan tetap online dengan gangguan minimum, Anda dapat mengonfigurasi geo-replikasi aktif dari Azure Jerman ke Azure global.

Penting

Mengonfigurasi geo-replikasi aktif untuk memigrasikan database ke Azure global hanya didukung menggunakan Transact-SQL (T-SQL), dan sebelum bermigrasi, Anda harus meminta pengaktifan langganan Anda agar mendukung migrasi ke Azure global. Untuk mengajukan permintaan, Anda harus menggunakan tautan permintaan dukungan ini.

Catatan

Wilayah cloud global Azure, Jerman Barat Tengah dan Jerman Utara, adalah wilayah yang didukung untuk geo-replikasi aktif dengan cloud Azure Jerman. Jika wilayah Azure global alternatif ingin digunakan sebagai tujuan database akhir, rekomendasi setelah penyelesaian migrasi ke Azure global adalah mengonfigurasi tautan geo-replikasi tambahan dari Jerman Barat Tengah atau Jerman Utara ke wilayah cloud global Azure yang diperlukan.

Untuk detail tentang biaya geo-replikasi aktif, lihat bagian berjudul Geo-replikasi aktif di Harga Azure SQL Database.

Migrasi database dengan geo-replikasi aktif memerlukan server logis Azure SQL di Azure global. Anda dapat membuat server menggunakan portal, Azure PowerShell, Azure CLI, dll., tetapi konfigurasi geo-replikasi aktif untuk bermigrasi dari Azure Jerman ke Azure global hanya didukung menggunakan Transact-SQL (T-SQL).

Penting

Saat bermigrasi antara cloud, awalan nama server primer (Azure Jerman) dan sekunder (Azure global) harus berbeda. Jika nama server sama, eksekusi pernyataan ALTER DATABASE akan berhasil, tetapi migrasi akan gagal. Misalnya, jika awalan nama server utama adalah myserver (myserver.database.cloudapi.de), awalan nama server sekunder di Azure global tidak boleh myserver.

Pernyataan ini ALTER DATABASE memungkinkan Anda menentukan server target di Azure global dengan menggunakan nama server dns yang sepenuhnya memenuhi syarat di sisi target.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedbmewakili nama database di server Azure SQL di Azure Jerman.
  • public-server.database.windows.net mewakili nama server Azure SQL yang ada di Azure global, tempat database akan dimigrasikan. Namespace layanan "database.windows.net" diperlukan, ganti public-server dengan nama server SQL logis Anda di Azure global. Server di Azure global harus memiliki nama yang berbeda dari server utama di Azure Jerman.

Perintah dijalankan di database master pada server Azure Jerman yang menghosting database lokal yang akan dimigrasikan.

  • T-SQL start-copy API mengautentikasi pengguna yang masuk di server cloud publik dengan menemukan pengguna dengan aktivitas login/nama pengguna SQL yang sama dalam database master server itu. Pendekatan ini bersifat agnostik awan; sehingga, T-SQL API digunakan untuk memulai penyalinan lintas cloud. Untuk izin dan informasi selengkapnya tentang topik ini, lihat Membuat dan menggunakan geo-replikasi aktif dan ALTER DATABASE (Transact-SQL).

  • Kecuali untuk ekstensi perintah T-SQL awal yang menunjukkan server logis Azure SQL di Azure global, proses geo-replikasi aktif identik dengan eksekusi yang ada di cloud lokal. Untuk langkah-langkah terperinci dalam membuat geo-replikasi aktif, lihat Membuat dan menggunakan geo-replikasi aktif dengan pengecualian database sekunder dibuat di server logis sekunder yang dibuat di Azure global.

  • Setelah database sekunder ada di Azure global (sebagai salinan online-nya dari database Azure Jerman), pelanggan dapat memulai failover database dari Azure Jerman ke Azure global untuk database ini menggunakan perintah ALTER DATABASE T-SQL (lihat tabel di bawah).

  • Setelah failover, setelah sekunder menjadi database utama di Azure global, Anda dapat menghentikan replikasi geografis aktif dan menghapus database sekunder di sisi Azure Jerman kapan saja (lihat tabel di bawah ini dan langkah-langkah yang ada dalam diagram).

  • Setelah failover, database sekunder di Azure Jerman akan terus dikenakan biaya sampai dihapus.

  • Menggunakan perintah ALTER DATABASE adalah satu-satunya cara untuk menyiapkan geo-replikasi aktif untuk memigrasikan database Azure Jerman ke Azure global.

  • Tidak ada portal Azure, Azure Resource Manager, PowerShell, atau CLI yang tersedia untuk mengonfigurasi geo-replikasi aktif untuk migrasi ini.

Untuk memigrasikan database dari Azure Jerman ke Azure global:

  1. Pilih database pengguna di Azure Jerman, misalnya, azuregermanydb

  2. Buat server logis di Azure global (cloud publik), misalnya, globalazureserver. Nama domain yang sepenuhnya memenuhi syarat (FQDN) adalah globalazureserver.database.windows.net.

  3. Mulai geo-replikasi aktif dari Azure Jerman ke Azure global dengan mengeksekusi perintah T-SQL ini di server di Azure Jerman. Perhatikan bahwa nama dns yang sepenuhnya memenuhi syarat digunakan untuk server publik globalazureserver.database.windows.net. Hal ini untuk menunjukkan bahwa server target berada di Azure global, bukan Azure Jerman.

    ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];

  4. Saat replikasi siap untuk memindahkan beban kerja baca-tulis ke server Azure global, mulai failover terencana ke Azure global dengan mengeksekusi perintah T-SQL ini di server Azure global.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. Tautan geo-replikasi aktif dapat dihentikan sebelum atau setelah proses failover. Eksekusi perintah T-SQL berikut setelah failover terencana akan menghapus tautan geo-replikasi dengan database di Azure global yang menjadi salinan baca-tulis. Ini harus dijalankan di server logis database geo-primer saat ini (yakni di server Azure global). Ini akan menyelesaikan proses migrasi.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];

    Perintah T-SQL berikut saat dieksekusi sebelum failover terencana juga menghentikan proses migrasi, tetapi dalam situasi ini database di Azure Jerman akan tetap menjadi salinan baca-tulis. Perintah T-SQL ini juga akan dijalankan di server logis database geo-primer saat ini, dalam hal ini di server Azure Jerman.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];

Langkah-langkah memigrasikan database Azure SQL dari Azure Jerman ke Azure global juga dapat diikuti dengan menggunakan geo-replikasi aktif.

Untuk informasi selengkapnya setelah tabel berikut menunjukkan perintah T-SQL untuk mengelola failover. Perintah berikut didukung untuk geo-replikasi aktif lintas cloud antara Azure Jerman dan Azure global:

Perintah Deskripsi
ALTER DATABASE Gunakan argumen ADD SECONDARY ON SERVER untuk membuat database sekunder untuk database yang sudah ada dan memulai replikasi data
ALTER DATABASE Gunakan FAILOVER atau FORCE_FAILOVER_ALLOW_DATA_LOSS untuk mengalihkan database sekunder menjadi primer untuk memulai kegagalan
ALTER DATABASE Gunakan REMOVE SECONDARY ON SERVER untuk mengakhiri replikasi data antara Database SQL dan database sekunder yang ditentukan.

Tampilan sistem pemantauan geo-replikasi aktif

Perintah Deskripsi
sys.geo_replication_links Menampilkan informasi tentang semua tautan replikasi yang ada untuk setiap database di server Azure SQL Database.
sys.dm_geo_replication_link_status Mendapatkan waktu replikasi terakhir, keterlambatan replikasi terakhir, dan informasi lain tentang tautan replikasi untuk database SQL tertentu.
sys.dm_operation_status Memperlihatkan status untuk semua operasi database termasuk status link replikasi.
sp_wait_for_database_copy_sync Menyebabkan aplikasi menunggu hingga semua transaksi yang diterapkan direplikasi dan dibenarkan oleh database sekunder aktif.

Migrasi cadangan retensi jangka panjang SQL Database

Migrasi database dengan geo-replikasi atau file BACPAC tidak akan menyalin cadangan retensi jangka panjang yang kemungkinan dimiliki oleh database di Azure Jerman. Untuk memigrasikan cadangan retensi jangka panjang yang ada ke wilayah Azure global target, Anda dapat menggunakan prosedur pencadangan retensi jangka panjang COPY.

Catatan

Metode cadangan LTR yang didokumentasikan di sini hanya dapat menyalin cadangan LTR dari Azure Jerman ke Azure global. Menyalin cadangan PITR menggunakan metode ini tidak didukung.

Prasyarat

  1. Database target tempat Anda menyalin cadangan LTR, di Azure global harus ada sebelum Anda memulai menyalin cadangan. Sebaiknya Anda terlebih dahulu memigrasikan database sumber menggunakan geo-replikasi aktif dan kemudian memulai cadangan LTR. Tindakan ini akan memastikan bahwa pencadangan database disalin ke database tujuan yang benar. Langkah ini tidak diperlukan jika Anda menyalin cadangan LTR dari database yang dihilangkan. Saat menyalin cadangan LTR dari database yang dihilangkan, DatabaseID dummy akan dibuat di wilayah target.
  2. Pasang Modul Az PowerShell ini
  3. Sebelum Anda memulai, pastikan peran Azure RBAC yang diperlukan diberikan pada cakupan langganan atau grup sumber daya. Catatan: Untuk mengakses cadangan LTR milik server yang dihilangkan, izin harus diberikan dalam cakupan langganan server tersebut. .

Batasan

  • Grup Failover tidak didukung. Ini berarti bahwa pelanggan yang memigrasikan database Azure Jerman harus mengelola string koneksi sendiri selama failover.
  • Tidak ada dukungan untuk portal Azure, Azure Resource Manager API, PowerShell, atau CLI. Ini berarti bahwa setiap migrasi Azure Jerman harus mengelola penyiapan geo-replikasi aktif dan failover melalui T-SQL.
  • Pelanggan tidak dapat membuat beberapa geo-sekunder di Azure global untuk database di Azure Jerman.
  • Pembuatan geo-sekunder harus dimulai dari wilayah Azure Jerman.
  • Pelanggan hanya dapat memigrasikan database dari Azure Jerman ke Azure global. Saat ini tidak ada migrasi lintas-cloud lainnya yang didukung.
  • Pengguna Azure AD di database pengguna Azure Jerman dimigrasikan tetapi tidak tersedia di penyewa Azure AD baru tempat database yang dimigrasikan berada. Untuk mengaktifkan pengguna ini, mereka harus dihilangkan dan dibuat ulang secara manual menggunakan pengguna Azure AD saat ini yang tersedia di penyewa Azure AD baru tempat database yang baru dimigrasikan berada.

Menyalin cadangan retensi jangka panjang menggunakan PowerShell

Perintah PowerShell baru Copy-AzSqlDatabaseLongTermRetentionBackup telah diperkenalkan, yang dapat digunakan untuk menyalin cadangan retensi jangka panjang dari Azure Jerman ke wilayah global Azure.

  1. Salin cadangan LTR menggunakan nama cadangan Contoh berikut menunjukkan cara menyalin cadangan LTR dari Azure Jerman ke wilayah global Azure, menggunakan nama cadangan.
# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN
  1. Salin cadangan LTR menggunakan resourceID cadangan Contoh berikut menunjukkan cara menyalin cadangan LTR dari Azure Jerman ke wilayah global Azure, menggunakan resourceID cadangan. Contoh ini juga dapat digunakan untuk menyalin cadangan database yang dihapus.
$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Batasan

  • Cadangan pemulihan titik waktu (PITR) hanya diambil di database utama, ini berdasarkan desain. Saat memigrasikan database dari Azure Jerman menggunakan Geo-DR, pencadangan PITR akan mulai terjadi pada primer baru setelah failover. Namun, cadangan PITR yang ada (pada primer sebelumnya di Azure Jerman) tidak akan dimigrasikan. Jika Anda memerlukan cadangan PITR untuk mendukung skenario pemulihan titik waktu, Anda perlu memulihkan database dari cadangan PITR di Azure Jerman dan kemudian memigrasikan database yang dipulihkan ke Azure global.
  • Kebijakan retensi jangka panjang tidak dimigrasikan dengan database. Jika memiliki kebijakan retensi jangka panjang (LTR) di database Anda di Azure Jerman, Anda perlu menyalin dan membuat ulang kebijakan LTR secara manual di database baru setelah migrasi.

Meminta Akses

Untuk memigrasikan database dari Azure Jerman ke Azure global menggunakan geo-replikasi, langganan Anda di Azure Jerman harus diaktifkan agar berhasil mengonfigurasi migrasi lintas-cloud.

Untuk mengaktifkan langganan Azure Jerman, Anda harus menggunakan tautan berikut untuk membuat permintaan dukungan migrasi:

  1. Telusuri permintaan dukungan migrasi berikut.

  2. Di tab Dasar, masukkan migrasi Geo-DR sebagai Ringkasan, lalu pilih Berikutnya: Solusi

    formulir permintaan dukungan baru

  3. Tinjau Langkah-Langkah yang Direkomendasikan, lalu pilih Berikutnya: Detail.

    informasi permintaan dukungan yang diperlukan

  4. Di halaman detail, masukkan berikut:

    1. Dalam kotak Deskripsi, masukkan ID langganan Azure global tempat tujuan migrasi. Untuk memigrasikan database ke lebih dari satu langganan, tambahkan daftar ID Azure global tempat tujuan database dimigrasikan.
    2. Masukkan informasi kontak: nama, nama perusahaan, email, atau nomor telepon.
    3. Isi formulir, lalu pilih Berikutnya: Tinjau + buat.

    detail permintaan dukungan

  5. Tinjau permintaan dukungan, lalu pilih Buat.

Anda akan dihubungi setelah permintaan diproses.

Azure Cosmos DB

Anda dapat menggunakan Alat Migrasi Data Azure Cosmos DB untuk memigrasikan data ke Azure Cosmos DB. Alat Migrasi Data Azure Cosmos DB adalah solusi sumber terbuka yang mengimpor data ke Azure Cosmos DB dari berbagai sumber termasuk: file JSON, MongoDB, SQL Server, file CSV, penyimpanan Azure Table, Amazon DynamoDB, HBase, dan kontainer Azure Cosmos.

Alat Migrasi Data Azure Cosmos DB tersedia sebagai alat antarmuka grafis atau alat baris perintah. Kode sumber tersedia di repositori GitHub Alat Migrasi Data Azure Cosmos DB. Alat versi kompilasi tersedia di Pusat Unduhan Microsoft.

Untuk memigrasikan sumber daya Azure Cosmos DB, sebaiknya Anda menyelesaikan langkah-langkah berikut:

  1. Tinjau persyaratan waktu aktif aplikasi dan konfigurasi akun untuk menentukan rencana tindakan terbaik.
  2. Klon konfigurasi akun dari Azure Jerman ke wilayah baru dengan menjalankan alat migrasi data.
  3. Jika jendela pemeliharaan dapat digunakan, salin data dari sumber ke tujuan dengan menjalankan alat migrasi data.
  4. Jika opsi penggunaan jendela pemeliharaan tidak tersedia, salin data dari sumber ke tujuan dengan menjalankan alat, lalu selesaikan langkah-langkah ini:
    1. Gunakan pendekatan berbasis konfigurasi untuk membuat perubahan pada operasi baca/tulis dalam aplikasi.
    2. Selesaikan sinkronisasi pertama kali.
    3. Siapkan sinkronisasi bertambah bertahap dan jangkau umpan perubahan.
    4. Arahkan pembacaan ke akun baru dan validasi aplikasi.
    5. Hentikan penulisan ke akun lama, validasi bahwa umpan perubahan dijangkau, lalu arahkan penulisan ke akun baru.
    6. Hentikan alat dan hapus akun lama.
  5. Jalankan alat untuk memvalidasi data sudah konsisten di akun lama dan baru.

Untuk informasi selengkapnya:

Azure Cache untuk Redis

Anda memiliki beberapa opsi jika ingin memigrasikan instans Azure Cache for Redis dari Azure Jerman ke Azure global. Opsi yang Anda pilih bergantung pada kebutuhan Anda.

Opsi 1: Terima kehilangan data, buat instans baru

Pendekatan ini paling masuk akal saat kedua kondisi berikut terpenuhi:

  • Anda menggunakan Azure Cache for Redis sebagai cache data sementara.
  • Aplikasi Anda akan mengisi ulang data cache secara otomatis di wilayah baru.

Untuk bermigrasi dengan kehilangan data dan membuat instans baru:

  1. Buat instans Azure Cache for Redis baru di wilayah target baru.
  2. Perbarui aplikasi Anda untuk menggunakan instans baru di wilayah baru.
  3. Hapus instans Azure Cache for Redis lama di wilayah sumber.

Opsi 2: Salin data dari instans sumber ke instans target

Anggota tim Azure Cache for Redis menulis alat sumber terbuka yang menyalin data dari satu instans Azure Cache untuk Redis ke instans lainnya tanpa memerlukan fungsi impor atau ekspor. Lihat langkah 4 dalam langkah-langkah berikut untuk mendapatkan informasi tentang alat ini.

Untuk menyalin data dari instans sumber ke instans target:

  1. Buat VM di wilayah sumber. Jika himpunan data Anda di Azure Cache for Redis besar, pastikan Anda memilih ukuran VM yang relatif kuat untuk meminimalkan waktu penyalinan.
  2. Buat instans Azure Cache for Redis baru di wilayah target.
  3. Alirkan data dari instans target. (Pastikan untuk tidak membersihkan dari instans sumber . Flushing diperlukan karena alat salin tidak menimpa kunci yang ada di lokasi target.)
  4. Gunakan alat berikut untuk menyalin data secara otomatis dari instans Azure Cache for Redis sumber ke instans Azure Cache for Redis target: Sumber alat dan unduhan alat.

Catatan

Proses ini memerlukan waktu lama bergantung pada ukuran himpunan data Anda.

Opsi 3: Ekspor dari instans sumber, impor ke instans tujuan

Pendekatan ini memanfaatkan fitur yang hanya tersedia di tingkat Premium.

Untuk mengekspor dari instans sumber dan mengimpor ke instans tujuan:

  1. Buat instans Azure Cache for Redis tingkat Premium baru di wilayah target. Gunakan ukuran yang sama dengan instans Azure Cache for Redis sumber.

  2. Ekspor data dari cache sumber atau gunakan cmdlet PowerShell Export-AzRedisCache.

    Catatan

    Akun Azure Storage ekspor harus berada di wilayah yang sama dengan instans cache.

  3. Salin blob yang diekspor ke akun penyimpanan di wilayah tujuan (misalnya, dengan menggunakan AzCopy).

  4. Impor data ke cache tujuan atau gunakan cmdlet PowerShell Import-AzRedisCAche.

  5. Konfigurasi ulang aplikasi Anda untuk menggunakan instans Azure Cache for Redis target.

Opsi 4: Tulis data ke dua instans Azure Cache for Redis, baca dari satu instans

Untuk pendekatan ini, Anda harus memodifikasi aplikasi Anda. Aplikasi perlu menulis data ke lebih dari satu instans cache saat membaca dari salah satu instans cache. Pendekatan ini masuk akal jika data yang disimpan dalam Azure Cache for Redis memenuhi kriteria berikut:

  • Data direfresh secara teratur.
  • Semua data ditulis ke instans Azure Cache for Redis.
  • Anda memiliki cukup waktu untuk merefresh semua data.

Untuk informasi selengkapnya:

PostgreSQL dan MySQL

Untuk informasi selengkapnya, lihat artikel di bagian "Mencadangkan dan memigrasikan data" di PostgreSQL dan MySQL.

PostgreSQL dan MySQL

Langkah berikutnya

Pelajari tentang alat, teknik, dan rekomendasi untuk memigrasikan sumber daya dalam kategori layanan berikut: