Tentang koneksi peering

Halaman ini memberikan ringkasan tentang pengelolaan koneksi Peering Jaringan VPC.

Koneksi peering

Koneksi peering menghubungkan dua jaringan Virtual Private Cloud (VPC). Untuk membuat koneksi peering, setiap pihak 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 lainnya.

Pembuatan koneksi peering tidak memberi Anda peran Identity and Access Management apa pun di jaringan VPC lain. Misalnya, jika 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 bertukar rute subnet IPv4 yang menggunakan rentang alamat IPv4 pribadi. Untuk mengetahui informasi selengkapnya tentang opsi pertukaran rute, lihat hal 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 yang tidak disengaja akan menyebabkan gangguan layanan, sebaiknya gunakan mode konsensus. Mode ini memerlukan perjanjian dari kedua jaringan dan mencegah perubahan sepihak pada status efektif koneksi peering.

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

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

Mode independen

Saat 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 berada dalam mode konsensus, setiap permintaan untuk memperbarui atau menghapus koneksi peering memerlukan perjanjian dari kedua jaringan.

Mengonfigurasi mode konsensus untuk koneksi

Anda dapat mengonfigurasi koneksi peering baru atau yang sudah ada untuk menggunakan mode konsensus dengan menetapkan parameter update_strategy:

  • Koneksi baru. Kedua jaringan harus menetapkan strategi pembaruan ke CONSENSUS. Jika strategi pembaruan tidak ditentukan, koneksi akan dibuat dalam mode independen.

  • Koneksi yang ada. Kedua jaringan harus mengubah strategi pembaruan ke CONSENSUS. Hingga kedua nilai cocok, strategi pembaruan efektif tetap INDEPENDENT dan permintaan pembaruan dan penghapusan sepihak diizinkan.

    Permintaan yang tertunda untuk memperbarui mode koneksi tidak menyebabkan waktu henti, dan koneksi tetap aktif saat permintaan sedang berlangsung.

Selain itu, untuk mengonfigurasi mode konsensus untuk koneksi, setiap opsi pertukaran rute dalam konfigurasi Anda harus memiliki nilai yang sama dengan flag pelengkap dalam konfigurasi peer. Jika nilai untuk flag berikut tidak cocok, permintaan untuk membuat atau memperbarui koneksi akan ditolak.

Flag lokal Flag peer pelengkap
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

Misalnya, jika jaringan Anda mengimpor rute kustom, jaringan peer harus mengekspor rute kustom. Jika salah satu nilai ini tidak cocok untuk koneksi yang ada, salah satu jaringan dapat memperbaruinya sebelum atau saat mengubah mode koneksi.

Untuk membatalkan permintaan yang tertunda untuk mengonfigurasi mode konsensus untuk koneksi yang ada, jaringan yang meminta harus mereset strategi pembaruan ke INDEPENDENT.

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

Memperbarui koneksi dalam mode konsensus

Salah satu pihak koneksi peering dapat mengirimkan permintaan pembaruan. Permintaan pembaruan yang tertunda tidak menyebabkan waktu henti, dan koneksi tetap aktif. Jika permintaan penghapusan sedang berlangsung, semua permintaan pembaruan (termasuk menerima atau membatalkan permintaan pembaruan yang tertunda) akan ditolak.

Untuk memperbarui koneksi peering yang dikonfigurasi dengan mode konsensus, administrator jaringan lokal terlebih dahulu memperbarui konfigurasi lokal. Kemudian, administrator jaringan peer harus membuat pembaruan pelengkap ke konfigurasi peer. Misalnya, jika Anda memperbarui flag --export-custom-routes ke true, jaringan peer harus menetapkan flag --import-custom-routes ke true. Status efektif koneksi peering tidak berubah hingga jaringan peer memperbarui konfigurasi yang sesuai.

Setelah konfigurasi peering lokal diperbarui, tidak ada pihak koneksi yang dapat mengirimkan permintaan pembaruan lebih lanjut hingga pembaruan awal diterima atau dibatalkan. Pembaruan sebagian tidak didukung—jika permintaan memperbarui beberapa parameter, semuanya harus diterima atau dibatalkan. Untuk membatalkan pembaruan, jaringan yang meminta akan mereset setiap parameter yang diubah ke nilai sebelumnya.

Diagram berikut menunjukkan cara status koneksi peering berubah saat permintaan pembaruan dikirimkan.

Memperbarui koneksi peering dalam mode konsensus
Memperbarui koneksi peering dalam mode konsensus (klik untuk memperbesar).

Dalam diagram sebelumnya, setelah jaringan A mengirimkan permintaan pembaruan, status pembaruan koneksi berubah dari IN_SYNC menjadi PENDING_PEER_ACKNOWLEDGMENT dalam konfigurasi lokal dan menjadi PENDING_LOCAL_ACKNOWLEDGMENT dalam konfigurasi peer.

Untuk kembali ke status IN_SYNC, jaringan B harus melakukan perubahan pelengkap atau jaringan A harus membatalkan permintaannya. Untuk mengetahui informasi selengkapnya tentang status koneksi ini, lihat Status koneksi.

Untuk memperbarui koneksi peering, lihat Memperbarui koneksi (mode konsensus).

Menghapus koneksi dalam mode konsensus

Untuk menghapus koneksi peering dalam mode konsensus, kedua pihak koneksi harus mengirimkan permintaan penghapusan. Anda dapat membatalkan permintaan penghapusan sebelum atau setelah permintaan tersebut diterima oleh jaringan peer.

Kondisi berikut berlaku untuk permintaan penghapusan:

  • Jika permintaan pembaruan tertunda, Anda masih dapat menghapus koneksi peering.
  • Jika permintaan penghapusan tertunda, semua permintaan pembaruan, termasuk menerima atau membatalkan pembaruan yang tertunda, akan ditolak. Untuk menyelesaikan pembaruan yang tertunda, Anda harus membatalkan permintaan penghapusan terlebih dahulu.

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

Status koneksi

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

Anda dapat melihat status koneksi 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 efektif: INDEPENDENT atau CONSENSUS.
consensusState.deleteStatus
  • UNSPECIFIED: tidak ada requestRemovePeering permintaan yang tertunda untuk koneksi peering ini. Kolom deleteStatus tidak muncul dalam output saat statusnya adalah UNSPECIFIED.
  • 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 koneksi ini telah meminta penghapusan koneksi peering. Permintaan removePeering berikutnya akan berhasil untuk salah satu peering.
  • LOCAL_CANCEL_REQUESTED: koneksi peering berada dalam status DELETE_ACKNOWLEDGED tetapi jaringan lokal telah membatalkan penghapusan.
  • PEER_CANCEL_REQUESTED: koneksi peering berada dalam status DELETE_ACKNOWLEDGED tetapi jaringan peer telah membatalkan penghapusan.
consensusState.updateStatus
  • IN_SYNC: tidak ada pemilik peering yang memiliki pembaruan tertunda.
  • PENDING_PEER_ACKNOWLEDGMENT: pemilik peering lokal telah melakukan perubahan, tetapi pemilik peering yang cocok belum menerapkan perubahan yang sesuai ke peering-nya.
  • PENDING_LOCAL_ACKNOWLEDGMENT: pemilik peering yang cocok telah melakukan perubahan, tetapi pemilik peering lokal belum menerapkan perubahan yang sesuai ke peering ini.

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

Langkah berikutnya