Bagikan melalui

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 Azure Database for PostgreSQL - Server Fleksibel.

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 dapat berkomunikasi melalui alamat IP pribadi 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 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 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:

  • 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 server fleksibel Azure Database for PostgreSQL secara langsung.
  • Aplikasi yang disebarkan di 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 DNS Privat sebelum mereka 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 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 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. Sumber daya Azure disebarkan ke subnet tertentu dalam jaringan virtual.

    Server fleksibel Azure Database for PostgreSQL Anda yang terintegrasi dalam jaringan virtual harus berada dalam 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. Ini memberi Anda 11 alamat IP yang tersedia untuk rentang CIDR /28. Server fleksibel Azure Database for PostgreSQL tunggal 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 AzureActiveDirectory layanan tujuan dan hop Internetberikutnya .
    • Tambahkan aturan dengan rentang IP tujuan yang sama dengan rentang subnet Azure Database for PostgreSQL - Server Fleksibel dan hop Virtual Networkberikutnya .

    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 Pratinjau 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.

    Pada saat ini, kami tidak mendukung NSGs bilamana ASG adalah bagian dari aturan dengan Azure Database for PostgreSQL - Server Fleksibel. Kami saat ini menyarankan penggunaan pemfilteran sumber atau tujuan berbasis-IP pada NSG.

    Ketersediaan tinggi dan fitur lain dari Azure Database for PostgreSQL - Server Fleksibel memerlukan kemampuan untuk mengirim/menerima lalu lintas ke port tujuan 5432 dalam subnet jaringan virtual Azure tempat Azure Database for PostgreSQL - Server Fleksibel disebarkan dan ke Azure Storage untuk pengarsipan log. Jika Anda membuat NSG untuk menolak arus lalu lintas ke atau dari 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.

    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 ke ID Microsoft Entra dengan menggunakan tag layanan Microsoft Entra.

    Saat Anda menyiapkan Replika Baca di seluruh wilayah Azure, Azure Database for PostgreSQL - Server Fleksibel memerlukan kemampuan untuk mengirim atau menerima lalu lintas ke port tujuan 5432 untuk primer dan replika dan ke Azure Storage di wilayah utama dan replika dari server utama dan replika. Port TCP tujuan yang diperlukan untuk Penyimpanan adalah 443.

  • Integrasi zona DNS privat: Integrasi zona DNS Privat Azure memungkinkan Anda menyelesaikan DNS privat dalam jaringan virtual saat ini atau jaringan virtual 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 Anda menggunakan akses jaringan privat dengan jaringan virtual Azure, menyediakan informasi zona DNS Privat wajib untuk dapat melakukan resolusi DNS. Untuk pembuatan server fleksibel Azure Database for PostgreSQL baru dengan menggunakan akses jaringan privat, zona DNS Privat perlu digunakan saat Anda mengonfigurasi server fleksibel Azure Database for PostgreSQL dengan akses privat.

Penting

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

Untuk pembuatan server fleksibel Azure Database for PostgreSQL baru 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 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 bisa 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 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 server fleksibel Azure Database for PostgreSQL Anda, atau Anda akan mendapatkan pesan kesalahan selama 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 DNS Privat dari yang Anda berikan saat membuat server fleksibel Azure Database for PostgreSQL ke zona DNS Privat lain yang ada untuk langganan yang sama atau berbeda.

Penting

Kemampuan untuk mengubah zona DNS Privat dari zona yang Anda berikan saat membuat 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 Azure Database for PostgreSQL - Server Fleksibel 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 dasar zona ketersediaan, zona-redundan. Untuk informasi selengkapnya, lihat Layanan Azure dengan dukungan zona ketersediaan.

Integrasi dengan server DNS kustom

Jika Anda menggunakan server DNS kustom maka Anda harus menggunakan penerus DNS untuk menyelesaikan FQDN Azure Database for PostgreSQL - Server Fleksibel. 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 server fleksibel Azure Database for PostgreSQL dari klien yang disediakan di jaringan virtual lain dari wilayah yang sama atau wilayah lain, 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 server fleksibel Azure Database for PostgreSQL Anda. Jika tidak, resolusi nama gagal.

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

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

Menggunakan desain jaringan privat hub-and-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. Spokes adalah jaringan virtual yang menampung 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 yang digunakan 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 spoke ke hub di-peering 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 WAN virtual atau ke jaringan virtual hub. Appliance merutekan 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-and-spoke baru (dan onboarding yang sudah ada) untuk manajemen pusat kontrol konektivitas dan keamanan.

Komunikasi dengan klien jaringan privat di berbagai wilayah

Sering kali, pelanggan memiliki kebutuhan untuk terhubung ke berbagai wilayah Azure klien. Lebih khusus lagi, pertanyaan ini biasanya bermunculan ke cara menghubungkan dua jaringan virtual (salah satunya memiliki Azure Database for PostgreSQL - Server Fleksibel dan yang lain memiliki klien aplikasi) yang berada di wilayah yang berbeda.

Ada beberapa cara untuk mencapai konektivitas tersebut, termasuk:

  • Peering jaringan virtual global. Metodologi ini adalah 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 jaringan virtual yang di-peering. Metode ini menyediakan throughput jaringan terbaik dan latensi terendah untuk konektivitas. Saat jaringan virtual di-peering, 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 jaringan-ke-jaringan. Koneksi antara jaringan virtual (koneksi jaringan-ke-jaringan) pada dasarnya adalah VPN antara dua lokasi Azure. Koneksi jaringan-ke-jaringan dibuat 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 appliance jaringan dalam arsitektur hub-and-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, 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 - Server Fleksibel 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 terpisah di setiap wilayah, memerlukan konektivitas di seluruh batas jaringan virtual regional yang dapat disediakan melalui peering jaringan virtual atau dalam arsitektur hub-and-spoke melalui appliance jaringan.

Secara default, resolusi nama DNS dilingkup ke jaringan virtual. Setiap klien dalam satu jaringan virtual (VNET1) tidak dapat menyelesaikan Azure Database for PostgreSQL - Flexible Server FQDN di jaringan virtual lain (VNET2).

Untuk mengatasi masalah ini, Anda harus memastikan klien di VNET1 dapat mengakses zona DNS Privat Azure Database for PostgreSQL - Server Fleksibel. Tambahkan tautan jaringan virtual ke zona DNS Privat 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 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 Azure Database for PostgreSQL - Jaringan Server Fleksibel dengan Private Link.

Penting

Azure Resource Manager mendukung kemampuan untuk mengunci sumber daya sebagai kontrol keamanan. Kunci 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 kumpulan catatan individual.

Menerapkan kunci jenis terhadap zona DNS Privat atau kumpulan catatan individual mungkin mengganggu kemampuan Azure Database for PostgreSQL - Server Fleksibel 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 Azure Database for PostgreSQL - Server Fleksibel.

Nama host

Terlepas dari opsi jaringan yang Anda pilih, kami sarankan Anda selalu menggunakan FQDN sebagai nama host saat Anda menyambungkan ke 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