Bagikan melalui

Jaringan dengan akses privat (integrasi jaringan virtual) untuk Azure Database for PostgreSQL

Artikel ini menjelaskan konsep konektivitas dan jaringan untuk instans server fleksibel Azure Database for PostgreSQL.

Saat membuat instans server fleksibel Azure Database for PostgreSQL, Anda harus memilih salah satu opsi jaringan berikut:

  • Akses privat (integrasi jaringan virtual)
  • Akses publik (alamat IP yang diizinkan) dan titik akhir privat

Dokumen ini menjelaskan opsi jaringan akses privat (integrasi jaringan virtual).

Akses privat (integrasi jaringan virtual)

Anda dapat menyebarkan instans server fleksibel Azure Database for PostgreSQL ke jaringan virtual Azure Anda dengan menggunakan injeksi jaringan virtual. Jaringan virtual Azure menyediakan komunikasi jaringan privat dan aman. Sumber daya dalam jaringan virtual berkomunikasi melalui alamat IP privat yang Anda tetapkan pada jaringan ini.

Pilih opsi jaringan ini jika Anda menginginkan kemampuan berikut:

  • Sambungkan dari sumber daya Azure di jaringan virtual yang sama ke instans server fleksibel Azure Database for PostgreSQL Anda dengan menggunakan alamat IP privat.
  • Gunakan VPN atau Azure ExpressRoute untuk menyambungkan dari sumber daya non-Azure ke instans server fleksibel Azure Database for PostgreSQL Anda.
  • Pastikan bahwa instans server fleksibel Azure Database for PostgreSQL tidak memiliki titik akhir publik yang dapat diakses melalui internet.

Diagram yang memperlihatkan cara kerja peering di antara jaringan virtual, yang salah satunya menyertakan instance server fleksibel dari Azure Database for PostgreSQL.

Pada diagram sebelumnya:

  • Instans server fleksibel Azure Database for PostgreSQL disuntikkan ke subnet 10.0.1.0/24 dari jaringan virtual VNet-1.
  • Aplikasi yang disebarkan pada subnet yang berbeda dalam jaringan virtual yang sama dapat mengakses instans server fleksibel Azure Database for PostgreSQL secara langsung.
  • Aplikasi yang disebarkan pada jaringan virtual yang berbeda (VNet-2) tidak memiliki akses langsung ke instans server fleksibel Azure Database for PostgreSQL. Anda harus melakukan peering jaringan virtual untuk zona DNS Privat sebelum mereka dapat mengakses instans server yang fleksibel.

Konsep jaringan virtual

Jaringan virtual Azure berisi ruang alamat IP privat yang Anda konfigurasi untuk penggunaan Anda. Jaringan virtual Anda harus berada di wilayah Azure yang sama dengan instans server fleksibel Azure Database for PostgreSQL Anda. Untuk mempelajari selengkapnya tentang jaringan virtual Azure, lihat Gambaran umum Azure Virtual Network.

Biasakan diri Anda dengan konsep-konsep ini saat menggunakan jaringan virtual di mana sumber daya diintegrasikan ke dalam jaringan virtual dengan instans server fleksibel Azure Database for PostgreSQL:

  • Subnet yang didelegasikan: Jaringan virtual berisi subnet (subnetwork). Subnet memungkinkan Anda melakukan segmentasi jaringan virtual ke ruang alamat yang lebih kecil. Anda menyebarkan sumber daya Azure ke subnet tertentu dalam jaringan virtual.

    Instans server fleksibel Azure Database for PostgreSQL Anda yang terintegrasi dalam jaringan virtual harus berada dalam subnet yang didelegasikan. Artinya, hanya instans server fleksibel Azure Database for PostgreSQL yang dapat menggunakan subnet tersebut. Tidak ada jenis sumber daya Azure lainnya yang bisa berada di subnet yang didelegasikan. Anda mendelegasikan subnet dengan menetapkan properti delegasinya sebagai Microsoft.DBforPostgreSQL/flexibleServers.

    Rentang CIDR terkecil yang dapat Anda tentukan untuk subnet adalah /28, yang menyediakan 16 alamat IP. Alamat pertama dan terakhir di jaringan atau subnet apa pun tidak dapat ditetapkan ke host individu mana pun. Azure mencadangkan lima IP untuk digunakan secara internal oleh jaringan Azure, yang mencakup dua IP yang tidak dapat ditetapkan ke host, seperti yang disebutkan. Reservasi ini memberi Anda 11 alamat IP yang tersedia untuk rentang CIDR /28. Satu instans server fleksibel Azure Database for PostgreSQL dengan fitur ketersediaan tinggi menggunakan empat alamat.

    Untuk replikasi dan koneksi Microsoft Entra, pastikan tabel rute tidak memengaruhi lalu lintas. Pola umumnya adalah merutekan semua lalu lintas keluar melalui Azure Firewall atau appliance pemfilteran jaringan lokal kustom.

    Jika subnet memiliki tabel rute yang terkait dengan aturan untuk merutekan semua lalu lintas ke appliance virtual:

    • Tambahkan aturan dengan tag layanan tujuan AzureActiveDirectory dan hop berikutnya Internet.
    • Tambahkan aturan dengan rentang IP tujuan yang sama dengan rentang subnet instans server fleksibel Azure Database for PostgreSQL dan hop yang berikutnya Virtual Network.

    Penting

    Nama AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet, dan GatewaySubnet tersimpan dalam Azure. Jangan gunakan salah satu nama ini sebagai nama subnet Anda. Selain itu, jaringan virtual seharusnya tidak memiliki ruang alamat yang tumpang tindih untuk membuat replika lintas wilayah.

  • Kelompok keamanan jaringan (NSG): Aturan keamanan di NSG memungkinkan Anda memfilter jenis lalu lintas jaringan yang dapat mengalir masuk dan keluar dari subnet jaringan virtual dan antarmuka jaringan. Untuk informasi selengkapnya, lihat Gambaran Umum NSG.

    Kelompok keamanan aplikasi (ASGs) membuatnya mudah untuk mengontrol keamanan Layer-4 dengan menggunakan NSGs untuk jaringan datar. Anda dapat dengan cepat:

    • Gabungkan komputer virtual ke ASG atau hapus komputer virtual dari ASG.
    • Menerapkan aturan secara dinamis ke komputer virtual tersebut atau menghapus aturan dari komputer virtual tersebut.

    Untuk informasi selengkapnya, lihat Gambaran Umum ASG.

    Saat ini, instans server fleksibel Azure Database untuk PostgreSQL tidak mendukung NSG yang menggunakan ASG sebagai bagian dari aturan. Gunakan pemfilteran sumber atau tujuan berbasis IP di NSG.

    Ketersediaan tinggi dan fitur lain dari server Azure Database for PostgreSQL memerlukan kemampuan untuk mengirim dan menerima lalu lintas ke port tujuan 5432 dalam subnet jaringan virtual Azure tempat instans server fleksibel Azure Database for PostgreSQL disebarkan dan ke Azure Storage untuk pengarsipan log. Jika Anda membuat NSG untuk menolak arus lalu lintas ke atau dari instans server fleksibel Azure Database for PostgreSQL dalam subnet tempatnya disebarkan, pastikan untuk mengizinkan lalu lintas ke port tujuan 5432 dalam subnet, dan juga ke Storage, dengan menggunakan tag layanan Storage sebagai tujuan. Untuk memastikan ketersediaan tinggi, praktik terbaiknya adalah menambahkan server atau layanan dari Microsoft. Titik akhir layanan penyimpanan karena memastikan perutean lalu lintas yang benar ke akun penyimpanan Azure yang digunakan untuk mengunggah file Write Ahead Log (WAL).

    Anda dapat memfilter aturan pengecualian ini lebih lanjut dengan menambahkan wilayah Azure Anda ke label seperti us-east.storage. Selain itu, jika Anda memilih untuk menggunakan autentikasi Microsoft Entra untuk mengautentikasi masuk ke instans server fleksibel Azure Database for PostgreSQL Anda, izinkan lalu lintas keluar ke ID Microsoft Entra dengan menggunakan tag layanan Microsoft Entra.

    Saat Anda menyiapkan Replika Baca di berbagai wilayah Azure, instans server fleksibel Azure Database for PostgreSQL Anda memerlukan kemampuan untuk mengirim atau menerima lalu lintas ke port tujuan 5432, baik untuk primer dan replika, serta ke Azure Storage di wilayah utama dan replika dari kedua server utama dan replika. Port TCP tujuan yang diperlukan untuk Penyimpanan adalah 443.

  • Integrasi zona DNS privat: Integrasi zona DNS privat Azure memungkinkan Anda melakukan resolusi DNS privat dalam jaringan virtual saat ini atau jaringan virtual yang di-peering di dalam wilayah mana pun tempat zona DNS privat ditautkan.

Menggunakan zona DNS Privat

Azure Private DNS menyediakan layanan DNS yang andal dan aman untuk jaringan virtual Anda. Azure Private DNS mengelola dan menyelesaikan nama domain di jaringan virtual tanpa harus mengonfigurasi solusi DNS kustom.

Saat Anda menggunakan akses jaringan privat dengan jaringan virtual Azure, Anda harus menyediakan informasi zona DNS Privat untuk mengaktifkan resolusi DNS. Untuk instans server fleksibel Azure Database for PostgreSQL baru yang dibuat dengan menggunakan akses jaringan privat, Anda perlu menggunakan zona DNS Privat sambil mengonfigurasi instans server fleksibel Azure Database for PostgreSQL dengan akses privat.

Penting

Saat menggunakan zona DNS privat dalam langganan yang berbeda, langganan tersebut begitu juga harus memiliki penyedia sumber daya Microsoft.DBforPostgreSQL terdaftar. Jika tidak, penyebaran instans server fleksibel Azure Database for PostgreSQL Anda tidak akan selesai.

Untuk instans server fleksibel Azure Database for PostgreSQL baru yang dibuat dengan menggunakan akses jaringan privat dengan API, templat Azure Resource Manager (templat ARM), Bicep, atau Terraform, buat zona DNS Privat. Kemudian gunakan saat Anda mengonfigurasi instans server fleksibel Azure Database for PostgreSQL dengan akses privat. Untuk informasi selengkapnya, lihat Spesifikasi REST API untuk Azure.

Jika Anda menggunakan portal Microsoft Azure atau Azure CLI untuk membuat instans server fleksibel Azure Database for PostgreSQL, Anda dapat memberikan nama zona DNS Privat yang sebelumnya Anda buat di langganan yang sama atau berbeda, atau zona DNS Privat default secara otomatis dibuat di langganan Anda.

Jika Anda menggunakan Azure API, templat ARM, Bicep, atau Terraform, buat zona DNS Privat yang diakhir dengan .postgres.database.azure.com. Gunakan zona tersebut saat Anda mengonfigurasi instans server fleksibel Azure Database for PostgreSQL dengan akses privat. Misalnya, gunakan formulir [name1].[name2].postgres.database.azure.com atau [name].postgres.database.azure.com. Jika Anda memilih untuk menggunakan formulir [name].postgres.database.azure.com, nama tersebut tidak bisa menjadi nama yang Anda gunakan untuk salah satu instans server fleksibel Azure Databases for PostgreSQL Anda, atau Anda akan mendapatkan pesan kesalahan selama provisi. Untuk informasi selengkapnya, lihat Gambaran umum zona DNS privat.

Saat Anda menggunakan portal Microsoft Azure, API, Azure CLI, atau templat ARM, Anda juga dapat mengubah zona DNS Privat dari yang Anda berikan saat membuat instans server fleksibel Azure Database for PostgreSQL ke zona DNS Privat lain yang ada di langganan yang sama atau berbeda.

Penting

Kemampuan untuk mengubah zona DNS Privat dari zona yang Anda berikan saat membuat instans server fleksibel Azure Database for PostgreSQL ke zona DNS Privat lain saat ini dinonaktifkan untuk server dengan fitur ketersediaan tinggi diaktifkan.

Setelah membuat zona DNS Privat di Azure, Anda perlu menautkan jaringan virtual ke zona TERSEBUT. Sumber daya yang dihosting di jaringan virtual tertaut kemudian dapat mengakses zona DNS Privat.

Penting

Kami tidak lagi memvalidasi kehadiran tautan jaringan virtual pada pembuatan server untuk instans server fleksibel Azure Database for PostgreSQL dengan jaringan privat. Saat Anda membuat server melalui portal, kami menyediakan pilihan pelanggan untuk membuat tautan pada pembuatan server melalui kotak centang Tautkan zona DNS Privat ke jaringan virtual Anda di portal Azure.

Zona privat DNS tahan terhadap pemadaman regional karena data zona tersedia secara global. Rekaman sumber daya di zona privat secara otomatis direplikasi di seluruh wilayah. Azure Private DNS adalah layanan yang mendasar untuk zona ketersediaan, dan mendukung redundansi zona. Untuk informasi selengkapnya, lihat Layanan Azure dengan dukungan zona ketersediaan.

Integrasi dengan server DNS kustom

Jika Anda menggunakan server DNS kustom, Anda harus menggunakan forwarder DNS untuk memecahkan FQDN dari instans server fleksibel Azure Database for PostgreSQL Anda. Alamat IP forwarder harus 168.63.129.16.

Server DNS kustom harus berada di dalam jaringan virtual atau dapat dijangkau melalui pengaturan server DNS jaringan virtual. Untuk informasi selengkapnya, lihat Resolusi nama yang menggunakan server DNS Anda sendiri.

Penting

Pemeliharaan terjadwal secara otomatis menyegarkan pengaturan server DNS kustom Anda. Untuk mengenali dan menerapkan pengaturan DNS kustom yang diperbarui sebelum peningkatan terjadwal berikutnya, Microsoft harus melakukan refresh secara internal karena fungsionalitas ini tidak diekspos melalui API atau kontrol yang menghadap pelanggan. Jika Anda memerlukan perubahan agar berlaku lebih cepat, hubungi Dukungan Microsoft.

Zona DNS pribadi dan peering jaringan virtual

Pengaturan zona DNS privat dan peering jaringan virtual tidak tergantung satu sama lain. Jika Anda ingin menyambungkan ke instans server fleksibel Azure Database for PostgreSQL dari klien yang Anda provisikan di jaringan virtual lain dari wilayah yang sama atau wilayah lain, Anda perlu menautkan zona DNS Privat dengan jaringan virtual. Untuk informasi selengkapnya, lihat Menautkan jaringan virtual.

Nota

Anda hanya bisa menautkan nama zona DNS Privat yang diakhir dengan postgres.database.azure.com. Nama zona DNS Anda tidak boleh sama dengan instans server fleksibel Azure Database for PostgreSQL Anda. Jika tidak, resolusi nama gagal.

Untuk memetakan nama server ke catatan DNS, jalankan nslookup perintah di Azure Cloud Shell dengan menggunakan Azure PowerShell atau Bash. Ganti nama server Anda untuk <server_name> parameter dalam contoh berikut:

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

Menggunakan desain jaringan privat hub dan spoke

Hub dan spoke adalah model jaringan populer untuk mengelola persyaratan komunikasi atau keamanan umum secara efisien.

Hub adalah jaringan virtual yang bertindak sebagai lokasi pusat untuk mengelola konektivitas eksternal. Hub juga menghosting layanan yang digunakan oleh beberapa beban kerja. Hub tersebut mengkoordinasikan semua komunikasi ke dan dari cabang. Aturan atau proses TI seperti keamanan dapat memeriksa, merutekan, dan mengelola lalu lintas secara terpusat. Spokes adalah jaringan virtual yang menampung beban kerja dan terhubung ke hub pusat melalui peering jaringan virtual. Layanan bersama dihosting di subnet milik layanan untuk dibagikan dengan hub. Subnet perimeter kemudian bertindak sebagai perangkat keamanan.

Spoke juga merupakan jaringan virtual di Azure yang Anda gunakan untuk mengisolasi beban kerja individual. Arus lalu lintas antara kantor pusat lokal dan Azure terhubung melalui Azure ExpressRoute atau VPN situs-ke-situs, yang terhubung ke jaringan virtual hub. Jaringan virtual dari cabang ke pusat dihubungkan dan memungkinkan komunikasi dengan sumber daya di tempat. Anda dapat menerapkan hub dan setiap spoke dalam langganan atau grup sumber daya terpisah.

Ada tiga pola utama untuk menghubungkan jaringan virtual spoke satu sama lain:

  • Spoke terhubung langsung satu sama lain: Anda membuat peering jaringan virtual atau terowongan VPN antara jaringan virtual spoke untuk menyediakan konektivitas langsung tanpa melintasi jaringan virtual hub.
  • Spoke berkomunikasi melalui perangkat jaringan: Setiap spoke jaringan virtual memiliki peering ke WAN virtual atau ke jaringan virtual hub. Appliance mengalihkan lalu lintas dari "spoke" ke "spoke". Appliance dapat dikelola oleh Microsoft (seperti halnya WAN virtual) atau oleh Anda.
  • Gateway jaringan virtual dilampirkan ke jaringan hub dan menggunakan rute yang ditentukan pengguna: Mengaktifkan komunikasi antara spoke.

Diagram yang memperlihatkan arsitektur hub-and-spoke dasar dengan konektivitas hibrid melalui hub ekspres.

Gunakan Azure Virtual Network Manager untuk membuat topologi jaringan virtual hub dan spoke baru (serta memasukkan yang sudah ada) guna manajemen pusat atas kontrol konektivitas dan keamanan.

Komunikasi dengan klien jaringan privat di berbagai wilayah

Sering kali, pelanggan perlu terhubung ke klien di berbagai wilayah Azure. Lebih khusus lagi, pertanyaan ini biasanya bermunculan ke cara menyambungkan dua jaringan virtual (salah satunya memiliki instans server fleksibel Azure Database for PostgreSQL dan yang lain memiliki klien aplikasi) yang berada di wilayah yang berbeda.

Anda dapat mencapai konektivitas tersebut dengan berbagai cara, termasuk:

  • Peering jaringan global virtual. Metodologi ini adalah yang paling umum karena ini adalah cara term mudah untuk menghubungkan jaringan di berbagai wilayah bersama-sama. Peering jaringan virtual global menciptakan koneksi langsung melalui backbone Azure antara dua jaringan virtual yang di-peering. Metode ini menyediakan throughput jaringan terbaik dan latensi terendah untuk konektivitas. Saat Anda melakukan peering jaringan virtual, Azure juga menangani perutean secara otomatis untuk Anda. Jaringan virtual ini dapat berkomunikasi dengan semua sumber daya di jaringan virtual yang di-peering yang dibuat di gateway VPN.
  • Koneksi antarjaringan. Koneksi antara jaringan virtual (koneksi jaringan-ke-jaringan) pada dasarnya adalah VPN antara dua lokasi Azure. Anda membuat koneksi jaringan-ke-jaringan pada gateway VPN. Lalu lintas Anda menimbulkan dua lompatan lalu lintas lebih banyak dibandingkan dengan peering jaringan virtual global. Ada juga latensi ekstra dan bandwidth yang lebih rendah dibandingkan dengan metode tersebut.
  • Komunikasi melalui perangkat jaringan dalam arsitektur hub-and-spoke. Alih-alih menghubungkan jaringan virtual spoke langsung satu sama lain, Anda dapat menggunakan perangkat jaringan untuk meneruskan lalu lintas antar spoke. Perangkat jaringan menyediakan layanan jaringan lebih banyak seperti inspeksi paket mendalam dan segmentasi atau pemantauan lalu lintas, tetapi dapat memperkenalkan latensi dan kemacetan performa jika tidak berukuran benar.

Replikasi antar wilayah Azure dan antar jaringan virtual dengan jaringan privat

Replikasi database adalah proses penyalinan data dari server pusat atau utama ke beberapa server yang dikenal sebagai replika. Server utama menerima operasi baca dan tulis, tetapi replika melayani transaksi baca-saja. Server utama dan replika secara kolektif membentuk kluster database. Tujuan replikasi database adalah untuk memastikan redundansi, konsistensi, ketersediaan tinggi, dan aksesibilitas data, terutama dalam aplikasi misi-kritis dengan lalu lintas tinggi.

Azure Database for PostgreSQL menawarkan dua metode untuk replikasi: fisik (yaitu, streaming) melalui fitur Replika Baca bawaan dan replikasi logis. Keduanya sangat ideal untuk kasus penggunaan yang berbeda, dan Anda dapat memilih satu di atas yang lain tergantung pada tujuan akhir Anda.

Replikasi di seluruh wilayah Azure dengan jaringan virtual terpisah di setiap wilayah memerlukan konektivitas yang melintasi batas jaringan virtual regional, yang dapat disediakan oleh peering jaringan virtual atau dalam arsitektur hub-and-spoke melalui perangkat jaringan.

Pada awalnya, resolusi nama DNS dibatasi ke jaringan virtual. Setiap klien dalam satu jaringan virtual (VNET1) tidak dapat menyelesaikan instans server fleksibel Azure Database for PostgreSQL FQDN di jaringan virtual lain (VNET2).

Untuk mengatasi masalah ini, pastikan klien di VNET1 dapat mengakses zona DNS Privat instans server fleksibel Azure Database for PostgreSQL. Tambahkan tautan jaringan virtual ke zona DNS Privat instans server fleksibel Azure Database for PostgreSQL Anda.

Skenario jaringan virtual tidak didukung

Berikut adalah beberapa batasan untuk bekerja dengan jaringan virtual yang dibuat melalui integrasi jaringan virtual:

  • Setelah Anda menyebarkan instans server fleksibel Azure Database for PostgreSQL ke jaringan virtual dan subnet, Anda tidak dapat memindahkannya ke jaringan virtual atau subnet lain. Anda tidak dapat memindahkan jaringan virtual ke kelompok sumber daya atau langganan lain.
  • Anda tidak dapat meningkatkan ukuran subnet (ruang alamat) setelah sumber daya ada di subnet.
  • Secara default, sumber daya yang disuntikkan jaringan virtual tidak dapat berinteraksi dengan Private Link. Jika Anda ingin menggunakan Private Link untuk jaringan privat, lihat Jaringan Azure Database for PostgreSQL dengan Private Link.

Penting

Azure Resource Manager mendukung kemampuan untuk mengunci sumber daya sebagai kontrol keamanan. Pengunci-pengunci sumber daya diterapkan pada sumber daya dan efektif untuk semua pengguna dan peran. Ada dua jenis kunci sumber daya: CanNotDelete dan ReadOnly. Anda bisa menerapkan jenis kunci ini baik ke zona DNS Privat atau ke kumpulan catatan individual.

Menerapkan kunci jenis terhadap zona DNS Privat atau kumpulan catatan individual mungkin mengganggu kemampuan instans server fleksibel Azure Database for PostgreSQL untuk memperbarui catatan DNS. Ini mungkin juga menyebabkan masalah selama operasi penting pada DNS, seperti failover ketersediaan tinggi dari primer ke sekunder. Untuk alasan ini, pastikan Anda tidak menggunakan zona privat DNS atau kunci rekaman saat menggunakan fitur ketersediaan tinggi dengan instans server fleksibel Azure Database for PostgreSQL.

Nama host

Terlepas dari opsi jaringan yang Anda pilih, selalu gunakan nama domain yang sepenuhnya memenuhi syarat (FQDN) sebagai nama host saat Anda tersambung ke instans server fleksibel Azure Database for PostgreSQL Anda. Alamat IP server mungkin berubah. Dengan menggunakan FQDN, Anda tidak perlu memperbarui string koneksi Anda.

Contoh yang menggunakan FQDN sebagai nama host adalah hostname = servername.postgres.database.azure.com. Jika memungkinkan, hindari menggunakan hostname = 10.0.0.4 (alamat privat) atau hostname = 40.2.45.67 (alamat publik).

Konten terkait

  • Last updated on