Jaringan dengan akses privat (Integrasi jaringan virtual) untuk Azure Database for PostgreSQL - Server Fleksibel

BERLAKU UNTUK: Azure Database for PostgreSQL - Server Fleksibel

Artikel ini menjelaskan konsep konektivitas dan jaringan untuk 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 VNet) atau Akses publik (alamat IP yang diizinkan) dan Titik Akhir Privat. Dokumen ini menjelaskan opsi jaringan akses privat (integrasi VNet).

Akses privat (integrasi jaringan virtual)

Anda dapat menyebarkan instans server fleksibel Azure Database for PostgreSQL ke jaringan virtual Azure (jaringan virtual) Anda menggunakan injeksi VNET. Jaringan virtual Azure menyediakan komunikasi jaringan privat dan aman. Sumber daya dalam jaringan virtual dapat berkomunikasi melalui alamat IP privat yang ditetapkan 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.

Pada diagram sebelumnya:

• Instans server fleksibel Azure Databases 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 VNET untuk zona DNS privat sebelum aplikasi itu dapat mengakses server fleksibel.

Konsep jaringan virtual

Jaringan virtual Azure memuat ruang alamat IP privat yang dikonfigurasi untuk Anda gunakan. 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.

Berikut adalah beberapa konsep yang harus dipahami saat Anda 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 (subnetworks). Subnet memungkinkan Anda melakukan segmentasi jaringan virtual ke ruang alamat yang lebih kecil. Sumber daya Azure disebarkan ke subnet tertentu dalam jaringan virtual.

  Instans server fleksibel Azure Database for PostgreSQL terintegrasi jaringan virtual Anda 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, namun alamat pertama dan terakhir di jaringan atau subnet apa pun tidak dapat ditetapkan ke host individual mana pun. Azure mencadangkan lima IP untuk digunakan secara internal oleh jaringan Azure, yang mencakup dua IP yang tidak dapat ditetapkan ke host, yang disebutkan di atas. Ini memberi Anda 11 alamat IP yang tersedia untuk rentang /28 CIDR, sedangkan satu instans server fleksibel Azure Database for PostgreSQL dengan fitur Ketersediaan Tinggi menggunakan empat alamat. Untuk koneksi Replikasi dan Microsoft Entra, pastikan Tabel Rute tidak memengaruhi lalu lintas. Pola umum dirutekan 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 lompatan berikutnya "Virtual Network"

  Penting

  Nama AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet, dan GatewaySubnet tersimpan dalam Azure. Jangan gunakan salah satu dari ini sebagai nama subnet Anda.

• Grup Keamanan Jaringan (NSG). Aturan keamanan dalam NSG memungkinkan Anda untuk memfilter jenis lalu lintas jaringan yang dapat masuk dan keluar dari subnet jaringan virtual dan antarmuka jaringan. Untuk informasi selengkapnya, lihat Pratinjau NSG.

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

  • Menggabungkan mesin virtual ke ASG, atau menghapus mesin virtual dari ASG.
  • Menerapkan aturan secara dinamis pada mesin virtual tersebut, atau menghapus aturan dari mesin virtual tersebut.

  Untuk informasi selengkapnya, lihat Gambaran Umum ASG.

  Saat ini, kami tidak mendukung NSG di mana ASG adalah bagian dari aturan dengan server fleksibel Azure Database for PostgreSQL. Kami saat ini menyarankan penggunaan pemfilteran sumber atau tujuan berbasis-IP pada NSG.

  Ketersediaan tinggi dan fitur lain dari server fleksibel Azure Database for PostgreSQL memerlukan kemampuan untuk mengirim/menerima lalu lintas ke port tujuan 5432 dalam subnet jaringan virtual Azure tempat server fleksibel Azure Database for PostgreSQL disebarkan, dan ke penyimpanan Azure untuk pengarsipan log. Jika Anda membuat Grup Keamanan Jaringan (NSG) untuk menolak arus lalu lintas ke atau dari instans server fleksibel Azure Database for PostgreSQL Anda dalam subnet tempatnya disebarkan, pastikan untuk mengizinkan lalu lintas ke port tujuan 5432 dalam subnet, dan juga ke penyimpanan Azure dengan menggunakan tag layanan Azure Storage sebagai tujuan. Anda selanjutnya dapat memfilter aturan pengecualian ini 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 menggunakan tag layanan Microsoft Entra. Saat menyiapkan Replika Baca di seluruh wilayah Azure, server fleksibel Azure Database for PostgreSQL memerlukan kemampuan untuk mengirim/menerima lalu lintas ke port tujuan 5432 untuk primer dan replika, serta penyimpanan Azure di wilayah primer dan replika dari server utama dan replika. Port TCP tujuan yang diperlukan untuk Azure Storage adalah 443.

• Integrasi zona DNS privat. Integrasi zona DNS privat Azure memungkinkan Anda menyelesaikan DNS privat dalam VNET terkini atau VNET yang di-peering di 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 menggunakan akses jaringan privat dengan jaringan virtual Azure, menyediakan informasi zona DNS privat wajib untuk dapat melakukan resolusi DNS. Untuk pembuatan instans server fleksibel Azure Database for PostgreSQL baru menggunakan akses jaringan privat, zona DNS privat perlu digunakan saat mengonfigurasi instans server fleksibel Azure Database for PostgreSQL dengan akses privat. Untuk pembuatan instans server fleksibel Azure Database for PostgreSQL baru menggunakan akses jaringan privat dengan API, ARM, atau Terraform, buat zona DNS privat dan gunakan saat mengonfigurasi instans server fleksibel Azure Database for PostgreSQL dengan akses privat. Lihat informasi selengkapnya mengenai spesifikasi REST API untuk Microsoft Azure. Jika Anda menggunakan portal 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 dibuat secara otomatis dalam langganan Anda.

Jika Anda menggunakan Azure API, templat Azure Resource Manager (templat ARM), atau Terraform, **buat zona DNS privat yang diakhir dengan .postgres.database.azure.com. Gunakan zona tersebut saat 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 tidak dapat menjadi nama yang Anda gunakan untuk salah satu instans server fleksibel Azure Database for PostgreSQL Anda atau pesan kesalahan akan ditampilkan selama provisi. Untuk informasi selengkapnya, lihat Ringkasan zona DNS privat.

Dengan menggunakan portal Azure, API, CLI, atau 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 langganan yang sama atau berbeda.

Penting

Kemampuan untuk mengubah Zona DNS privat dari 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 DNS tersebut. Setelah ditautkan, sumber daya yang dihosting di jaringan virtual tersebut dapat mengakses zona DNS privat.

Penting

Kami tidak lagi memvalidasi kehadiran tautan jaringan virtual pada pembuatan server untuk server fleksibel Azure Database for PostgreSQL dengan jaringan privat. Saat membuat server melalui portal, kami menyediakan pilihan pelanggan untuk membuat tautan pada pembuatan server melalui kotak centang "Tautkan Zona DNS Privat 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 dasar zona ketersediaan, zona reduntant. Untuk informasi selengkapnya, lihat Layanan Azure dengan dukungan zona ketersediaan.

Integrasi dengan server DNS kustom

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

Server DNS kustom harus berada di dalam VNet atau dapat dijangkau melalui pengaturan Server DNS VNET. Untuk mempelajari lebih lanjut, lihat Resolusi nama yang menggunakan server DNS Anda sendiri.

Zona DNS privat 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 disediakan di jaringan virtual lain dari wilayah yang sama atau wilayah yang berbeda, Anda harus menautkan zona DNS privat dengan jaringan virtual. Untuk informasi selengkapnya, lihat Menautkan jaringan virtual.

Catatan

Hanya nama zona DNS privat yang diakhir dengan 'postgres.database.azure.com' yang dapat ditautkan. Nama zona DNS Anda tidak boleh sama dengan instans server fleksibel Azure Database for PostgreSQL Anda jika tidak, resolusi nama akan gagal.

Untuk memetakan Nama server ke catatan DNS, Anda bisa menjalankan perintah nslookup di Azure Cloud Shell menggunakan Azure PowerShell atau Bash, mengganti nama server Anda untuk <parameter server_name> dalam contoh di bawah ini:

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 mengkoordinasikan semua komunikasi ke dan dari spoke. Aturan atau proses TI seperti keamanan dapat memeriksa, merutekan, dan mengelola lalu lintas secara terpusat. Spoke adalah jaringan virtual yang menghosting beban kerja, dan terhubung ke hub pusat melalui peering jaringan virtual. Layanan bersama dihosting di subnet layanan sendiri untuk dibagikan dengan spoke. Subnet perimeter kemudian bertindak sebagai appliance keamanan.

Spoke juga merupakan jaringan virtual di Azure, digunakan untuk mengisolasi beban kerja individu. Arus lalu lintas antara kantor pusat lokal dan Azure terhubung melalui ExpressRoute atau VPN Situs ke Situs, yang terhubung ke jaringan virtual hub. Jaringan virtual dari spoke ke hub diterapkan, dan memungkinkan komunikasi ke sumber daya lokal. 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. Peering jaringan virtual atau terowongan VPN dibuat antara jaringan virtual spoke untuk menyediakan konektivitas langsung tanpa melintasi jaringan virtual hub.
• Spoke berkomunikasi melalui appliance jaringan. Setiap jaringan virtual spoke memiliki peering ke Virtual WAN atau ke jaringan virtual hub. Appliance merutekan lalu lintas dari spoke ke spoke. Appliance dapat dikelola oleh Microsoft (seperti halnya Virtual WAN) atau oleh Anda.
• Gateway Virtual Network yang dilampirkan ke jaringan hub dan memanfaatkan Rute yang Ditentukan Pengguna (UDR), untuk mengaktifkan komunikasi antara spoke.

Gunakan Azure Virtual Network Manager (AVNM) untuk membuat hub baru (dan onboarding yang ada) dan topologi jaringan virtual spoke untuk manajemen pusat kontrol konektivitas dan keamanan.

Komunikasi dengan klien jaringan privat di berbagai wilayah

Sering kali pelanggan memiliki kebutuhan untuk terhubung ke klien wilayah Azure yang berbeda. Lebih khusus lagi, pertanyaan ini biasanya bermunculan ke cara menyambungkan dua VNET (salah satunya memiliki Azure Database for PostgreSQL - Server Fleksibel dan klien aplikasi lain) yang berada di wilayah yang berbeda. Ada beberapa cara untuk mencapai konektivitas tersebut, beberapa di antaranya adalah:

• Peering VNET global. Metodologi yang paling umum, karena ini adalah cara term mudah untuk menghubungkan jaringan di berbagai wilayah bersama-sama. Peering jaringan virtual global membuat koneksi melalui backbone Azure langsung di antara dua VNET yang di-peering. Ini memberikan throughput jaringan terbaik dan latensi terendah untuk konektivitas menggunakan metode ini. Ketika VNET di-peering, Azure juga akan menangani perutean secara otomatis untuk Anda, VNET ini dapat berkomunikasi dengan semua sumber daya di jaringan virtual yang di-peering, yang dibuat di gateway VPN.
• Koneksi VNET-ke-VNET. Koneksi JARINGAN VIRTUAL-ke-VIRTUAL NETWORK pada dasarnya adalah VPN antara dua lokasi Azure yang berbeda. Koneksi VIRTUAL NETWORK-to-VIRTUAL NETWORK dibuat pada gateway VPN. Ini berarti lalu lintas Anda menimbulkan dua lompatan lalu lintas tambahan dibandingkan dengan peering jaringan virtual global. Ada juga latensi tambahan dan bandwidth yang lebih rendah dibandingkan dengan metode tersebut.
• Komunikasi melalui appliance jaringan di arsitektur Hub dan Spoke**. Alih-alih menghubungkan jaringan virtual spoke secara langsung satu sama lain, Anda dapat menggunakan appliance jaringan untuk meneruskan lalu lintas antar spoke. Appliance jaringan menyediakan lebih banyak layanan jaringan seperti inspeksi paket mendalam dan segmentasi atau pemantauan lalu lintas, tetapi mereka dapat memperkenalkan latensi dan hambatan performa jika tidak berukuran benar.

Replikasi di seluruh wilayah Azure dan 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 sedangkan 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.

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

Replikasi di seluruh wilayah Azure, dengan jaringan virtual (VNET) terpisah di setiap wilayah, memerlukan konektivitas di seluruh batas jaringan virtual regional yang dapat disediakan melalui peering jaringan virtual atau di arsitektur Hub dan Spoke melalui appliance jaringan.

Secara default resolusi nama DNS dilingkup ke jaringan virtual. Ini berarti bahwa 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, Anda harus memastikan klien di VNET1 dapat mengakses Zona DNS Privat server fleksibel Azure Database for PostgreSQL. Ini dapat dicapai dengan menambahkan 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 instans server fleksibel Azure Database for PostgreSQL disebarkan 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.
• Ukuran subnet (ruang alamat) tidak dapat ditingkatkan setelah sumber daya ada di subnet
• Sumber daya yang disuntikkan jaringan virtual tidak dapat berinteraksi dengan Private Link secara default. Jika Anda ingin menggunakan Private Link untuk jaringan privat, lihat Jaringan server fleksibel Azure Database for PostgreSQL dengan Private Link

Penting

Azure Resource Manager mendukung kemampuan untuk mengunci sumber daya, sebagai kontrol keamanan. Penguncian sumber daya diterapkan ke sumber daya, dan efektif di semua pengguna dan peran. Ada dua jenis kunci sumber daya: CanNotDelete dan ReadOnly. Jenis kunci ini dapat diterapkan baik ke zona DNS Privat, atau ke rangkaian data individual. Menerapkan kunci jenis terhadap Zona DNS Privat atau kumpulan catatan individual mungkin mengganggu kemampuan server fleksibel Azure Database for PostgreSQL untuk memperbarui catatan DNS dan 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 server fleksibel Azure Database for PostgreSQL.

Nama host

Terlepas dari opsi jaringan yang Anda pilih, kami sarankan Anda selalu menggunakan FQDN sebagai nama host saat menyambungkan ke instans server fleksibel Azure Database for PostgreSQL Anda. Alamat IP server tidak dijamin tetap statis. Menggunakan FQDN membantu Anda menghindari perubahan pada 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

• Portal Azure
• Azure CLI