Tentang koneksi peering

Halaman ini memberikan ringkasan tentang cara mengelola koneksi VPC Network Peering.

Koneksi peering

Koneksi peering menghubungkan dua jaringan Virtual Private Cloud (VPC). Untuk membuat koneksi peering, setiap sisi membuat konfigurasi peering secara terpisah yang mereferensikan jaringan lain.

Anda memulai permintaan untuk terhubung ke jaringan VPC lain dengan membuat konfigurasi peering. Setelah jaringan lain memiliki konfigurasi yang sesuai untuk melakukan peering dengan jaringan Anda, koneksi peering akan dibuat dan status peering diubah menjadi ACTIVE di kedua jaringan. Status peering tetap INACTIVE jika jaringan lain tidak memiliki konfigurasi peering yang cocok, yang menunjukkan bahwa jaringan Anda tidak terhubung ke jaringan lain.

Pembuatan koneksi peering tidak memberi Anda peran Identity and Access Management di jaringan VPC lain. Misalnya, jika Anda memiliki peran Compute Network Admin (roles/compute.networkAdmin) atau peran Compute Security Admin (roles/compute.securityAdmin) untuk satu jaringan, Anda tidak menjadi administrator jaringan atau administrator keamanan untuk jaringan lain.

Setelah koneksi peering dibuat, kedua jaringan VPC akan selalu menukar rute subnet IPv4 yang menggunakan rentang alamat IPv4 pribadi. Untuk mengetahui informasi selengkapnya tentang opsi pertukaran rute, lihat artikel berikut:

Mode koneksi

Mode koneksi menentukan cara koneksi peering dikelola. Peering Jaringan VPC mendukung dua mode koneksi:

Untuk deployment standar, mode independen umumnya lebih disukai. Namun, untuk deployment yang mendukung layanan penting yang penghapusan koneksi peering secara tidak sengaja akan menyebabkan gangguan layanan, sebaiknya gunakan mode konsensus. Mode ini memerlukan persetujuan dari kedua jaringan dan mencegah perubahan sepihak pada koneksi peering.

Saat membuat koneksi peering, kedua konfigurasi peering harus menentukan mode koneksi yang sama: baik independen maupun konsensus.

Untuk mengubah mode peering koneksi yang ada dari independen menjadi konsensus, kedua konfigurasi peering harus diperbarui. Mengubah mode koneksi dari konsensus ke independen tidak didukung.

Mode independen

Jika koneksi peering berada dalam mode independen (default), salah satu jaringan dapat memperbarui atau menghapus koneksi kapan saja. Anda dapat membatasi perilaku ini secara opsional dengan memperbarui mode koneksi ke konsensus.

Mode konsensus

Mode konsensus mencegah perubahan sepihak yang tidak disengaja pada perilaku jaringan. Saat koneksi peering dalam mode konsensus, setiap permintaan untuk menghapus koneksi peering memerlukan persetujuan dari kedua jaringan.

Batasan

Memperbarui koneksi peering dalam mode konsensus tidak didukung. Untuk memperbarui opsi pertukaran rute atau parameter konfigurasi lainnya untuk koneksi peering dalam mode konsensus, Anda harus menghapus koneksi, lalu membuatnya ulang dengan parameter konfigurasi yang diinginkan.

Mengonfigurasi mode konsensus untuk koneksi

Anda dapat mengonfigurasi koneksi peering baru atau yang sudah ada untuk menggunakan mode konsensus. Sebelum mengonfigurasi koneksi peering untuk menggunakan mode konsensus, pertimbangkan hal-hal berikut:

  • Parameter update_strategy mengonfigurasi mode koneksi. Untuk mengubah mode koneksi, strategi update di konfigurasi lokal dan peer Anda harus diupdate dari INDEPENDENT ke CONSENSUS. Hingga kedua konfigurasi diperbarui, strategi pembaruan yang efektif tetap INDEPENDENT, dan permintaan penghapusan koneksi sepihak diizinkan.

    Setelah permintaan untuk mengubah mode koneksi dimulai, jaringan peer dapat menerima permintaan tersebut, atau jaringan lokal dapat mengembalikannya.

  • Untuk mengonfigurasi mode konsensus untuk koneksi, setiap opsi pertukaran rute yang ingin Anda gunakan harus memiliki nilai yang sama dengan tanda pelengkap dalam konfigurasi peering yang cocok. Misalnya, jika jaringan Anda mengimpor rute kustom, jaringan lain harus mengekspor rute kustom.

    Jika nilai untuk tanda pelengkap berikut tidak cocok di antara konfigurasi, permintaan untuk memperbarui mode koneksi akan ditolak. Kedua sisi koneksi dapat memperbarui nilai ini sebelumnya atau saat memperbarui mode koneksi.

    Jaringan Anda Jaringan peer
    import_custom_route export_custom_route
    export_custom_route import_custom_route
    import_subnet_routes_with_public_ip export_subnet_routes_with_public_ip
    export_subnet_routes_with_public_ip import_subnet_routes_with_public_ip
    stack_type stack_type
  • Permintaan tertunda untuk memperbarui mode koneksi tidak menyebabkan periode nonaktif, dan koneksi tetap aktif saat permintaan Anda sedang diproses.

Untuk mengetahui informasi selengkapnya, lihat Membuat koneksi peering dalam mode konsensus dan Memperbarui koneksi ke mode
konsensus.

Menghapus koneksi dalam mode konsensus

Untuk menghapus koneksi peering dalam mode konsensus, kedua sisi koneksi harus mengirimkan permintaan penghapusan sebelum koneksi dapat dihapus. Setelah permintaan penghapusan dimulai, permintaan tersebut tidak dapat dibatalkan.

Untuk mengetahui informasi selengkapnya, lihat Menghapus koneksi (mode konsensus).

Status koneksi

Perintah gcloud compute networks describe menampilkan status efektif koneksi peering dan konfigurasi peering lokal Anda.

Anda dapat melihat status koneksi yang efektif dengan memeriksa kolom peerings.connectionStatus. Tabel berikut menjelaskan status konfigurasi yang tersedia. Tanda centang menunjukkan bahwa kolom tersedia.

Kolom Mode independen Mode konsensus Deskripsi
trafficConfiguration Menampilkan opsi pertukaran rute efektif dari koneksi peering.
updateStrategy Menampilkan mode koneksi: INDEPENDENT atau CONSENSUS.
consensusState.deleteStatus
  • UNSPECIFIED: tidak ada permintaan requestRemovePeering yang tertunda untuk koneksi peering ini.
  • LOCAL_DELETE_REQUESTED: pemilik peering ini telah meminta penghapusan koneksi peering.
  • PEER_DELETE_REQUESTED: pemilik peering yang cocok telah meminta penghapusan koneksi peering.
  • DELETE_ACKNOWLEDGED: kedua pemilik peering dari koneksi ini telah meminta penghapusan koneksi peering. Permintaan removePeering berikutnya akan berhasil untuk peering mana pun.
consensusState.updateStatus
  • IN_SYNC: tidak ada pemilik peering yang memiliki update tertunda.
  • PENDING_PEER_ACK: pemilik peering lokal telah melakukan perubahan, tetapi pemilik peering yang cocok belum menerapkan perubahan yang sesuai pada peering-nya.
  • PENDING_LOCAL_ACK: pemilik peering yang cocok telah melakukan perubahan, tetapi pemilik peering lokal belum menerapkan perubahan yang sesuai pada peering ini.

Untuk mencantumkan semua konfigurasi peering dalam Google Cloud project, lihat Mencantumkan koneksi peering.

Langkah berikutnya