Peralatan jaringan terpusat di Google Cloud

Dokumen ini ditujukan bagi administrator jaringan, arsitek solusi, dan tenaga profesional operasi yang menjalankan peralatan jaringan terpusat di Google Cloud. Pengetahuan terkait Compute Engine dan jaringan Virtual Private Cloud (VPC) di Google Cloud diperlukan.

Lingkungan perusahaan sering kali perlu mengarahkan traffic ke internet, jaringan lokal, cloud lain, atau bahkan ke bagian lain dari lingkungan cloud yang sama melalui peralatan berbasis VM yang divirtualisasikan, yang memantau, mengubah, atau memblokir traffic.

Dokumen ini meninjau beberapa opsi desain yang membagi Jaringan VPC dan menghubungkannya dengan peralatan jaringan virtual yang terpusat. Semua komunikasi antara jaringan VPC, jaringan lokal, dan internet dirutekan melalui perangkat terpusat. Anda dapat men-deploy sekelompok peralatan redundan untuk mendapatkan konfigurasi ketersediaan tinggi. Jika tidak memerlukan ketersediaan tinggi, Anda dapat men-deploy satu peralatan jaringan.

Perutean traffic melalui peralatan virtual mungkin sulit untuk dilakukan. Misalnya di Google Cloud, Anda dapat mengganti rute yang mengarah ke internet dan mengalihkan traffic ke serangkaian peralatan virtual. Namun, perilaku perutean antar-subnetwork dalam jaringan VPC. Perutean antar-subnetwork bersifat otomatis dan rute tersebut tidak dapat dihapus atau diganti.

Selain itu, karena peran penting dari peralatan virtual, peralatan tersebut harus di-deploy dalam konfigurasi sangat tersedia Tindakan ini rumit karena Anda perlu memastikan bahwa semua traffic dirutekan melalui salah satu peralatan virtual dan failover di antara peralatan ini berjalan secara otomatis.

Arsitektur

Diagram berikut menunjukkan kasus penggunaan umum dari beberapa opsi desain yang menampilkan peralatan jaringan virtual yang terpusat.

Opsi desain yang menampilkan peralatan jaringan virtual yang terpusat.

Diagram sebelumnya menunjukkan jalur komunikasi antara jaringan VPC yang tersegmentasi, jaringan lokal, dan internet, serta cara jaringan tersebut dirutekan melalui peralatan jaringan virtual yang terpusat.

Kasus penggunaan utama untuk arsitektur ini

Anda dapat menggunakan arsitektur ini untuk beberapa kasus penggunaan yang melibatkan peralatan jaringan virtual yang dirutekan melalui traffic. Perhatikan hal-hal berikut:

  • Banyak peralatan dari vendor berbeda dapat ditemukan di Google Cloud Marketplace.
  • Beberapa vendor peralatan juga menawarkan image Compute Engine kustom untuk Google Cloud di situs atau halaman dukungan mereka.
  • Anda dapat membuat peralatan virtual sendiri menggunakan software jaringan open source. Anda juga dapat membuat image sendiri.

Vendor sering kali menyediakan arsitektur referensi atau panduan deployment mereka sendiri untuk menjalankan peralatan virtual mereka dalam konfigurasi ketersediaan tinggi. Untuk mengetahui informasi selengkapnya, lihat situs vendor.

Arsitektur referensi dari vendor mungkin tidak mencakup semua opsi yang ditampilkan dalam dokumen ini.

Anda perlu memahami keunggulan dan kekurangan dari masing-masing pendekatan. Kasus penggunaan umum untuk peralatan virtual tempat traffic dirutekan mencakup hal berikut:

  • Firewall generasi berikutnya (NGFWs). Serangkaian set firewall terpusat dijalankan sebagai virtual machine yang memberikan fitur yang tidak tersedia jika Anda menggunakan aturan firewall VPC. Ini adalah kasus penggunaan yang paling umum. Fitur umum produk NGFW meliputi pemeriksaan paket mendalam (DPI) dan firewalling pada lapisan aplikasi. Beberapa firewall NGFW juga menyediakan pemeriksaan traffic TLS/SSL ,serta fungsi jaringan lainnya yang dijelaskan dalam kasus penggunaan pada item berbutir berikut.
  • Intrusion detection system/intrusion prevention system (IDS/IPS). IDS berbasis jaringan memerlukan visibilitas semua semua traffic yang berpotensi berbahaya. Untuk mencegah intrusi, traffic biasanya diblokir langsung oleh IPS di jalur traffic.
  • Proxy transparan. Proxy transparan sering digunakan untuk memantau traffic HTTP(S) dan menerapkan pembatasan pada akses web.
  • Gateway penafsiran alamat jaringan (NAT). Gateway NAT menafsirkan alamat IP dan port. Hal ini membantu, misalnya, untuk menghindari alamat IP yang tumpang tindih. Google Cloud menawarkan Cloud NAT sebagai layanan terkelola, tetapi layanan ini hanya tersedia untuk traffic yang menuju ke internet, bukan untuk traffic lokal atau untuk jaringan Jaringan VPC lainnya di Google Cloud.
  • Firewall aplikasi web (WAF). WAF memblokir traffic HTTP berbahaya yang menuju ke aplikasi web. Google Cloud menawarkan fungsionalitas WAF melalui Kebijakan keamanan Google Cloud Armor. Fungsionalitas yang tepat berbeda antar-vendor WAF, jadi penting untuk menentukan kebutuhan Anda dengan tepat.

Persyaratan umum

Persyaratan untuk perutean traffic melalui peralatan virtual terpusat berbeda-beda berdasarkan kasus penggunaan tertentu. Namun, persyaratan berikut umumnya berlaku:

  • Semua traffic di antara segmen jaringan yang berbeda—misalnya, lingkungan yang dikelola oleh tim yang berbeda, dengan persyaratan keamanan terpisah atau antara modul aplikasi yang berbeda—harus melewati peralatan virtual terpusat.
  • Semua traffic ke atau dari internet ke lingkungan yang aman harus melewati peralatan virtual terpusat.
  • Semua traffic ke atau dari sistem lokal yang terhubung Google Cloud melalui Cloud VPN, Dedicated Interconnect, atau Partner Interconnect harus melewati peralatan virtual terpusat.
  • Beberapa peralatan virtual terpusat disiapkan dalam konfigurasi ketersediaan tinggi dalam konfigurasi aktif/aktif atau aktif/pasif. Failover terjadi secara otomatis jika ada masalah software atau hardware yang muncul pada salah satu peralatan virtual.
  • Semua traffic dirutekan secara stateful, sehingga satu alur traffic antara dua virtual machine selalu melewati peralatan virtual yang sama.
  • Throughput sistem peralatan virtual terpusat dapat diskalakan dengan salah satu dari dua opsi berikut:
    • Menskalakan peralatan virtual secara vertikal: meningkatkan jumlah core atau jumlah memori pada setiap virtual machine.
    • Menskalakan peralatan virtual secara horizontal: meningkatkan jumlah peralatan virtual yang digunakan untuk mendistribusikan traffic.

Opsi arsitektur

Ada beberapa opsi untuk mencapai ketersediaan tinggi di antara peralatan virtual. Terdapat juga beberapa opsi untuk melampirkan segmen jaringan ke peralatan virtual.

Anda dapat menggabungkan opsi apa pun untuk mencapai ketersediaan tinggi dengan opsi apa pun untuk melampirkan segmen jaringan. Opsi umum yang akan dijelaskan nanti dalam dokumen ini adalah arsitektur yang menggunakan Peering Jaringan VPC dan Load Balancer Jaringan passthrough internal sebagai next hop.

Memilih opsi ketersediaan tinggi

Anda dapat membangun arsitektur untuk mencapai ketersediaan tinggi bagi peralatan pusat menggunakan beberapa instance dengan dua cara berikut:

  • Gunakan Load Balancer Jaringan passthrough internal sebagai next hop. Dalam pendekatan ini, Anda menempatkan beberapa peralatan virtual dalam grup instance terkelola di belakang Load Balancer Jaringan passthrough internal. Load balancer ini digunakan sebagai next hop untuk rute default yang menggantikan rute default di Jaringan VPC yang terhubung ke peralatan. Anda dapat menggunakan peralatan baik dalam konfigurasi aktif/aktif, yang merupakan konfigurasi standar, atau dalam konfigurasi aktif/pasif, dengan menggunakan failover untuk Load Balancer Jaringan passthrough internal. Health check mengarahkan traffic ke instance yang responsif. Jika ingin membuat ulang peralatan secara otomatis saat gagal, Anda dapat menggunakan autohealing. Jika perangkat Anda menggunakan beberapa antarmuka jaringan, Load Balancer Jaringan passthrough internal sebagai next hop dapat memiliki backend pada antarmuka jaringan apa pun.

    Diagram berikut menunjukkan topologi penggunaan Load Balancer Jaringan passthrough internal sebagai next hop.

    Topologi penggunaan Load Balancer Jaringan passthrough internal sebagai next hop.

    Diagram sebelumnya menunjukkan grup instance terkelola dalam Jaringan VPC, termasuk beberapa peralatan virtual yang berada di balik Load Balancer Jaringan passthrough internal, yang berfungsi sebagai next hop.

  • Gunakan perutean. Dalam pendekatan ini, rute Google Cloud mengarahkan traffic ke peralatan virtual dari jaringan VPC yang terhubung. Anda dapat menggunakan peralatan baik dalam konfigurasi aktif/pasif dengan menggunakan rute prioritas yang berbeda, atau dalam konfigurasi aktif/aktif saat rute dikonfigurasi dengan rute prioritas yang sama, dalam hal ini Anda menggunakan perutean multi-jalur dengan biaya yang sama (ECMP) untuk mendistribusikan traffic. Anda dapat menggunakan autohealing untuk membantu memastikan bahwa peralatan akan memulai ulang ketika tidak responsif.

    Diagram berikut menunjukkan topologi penggunaan perutean.

    Topologi penggunaan perutean

    Diagram sebelumnya menunjukkan grup instance terkelola dalam jaringan VPC dengan rute Google Cloud mengarahkan traffic ke peralatan virtua dari jaringan VPC yang terhubung.

Menggunakan Load Balancer Jaringan passthrough internal sebagai next hop memiliki keunggulan dibandingkan menggunakan perutean Google Cloud untuk ketersediaan tinggi:

  • Health checks menentukan tempat traffic diteruskan dan membantu memastikan bahwa traffic hanya diteruskan ke instance yang responsif Anda dapat mengekspos health check agar instance lokal atau jalur end-to-end diverifikasi.
  • Anda dapat menyesuaikan timer health check untuk failover yang lebih cepat. Pendekatan ini memberikan waktu failover tercepat jika terjadi instance yang tidak responsif.
  • Denganhashing simetris, Anda dapat memastikan bahwa traffic kembali dirutekan ke virtual machine yang sama dengan traffic keluar.

Penggunaan perutean Google Cloud memiliki keunggulan berikut:

  • Hashing simetris yang konsisten memastikan bahwa paket untuk koneksi tertentu diproses oleh backend VM yang sama baik untuk permintaan maupun respons, tergantung protokol dan pemilihan afinitas sesi. Protokol dan pemilihan afinitas sesi menentukan apakah pelacakan koneksi digunakan atau tidak. Perlu diingat bahwa beberapa kasus penggunaan mungkin akan diuntungkan karena memiliki konfigurasi NAT sumber (SNAT) di instance backend; misalnya, koneksi respons dari satu jaringan ke jaringan lain harus cocok dengan koneksi permintaan terpisah di arah yang sama antara dua jaringan yang sama.

Penggunaan perutean Google Cloud memiliki kekurangan berikut:

  • Health check menghapus dan membuat ulang instance yang tidak responsif dari kumpulan instance. Namun, aliran traffic tidak langsung berubah sebagai respons terhadap health check yang gagal karena menghapus instance yang tidak responsif dan membuat instance baru yang responsif memerlukan waktu. Hal ini menyebabkan waktu failover yang lebih lambat.
  • Waktu failover akan lebih lambat jika Anda menyetel timer health check untuk menghindari penghapusan dan pembuatan ulang instance yang tidak perlu.

Semua traffic protokol didukung, baik Anda menggunakan Load Balancer Jaringan passthrough internal sebagai next hop atau menggunakan perutean Google Cloud. Untuk mengetahui informasi lebih detail tentang dukungan ini, lihatPemrosesan TCP, UDP, dan traffic protokol lainnya.

Demikian pula, kedua solusi mendukung pembatasan rute ke tag jaringan tertentu. Misalnya, VM instance dapat dikelompokkan berdasarkan region untuk menggunakan serangkaian peralatan yang berbeda.

Memilih opsi untuk melampirkan segmen jaringan

Karena perutean antar-subnetwork tidak dapat diganti, segmen jaringan diimplementasikan menggunakan jaringan VPC terpisah. Traffic antara jaringan VPC ini, to an on-premises environment, ke lingkungan lokal, dan ke internet perlu dirutekan melalui peralatan terpusat. Perlu diingat bahwa semua segmen jaringan ini dapat berupa jaringan VPC mandiri atau Jaringan VPC bersama.

Berikut beberapa opsi untuk menghubungkan segmen jaringan:

  • Berbagai antarmuka jaringan. Cara paling sederhana untuk menghubungkan beberapa jaringan VPC melalui peralatan virtual adalah dengan menggunakan beberapa antarmuka jaringan, dengan setiap antarmuka terhubung ke salah satu jaringan VPC. Internet dan konektivitas lokal disediakan melalui satu atau dua antarmuka jaringan terpisah. Dengan banyak produk NGFW, konektivitas internet terhubung melalui antarmuka yang ditandai sebagai tidak tepercaya dalam software NGFW.

    Diagram berikut menunjukkan topologi ini.

    Topologi beberapa jaringan VPC yang terhubung melalui peralatan virtual dengan menggunakan beberapa antarmuka jaringan.

    Diagram sebelumnya menunjukkan beberapa jaringan VPC yang terhubung melalui peralatan virtual dengan menggunakan beberapa antarmuka jaringan. Setiap antarmuka terhubung ke salah satu jaringan VPC Diagram tersebut juga menunjukkan koneksi internet dan koneksi lokal melalui antarmuka jaringan terpisah, termasuk koneksi internet melalui antarmuka yang tidak terpercaya.

  • Peering Jaringan VPC Tipologi ini menggunakan konsep hub-dan-spoke bersama dengan Peering VPC Network. Segmen jaringan diimplementasikan sebagai serangkaian jaringan VPC spoke yang di-peering menggunakan Peering Jaringan VPC dengan jaringan VPC hub, yang trafficnya dirutekan melalui kumpulan peralatan yang terpusat. Rute default atau rute yang mengarah ke Load Balancer Jaringan passthrough internal sebagai next hop, atau ke peralatan virtual secara langsung diekspor sebagai rute kustom melalui Peering Jaringan VPC. Konektivitas internet dan konektivitas lokal disediakan melalui satu atau dua antarmuka jaringan terpisah.

    Diagram berikut menunjukkan topologi ini.

    Topologi penggabungan beberapa antarmuka jaringan dengan Peering Jaringan VPC.

    Diagram sebelumnya menunjukkan kumpulan peralatan virtual terpusat dengan beberapa antarmuka jaringan yang terlampir ke beberapa jaringan VPC hub. Setiap jaringan VPC hub dilampirkan ke beberapa jaringan VPC melalui Peering Jaringan VPC. Traffic antara dua jaringan VPC dirutekan melalui kumpulan peralatan virtual yang terpusat.

  • Menggabungkan beberapa antarmuka jaringan dan Peering Jaringan VPC. Pendekatan ini menggabungkan dua opsi sebelumnya untuk skalabilitas tambahan. Beberapa antarmuka jaringan terlampir ke beberapa jaringan VPC hub, yang masing-masing terhubung ke beberapa jaringan VPC spoke melalui Peering Jaringan VPC. Untuk setiap jaringan VPC hub-dan-spoke, gunakan pendekatan yang sama seperti yang dijelaskan dalam kasus Peering Jaringan VPC.

    Diagram berikut menunjukkan topologi ini.

    Topologi pendekatan hub-dan-spoke digabungkan dengan Peering Jaringan VPC.

    Diagram sebelumnya menunjukkan jaringan VPC hub yang terlampir ke beberapa jaringan VPC melalui Peering Jaringan VPC. Traffic dirutekan melalui kumpulan peralatan virtual terpusat dengan satu antarmuka jaringan di jaringan hub.

Pohon keputusan berikut dapat membantu Anda memutuskan pendekatan terbaik untuk melampirkan segmen jaringan.

Pohon keputusan untuk memilih pendekatan terbaik untuk melampirkan segmen jaringan.

Menggunakan beberapa antarmuka jaringan—pendekatan pertama yang dijelaskan dalam kasus sebelumnya—adalah pendekatan yang paling mudah untuk diterapkan.

Namun, menggunakan beberapa antarmuka jaringan memiliki kekurangan berikut:

  • Anda dibatasi hingga 8 antarmuka jaringan per instance virtual machine. Jika menggunakan satu antarmuka jaringan untuk konektivitas internet dan satu antarmuka untuk konektivitas lokal, Anda hanya dapat menghubungkan 6 segmen jaringan di Google Cloud. Beberapa peralatan memerlukan antarmuka pengelolaan tambahan, yang mana membatasi Anda hingga 5 segmen jaringan.
  • Anda tidak dapat menambahkan atau menghapus antarmuka jaringan setelah instance dibuat.

Penggunaan Peering Jaringan VPC memiliki keunggulan berikut:

  • Anda dapat meningkatkan skala hingga batas koneksi Peering Jaringan VPC dari satu jaringan VPC. Hubungi tim penjualan Google Cloud jika Anda memiliki pertanyaan tentang cara meningkatkan batas ini.
  • Menambahkan atau menghapus jaringan VPC dari arsitektur ini mudah dilakukan dengan menyiapkan Peering Jaringan VPC.

Namun, penggunaan Peering Jaringan VPC memiliki kekurangan berikut:

  • Pendekatan ini sedikit lebih kompleks dibandingkan pendekatan yang menggunakan beberapa antarmuka jaringan.
  • Jumlah VPC yang dapat terhubung masih terbatas dibandingkan dengan pendekatan gabungan

Menggunakan pendekatan gabungan—dengan beberapa antarmuka jaringan dan Peering Jaringan VPC—memiliki keunggulan berikut:

  • Cara ini merupakan pendekatan yang paling skalabel karena batasnya adalah hasil dari batas antarmuka jaringan dan batas koneksi peering VPC. Misalnya, Anda dapat menghubungkan 6 jaringan VPC hub ke antarmuka jaringan yang terpisah, dengan setiap antarmuka memiliki 25 jaringan VPC spoke yang terhubung. Pendekatan ini memberi Anda batas 150 jaringan VPC yang bertukar traffic melalui satu rangkaian peralatan virtual.

Namun, pendekatan ini memiliki kekurangan berikut:

  • Ini merupakan pendekatan yang paling kompleks untuk diterapkan.

Contoh arsitektur

Berikut ini adalah dua contoh arsitektur. Contoh arsitektur pertama menunjukkan cara menggunakan Load Balancer Jaringan passthrough internal untuk ketersediaan tinggi, yang digabungkan dengan Peering Jaringan VPC untuk melampirkan segmen jaringan. Contoh arsitektur kedua, kasus penggunaan khusus, menunjukkan cara merutekan traffic dari satu jaringan VPC bersama di Google Cloud ke lingkungan lokal dan ke internet.

Contoh arsitektur yang menggunakan Peering Jaringan VPC dan Load Balancer Jaringan passthrough internal sebagai next hop

Arsitektur ini merupakan kasus penggunaan umum untuk lingkungan perusahaan, menggunakan Load Balancer Jaringan passthrough internal untuk ketersediaan tinggi yang digabungkan dengan Peering Jaringan VPC untuk melampirkan segmen jaringan.

Diagram berikut menunjukkan topologi arsitektur ini.

Topologi penggunaan Peering Jaringan VPC dan Load Balancer Jaringan passthrough internal sebagai next hop.

Diagram sebelumnya menunjukkan jaringan VPC hub dan beberapa jaringan VPC spoke yang di-peering dengan jaringan VPC hub menggunakan Peering Jaringan VPC. Jaringan VPC hub memiliki 2 instance peralatan virtual dalam grup instance terkelola dibelakang Load Balancer Jaringan passthrough internal. Rute default statis mengarah ke Load Balancer Jaringan passthrough internal sebagai next hop. Rute default statis ini diekspor melalui Peering Jaringan VPC menggunakan rute kustom. Rute default ke gateway internet di jaringan VPC spoke akan dihapus.

Anda dapat memenuhi persyaratan dengan cara berikut:

  • Konektivitas antara spoke bersifat otomatis dirutekan melalui firewall karena Peering Jaringan VPC bersifat non-transitif, sehingga jaringan VPC spoke tidak dapat saling bertukar data secara langsung. Anda dapat mengonfigurasi peralatan virtual untuk menetapkan ketentuan dan kebijakan yang memungkinkan spoke dapat bertukar traffic.
  • Konektivitas ke internet hanya dapat dilakukan melalui peralatan virtual karena rute default ke gateway internet telah dihapus dari jaringan VPC spoke. Peralatan virtual memiliki rute default melalui antarmuka jaringan terpisah, yang dapat ditandai sebagai tidak tepercaya jika terjadi NGFW.
  • Konektivitas ke jaringan lokal dicapai melalui jaringan VPC konektivitas yang terhubung ke peralatan virtual melalui antarmuka jaringan yang terpisah. Koneksi Cloud VPN atau Cloud Interconnect dihentikan di Jaringan VPC konektivitas ini.
  • Ketersediaan tinggi dicapai melalui health check yang disesuaikan pada load balancer internal. Anda dapat mengonfigurasi peralatan sebagai aktif/pasif dengan menggunakan failover untuk Load Balancer Jaringan passthrough internal. Hal tersebut membantu Anda memastikan bahwa traffic selalu mengalir melalui satu peralatan virtual.

Anda dapat menggunakan contoh arsitektur ini jika komunikasi antara berbagai Jaringan VPC yang berbeda melibatkan TCP/UDP atau traffic protokol lain. Solusi ini skalabel hingga batas koneksi Peering Jaringan VPC per jaringan VPC.

Untuk contoh implementasi arsitektur ini dengan gateway NAT sebagai alat virtual, lihat Men-deploy jaringan hub-dan-spoke dengan menggunakan load balancer sebagai next hop. Anda dapat menggunakan pola yang sama untuk men-deploy peralatan virtual lainnya, seperti yang dijelaskan di bagian kasus penggunaan sebelumnya.

Kasus penggunaan khusus dengan satu Jaringan VPC bersama di Google Cloud

Dalam satu penggunaan khusus, tidak ada traffic antara berbagai jaringan VPC yang perlu melewati peralatan virtual. Sebagai gantinya, hanya traffic dari satu jaringan VPC bersama yang dirutekan ke lingkungan lokal dan internet. Anda dapat menerapkan kasus penggunaan ini dengan menggunakan salah satu opsi ketersediaan tinggi yang telah dijelaskan sebelumnya dalam dokumen ini. Kemudian, gabungkan opsi terpilih dengan antarmuka masing-masing jaringan untuk konektivitas ke jaringan VPC bersama, jaringan lokal, dan Google Cloud. Jika Anda menginginkan visibilitas ke traffic antar-subnet tanpa menjalankannya melalui peralatan terpusat, Duplikasi Paket dapat membantu.

Diagram berikut menunjukkan topologi ini.

Topologi kasus penggunaan khusus dengan satu jaringan VPC bersama di Google Cloud.

Diagram sebelumnya menunjukkan traffic dari satu jaringan VPC bersama yang dirutekan ke jaringan lokal dan internet melalui sekumpulan peralatan virtual.

Implementasi arsitektur dengan peralatan virtual

Untuk mengetahui informasi tentang cara menggunakan Peering Jaringan VPC antar-segmen dan Load Balancer Jaringan passthrough internal sebagai opsi ketersediaan tinggi, lihat Men-deploy jaringan hub-dan-spoke dengan menggunakan load balancer sebagai next hop.

Jika Anda ingin men-deploy perangkat dari partner Google Cloud dari Cloud Marketplace, hubungi vendor peralatan Anda, atau telusuri situs vendor untuk mendapatkan panduan tentang cara men-deploy peralatan mereka di Google Cloud.

Langkah selanjutnya