Jaringan dengan akses privat (integrasi jaringan virtual) di server fleksibel Azure Database for PostgreSQL

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

Saat membuat 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 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 server fleksibel Azure Database for PostgreSQL Anda dengan menggunakan alamat IP privat.
  • Gunakan VPN atau Azure ExpressRoute untuk menyambungkan dari sumber daya yang tidak Azure ke server fleksibel Azure Database for PostgreSQL Anda.
  • Pastikan bahwa server fleksibel Azure Database for PostgreSQL tidak memiliki titik akhir publik yang dapat diakses melalui internet.

Diagram yang memperlihatkan cara kerja peering antara jaringan virtual, salah satunya mencakup server fleksibel Azure Database for PostgreSQL.

Pada diagram sebelumnya:

  • Azure Database for PostgreSQL server fleksibel disisipkan ke subnet 10.0.1.0/24 pada jaringan virtual VNet-1.
  • Aplikasi yang disebarkan pada subnet yang berbeda dalam jaringan virtual yang sama dapat mengakses server fleksibel Azure Database for PostgreSQL secara langsung.
  • Aplikasi yang disebarkan pada jaringan virtual yang berbeda (VNet-2) tidak memiliki akses langsung ke server fleksibel Azure Database for PostgreSQL. Anda harus melakukan peering jaringan virtual untuk zona Private DNS sebelum mereka dapat mengakses server 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 server fleksibel Azure Database for PostgreSQL Anda. Untuk mempelajari selengkapnya tentang jaringan virtual Azure, lihat Gambaran umum Microsoft Azure Virtual Network.

Biasakan diri Anda dengan konsep-konsep ini saat menggunakan jaringan virtual di mana sumber daya diintegrasikan ke dalam jaringan virtual dengan 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.

    Server fleksibel Azure Database for PostgreSQL Anda yang terintegrasi dalam jaringan virtual harus berada di subnet yang didelegasikan. Artinya, hanya 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 server Azure Database for PostgreSQL fleksibel 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 server fleksibel Azure Database for PostgreSQL dan hop 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, Azure Database untuk PostgreSQL Flexible Server tidak mendukung NSG yang aturannya menyertakan ASG. 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 server fleksibel Azure Database for PostgreSQL disebarkan dan ke Azure Storage untuk pengarsipan log. Jika Anda membuat NSG untuk menolak lalu lintas ke atau dari server fleksibel Azure Database for PostgreSQL Anda di dalam subnet tempat server tersebut disebarkan, pastikan untuk mengizinkan lalu lintas ke port tujuan 5432 di dalam subnet, dan juga ke Storage, dengan menggunakan tag layanan Storage sebagai tujuan.

    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 server fleksibel Azure Database for PostgreSQL Anda, izinkan lalu lintas keluar Microsoft Entra ID dengan menggunakan tag layanan Microsoft Entra.

    Titik akhir layanan Microsoft.Storage secara otomatis dikonfigurasi pada subnet yang didelegasikan saat server pertama disediakan di subnet tersebut. Konfigurasi ini memastikan perutean lalu lintas yang andal ke akun Azure Storage yang digunakan untuk mengunggah file log Write-Ahead (WAL). Menghapus titik akhir ini dapat mengganggu konektivitas dan dapat menyebabkan konsekuensi yang tidak diinginkan untuk operasi layanan inti.

    Saat Anda menyiapkan replika baca lintas wilayah Azure, server fleksibel Azure Database for PostgreSQL Anda harus dapat mengirim atau menerima lalu lintas ke port tujuan 5432 untuk server primer maupun replika, serta ke Azure Storage di wilayah primer dan replika dari server primer maupun 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 server fleksibel Azure Database for PostgreSQL baru yang dibuat dengan menggunakan akses jaringan privat, Anda perlu menggunakan zona Private DNS saat mengonfigurasi 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, penerapan server fleksibel Azure Database for PostgreSQL Anda tidak akan berhasil diselesaikan.

Untuk 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 Private DNS. Kemudian gunakan saat Anda mengonfigurasi server fleksibel Azure Database for PostgreSQL dengan akses privat. Untuk informasi selengkapnya, lihat Spesifikasi REST API untuk Azure.

Jika Anda menggunakan portal Azure atau Azure CLI untuk membuat server fleksibel Azure Database for PostgreSQL, Anda dapat memberikan nama zona Private DNS yang sebelumnya Anda buat di langganan yang sama atau berbeda, atau Private DNS default zona 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 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 format [name].postgres.database.azure.com, nama tersebut tidak boleh sama dengan nama yang Anda gunakan untuk salah satu Azure Databases for PostgreSQL flexible server Anda, atau Anda akan mendapatkan pesan kesalahan saat provisi. Untuk informasi selengkapnya, lihat Gambaran umum zona DNS privat.

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

Penting

Kemampuan untuk mengubah zona Private DNS dari zona yang Anda berikan saat membuat server fleksibel Azure Database for PostgreSQL ke zona Private DNS 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 keberadaan tautan jaringan virtual saat pembuatan server untuk Azure Database for PostgreSQL Flexible Server 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 melakukan resolusi FQDN dari 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 terhubung ke server fleksibel Azure Database for PostgreSQL dari klien yang Anda provisikan di jaringan virtual lain dari wilayah yang sama atau wilayah yang berbeda, Anda perlu menautkan zona Private DNS 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 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.

Gunakan spoke untuk mengisolasi beban kerja individual. Sambungkan kantor pusat lokal dan Azure melalui ExpressRoute atau VPN situs-ke-situs, yang terhubung ke jaringan virtual hub. Rekan jaringan virtual dari spoke ke hub dan aktifkan komunikasi ke sumber daya lokal. Terapkan hub dan setiap spoke dalam langganan atau grup sumber daya terpisah.

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

  • Spoke saling terhubung secara langsung: Buat 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 menghubungkan dua jaringan virtual (salah satunya memiliki 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 FQDN server fleksibel Azure Database for PostgreSQL di jaringan virtual lain (VNET2).

Untuk mengatasi masalah ini, pastikan klien di VNET1 dapat mengakses server fleksibel Azure Database for PostgreSQL zona Private DNS. Tambahkan tautan jaringan virtual ke zona Private DNS 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 menyebarkan 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.
  • Konfigurasi jaringan kustom yang merutekan semua lalu lintas ke Microsoft Azure Storage melalui Virtual Network Appliance (NVA) tidak didukung. Misalnya, menggunakan rute catch-all (0.0.0.0/0 → NVA) untuk memaksa semua lalu lintas keluar melalui NVA dapat mengganggu konektivitas platform yang diperlukan. Ini dapat mengakibatkan kegagalan tak terduga dalam operasi penting, termasuk skenario Ketersediaan Tinggi. Secara default, layanan menambahkan titik akhir layanan Micosoft.Storage saat server pertama disediakan di subnet yang didelegasikan, yang menyediakan konektivitas aman dan langsung ke Azure Storage melalui jaringan backbone Azure. Menghapus titik akhir ini dapat menyebabkan konsekuensi yang tidak diinginkan untuk operasi layanan inti.

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 Private DNS atau kumpulan catatan individual mungkin mengganggu kemampuan 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 Anda menggunakan fitur ketersediaan tinggi dengan 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 terhubung ke 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