Merancang workload Anda

Last reviewed 2024-07-24 UTC

Dokumen ini membantu Anda mendesain workload dengan cara yang meminimalkan dampak ekspansi dan migrasi workload di masa mendatang ke platform Google Cloud lainnya region, atau dampak migrasi workload di seluruh region. Ini dokumen ini berguna jika Anda berencana melakukan salah satu dari aktivitas ini atau jika Anda sedang mengevaluasi peluang untuk melakukannya di masa depan dan ingin mengeksplorasi hasil kerja Anda.

Dokumen ini adalah bagian dari rangkaian:

Panduan dalam seri ini juga berguna jika Anda tidak merencanakan migrasi lintas wilayah atau untuk perluasan ke beberapa wilayah terlebih dahulu. Dalam kasus ini, Anda mungkin perlu melakukan upaya tambahan untuk menyiapkan infrastruktur, workload, dan data untuk migrasi antar-region dan untuk perluasan ke di beberapa region.

Dokumen ini membantu Anda melakukan tindakan berikut:

  1. Menyiapkan zona pendaratan
  2. Menyiapkan workload untuk migrasi di seluruh region
  3. Menyiapkan resource komputasi
  4. Menyiapkan resource penyimpanan data
  5. Persiapan untuk penonaktifan lingkungan sumber

Menyiapkan zona pendaratan

Bagian ini berfokus pada pertimbangan yang harus Anda buat untuk memperluas zona landing (juga disebut fondasi cloud) saat bermigrasi lintas region.

Langkah pertama adalah mengevaluasi kembali berbagai aspek pada {i>landing page <i}yang ada zona waktu. Sebelum dapat memigrasikan beban kerja, Anda harus sudah memiliki zona landing diterapkan. Meskipun Anda mungkin sudah memiliki zona landing untuk wilayah tersebut yang menghosting beban kerja, zona landing mungkin tidak mendukung deployment di region yang berbeda, sehingga harus diperluas ke region target. Beberapa zona pendaratan yang sudah ada mungkin memiliki desain yang dapat mendukung wilayah lain tanpa pengerjaan ulang yang signifikan terhadap zona pendaratan (untuk misalnya, Pengelolaan Akses dan Identitas, atau pengelolaan resource). Namun, informasi tambahan faktor seperti jaringan atau data mungkin mengharuskan Anda melakukan perencanaan untuk . Proses evaluasi ulang Anda harus mempertimbangkan aspek utama persyaratan workload untuk memungkinkan Anda menyiapkan fondasi umum bisa menjadi spesialis nanti selama migrasi.

Pertimbangan perusahaan

Dalam hal aspek-aspek seperti standar industri dan pemerintah, peraturan, dan sertifikasi, memindahkan workload ke region lain dapat persyaratan yang berbeda. Workload yang berjalan di region Google yang secara fisik yang berlokasi di negara yang berbeda harus mematuhi hukum dan peraturan yang berlaku di negara. Selain itu, standar industri yang berbeda mungkin memiliki persyaratan untuk workload yang berjalan di luar negeri (terutama dalam hal keamanan). Karena region Google Cloud dibangun untuk menjalankan resource dalam satu negara tertentu, terkadang workload dimigrasikan dari region Google lain ke negara untuk mematuhi peraturan tertentu. Saat Anda melakukan operasi "di dalam negara" migrasi data, penting untuk mengevaluasi kembali data yang berjalan di infrastruktur lokal untuk memeriksa region baru memungkinkan migrasi data Anda ke Google Cloud.

Pengelolaan akses dan identitas

Saat merencanakan migrasi, Anda mungkin tidak perlu merencanakan banyak perubahan identitas dan akses untuk region yang sudah ada di Google Cloud. Keputusan identitas di Google Cloud dan akses ke resource biasanya berdasarkan sifat sumber daya, bukan wilayah tempat sumber daya tersebut sedang berjalan. Beberapa pertimbangan yang mungkin perlu Anda pertimbangkan adalah sebagai berikut:

  • Desain tim: Beberapa perusahaan disusun untuk memiliki tim untuk menangani sumber daya yang berbeda. Saat beban kerja dimigrasikan ke wilayah lain, karena perubahan struktur resource, mungkin menjadi kandidat terbaik untuk bertanggung jawab atas sumber daya tertentu, di dalam kasus ini, akses harus disesuaikan.
  • Konvensi penamaan: Meskipun konvensi penamaan mungkin tidak memiliki dampak teknis pada fungsi, beberapa pertimbangan mungkin diperlukan jika ada sumber daya yang didefinisikan dengan konvensi nama yang mengacu pada wilayah tertentu. Satu contoh umumnya adalah ketika sudah ada beberapa region replika, seperti virtual machine Compute Engine (VM), yang diberi nama dengan region sebagai awalan, misalnya, europe-west1-backend-1. Selama proses migrasi, untuk menghindari kebingungan atau, lebih buruk lagi, merusak pipeline yang bergantung pada konvensi penamaan tertentu, maka penting untuk mengubah nama untuk mencerminkan wilayah baru.

Konektivitas dan jaringan

Desain jaringan Anda memengaruhi beberapa aspek dalam cara migrasi dijalankan, jadi penting untuk mengatasi desain ini sebelum Anda merencanakan cara memindahkan beban kerja.

Perlu diingat bahwa konektivitas lokal dengan Google Cloud adalah salah satu yang harus dievaluasi ulang dalam migrasi, karena migrasi dapat dirancang untuk bersifat spesifik per region. Salah satu contoh dari faktor ini adalah Cloud Interconnect, yang terhubung ke Google Cloud melalui lampiran VLAN ke region. Anda harus mengubah region tempat lampiran VLAN terhubung sebelum menutup region tersebut untuk menghindari traffic antar-region. Faktor lain perlu dipertimbangkan adalah jika Anda menggunakan Partner Interconnect, memigrasikan wilayah dapat membantu Anda memilih lokasi fisik yang berbeda untuk untuk menghubungkan lampiran VLAN ke Google Cloud. Pertimbangan ini juga relevan jika Anda menggunakan Cloud VPN dan memutuskan untuk mengubah alamat subnet migrasi: Anda harus mengkonfigurasi ulang {i> router<i} Anda untuk mencerminkan jaringan baru.

Meskipun virtual private cloud (VPC) di Google Cloud merupakan resource global, satu subnet selalu terikat dengan satu region, yang berarti Anda tidak dapat menggunakan untuk workload setelah migrasi. Karena {i>subnet<i} tidak boleh tumpang tindih IP, untuk mempertahankan alamat yang sama, Anda harus membuat VPC baru. Proses ini disederhanakan jika Anda menggunakan Cloud DNS, yang dapat memanfaatkan fitur seperti DNS peering untuk merutekan traffic bagi beban kerja yang dimigrasikan sebelum menutup workload lama teritorial Anda.

Untuk mengetahui informasi selengkapnya tentang cara membangun fondasi di Google Cloud, lihat Bermigrasi ke Google Cloud: Bangun fondasi Anda.

Menyiapkan workload untuk migrasi di seluruh region

Baik Anda menyiapkan infrastruktur di Google Cloud dan Anda berencana untuk bermigrasi ke region lain nanti, atau Anda sudah berada di Google Cloud dan Anda perlu bermigrasi ke region lain, Anda harus memastikan bahwa workload dapat dimigrasikan dengan cara yang paling mudah untuk mengurangi upaya dan meminimalkan risiko. Untuk membantu Anda memastikan bahwa semua beban kerja dalam status mengizinkan jalur ke migrasi, sebaiknya Anda melakukan pendekatan berikut:

  • Pilih desain jaringan yang mudah direplikasi dan dikaitkan secara longgar dari topologi jaringan tertentu. Google Cloud menawarkan berbagai produk yang dapat membantu Anda memisahkan konfigurasi jaringan Anda saat ini dari sumber daya yang menggunakan jaringan tersebut. Channel contoh dari produk tersebut adalah Cloud DNS, yang memungkinkan Anda memisahkan IP subnet dari VM.
  • Siapkan produk yang mendukung konfigurasi multi-region atau global. Produk yang mendukung konfigurasi yang melibatkan lebih dari satu region, biasanya menyederhanakan proses migrasi ke region lain.
  • Pertimbangkan layanan terkelola dengan replika lintas region terkelola untuk data. Seperti yang dijelaskan di bagian berikut dalam dokumen ini, beberapa layanan terkelola memungkinkan Anda membuat replika di region yang berbeda, biasanya untuk pencadangan untuk tujuan ketersediaan tinggi. Fitur ini bisa jadi penting untuk memigrasikan data dari satu region ke region lain.

Beberapa layanan Google Cloud dirancang untuk mendukung deployment multi-region atau deployment global. Anda tidak perlu memigrasikan layanan ini, meskipun Anda mungkin perlu menyesuaikan beberapa konfigurasi standar.

Menyiapkan resource komputasi

Bagian ini berisi ringkasan tentang resource komputasi di Google Cloud dan prinsip desain untuk mempersiapkan migrasi ke region lain.

Dokumen ini berfokus pada produk komputasi Google Cloud berikut:

Compute Engine

Compute Engine adalah layanan Google Cloud yang menyediakan VM untuk pelanggan.

Untuk memigrasikan resource Compute Engine dari satu region ke region lain, Anda harus mengevaluasi berbagai faktor selain pertimbangan jaringan.

Sebaiknya Anda melakukan hal berikut:

  • Periksa resource komputasi: Salah satu batasan pertama yang dapat Anda temukan ketika mengubah region hosting VM adalah ketersediaan platform CPU di wilayah target baru. Jika Anda harus mengubah seri mesin selama migrasi, periksa apakah sistem operasi VM Anda saat ini didukung untuk serial ini. Secara umum, masalah ini dapat diperluas ke setiap file Google Cloud layanan komputasi (beberapa wilayah baru mungkin tidak memiliki layanan seperti Cloud Run atau Cloud GPU), jadi sebelum Anda merencanakan migrasi, pastikan memastikan bahwa semua layanan komputasi yang Anda butuhkan tersedia di region tujuan.
  • Mengonfigurasi load balancing dan penskalaan: Compute Engine mendukung traffic load balancing antara instance Compute Engine dan penskalaan otomatis untuk menambah atau menghapus virtual machine dari MIG secara otomatis, sesuai dengan permintaan. Sebaiknya Anda mengonfigurasi load balancing dan penskalaan otomatis untuk meningkatkan keandalan dan fleksibilitas lingkungan bisnis, guna menghindari beban pengelolaan solusi yang dikelola sendiri. Sebagai informasi selengkapnya tentang cara mengonfigurasi load balancing dan penskalaan untuk Compute Engine, lihat Load balancing dan penskalaan.
  • Gunakan nama DNS zona: Untuk mengurangi risiko pemadaman layanan lintas regional, sebaiknya Anda menggunakan nama DNS zona untuk mengidentifikasi virtual machine secara unik menggunakan nama DNS di lingkungan Anda. Google Cloud menggunakan nama DNS zona untuk Virtual machine Compute Engine secara default. Untuk mengetahui informasi selengkapnya tentang cara kerja DNS internal Compute Engine, lihat Ringkasan DNS internal. Untuk memfasilitasi migrasi mendatang di seluruh di region, dan agar konfigurasi Anda lebih mudah dikelola, sebaiknya Anda mempertimbangkan nama DNS zona sebagai parameter konfigurasi yang akhirnya dapat Anda perubahan di masa depan.
  • Gunakan template grup instance terkelola (MIG) yang sama: Dengan Compute Engine, Anda dapat membuat MIG regional yang secara otomatis menyediakan virtual machine di beberapa zona dalam satu wilayah secara otomatis. Jika menggunakan template di wilayah lama, Anda dapat menggunakan template yang sama untuk men-deploy MIG di region baru.

GKE

Google Kubernetes Engine (GKE) membantu Anda men-deploy, mengelola, dan menskalakan dalam container workload di Kubernetes.

Guna menyiapkan workload GKE untuk dimigrasikan, pertimbangkan poin desain dan fitur GKE berikut:

  • Mesh Layanan Cloud: Penerapan mesh Istio yang terkelola. Mengadopsi Mesh Layanan Cloud untuk cluster memungkinkan Anda memiliki tingkat kontrol yang lebih besar pada jaringan traffic ke cluster. Salah satu fitur utama Cloud Service Mesh adalah Anda dapat membuat mesh layanan di antara dua cluster. Anda dapat menggunakan fitur ini untuk merencanakan migrasi dari satu region ke region lain dengan membuat Cluster GKE di region baru dan menambahkannya ke mesh layanan. Menurut dengan pendekatan ini, Anda dapat mulai men-deploy workload di mengelompokkan dan mengarahkan lalu lintas ke sana secara bertahap, sehingga Anda dapat menguji {i>deploy<i} sembari memiliki opsi untuk melakukan rollback dengan mengedit perutean mesh.
  • Sinkronisasi Konfigurasi: Layanan GitOps yang dibangun pada inti {i> open source<i} yang memungkinkan operator dan administrator platform men-deploy konfigurasi dari satu sumber. Sinkronisasi Konfigurasi dapat mendukung satu atau banyak klaster, sehingga Anda dapat menggunakan satu sumber tepercaya untuk untuk mengonfigurasi cluster. Anda dapat menggunakan fungsi Config Sync ini untuk mereplikasi konfigurasi cluster yang ada di cluster untuk region baru, dan mungkin menyesuaikan resource tertentu untuk region tersebut.
  • Pencadangan untuk GKE: Dengan fitur ini, Anda dapat mencadangkan data persisten cluster secara berkala dan memulihkan data ke cluster yang sama atau ke cluster baru.

Cloud Run

Cloud Run menawarkan pendekatan ringan untuk men-deploy container di Google Cloud. Layanan Cloud Run bersifat regional sumber daya, dan direplikasi di beberapa zona di region tempatnya berada. Jika Anda men-deploy layanan Cloud Run, Anda dapat memilih region tempat men-deploy instance, lalu menggunakan fitur ini untuk men-deploy instance workload di region yang berbeda.

VMware Engine

Google Cloud VMware Engine adalah layanan terkelola sepenuhnya yang memungkinkan Anda menjalankan Platform VMware di Google Cloud. Lingkungan VMware berjalan secara native di Infrastruktur bare metal Google Cloud di lokasi Google Cloud termasuk vSphere, vCenter, vSAN, NSX-T, HCX, dan alat yang sesuai.

Untuk memigrasikan instance VMware Engine ke region yang berbeda, seharusnya membuat cloud pribadi di region baru dan kemudian menggunakan alat VMware untuk memindahkan {i>instance<i}.

Anda juga harus mempertimbangkan DNS dan load balancing di Compute Engine saat merencanakan migrasi. VMware Engine menggunakan Google Cloud DNS, yang merupakan layanan hosting DNS terkelola yang menyediakan Hosting DNS yang dipublikasikan ke internet publik, zona pribadi yang dapat dilihat oleh jaringan VPC, penerusan dan peering DNS untuk mengelola resolusi nama pada jaringan VPC.
Anda rencana migrasi dapat mendukung pengujian konfigurasi DNS dan load balancing multi-region.

Menyiapkan resource penyimpanan data

Bagian ini memberikan gambaran tentang sumber daya penyimpanan data di Google Cloud dan dasar-dasar cara mempersiapkan migrasi ke penyedia lain teritorial Anda.

Keberadaan data yang sudah ada di Google Cloud menyederhanakan migrasi, karena ini menyiratkan bahwa solusi untuk {i>host<i} mereka tanpa atau dapat dihosting di Google Cloud.

Kemampuan untuk menyalin data database ke region yang berbeda dan memulihkan data di tempat lain adalah pola yang umum ditemukan Pemulihan dari Bencana (DR). Karena alasan ini, beberapa pola yang dijelaskan dalam dokumen ini bergantung pada Mekanisme DR seperti pencadangan dan pemulihan database.

Layanan terkelola berikut dijelaskan dalam dokumen ini:

Dokumen ini mengasumsikan bahwa solusi penyimpanan yang Anda gunakan instance regional yang ditempatkan bersama dengan resource komputasi.

Cloud Storage

Penawaran Cloud Storage Storage Transfer Service, yang mengotomatiskan transfer file dari berbagai ke Cloud Storage. Dapat digunakan untuk mereplikasi data ke region untuk pencadangan, dan juga migrasi region ke region.

Cloud SQL

Cloud SQL menawarkan layanan database relasional untuk menghosting berbagai jenis {i>database<i}. Cloud SQL menawarkan fungsi replikasi lintas-region yang memungkinkan data instance direplikasi dalam wilayah yang berbeda. Fitur ini adalah pola umum untuk pencadangan dan pemulihan instance Cloud SQL, tetapi juga memungkinkan Anda mempromosikan replika kedua di region lain ke replika utama. Anda dapat menggunakan fitur ini untuk membuat replika baca di region kedua, lalu mempromosikannya ke replika utama setelah Anda sebagian besar workload standar dan berbasis cloud. Secara umum, untuk database, layanan terkelola menyederhanakan proses replikasi data, untuk mempermudah pembuatan replika di region baru selama migrasi.

Cara lain untuk menangani migrasi adalah dengan menggunakan Database Migration Service, yang memungkinkan Anda memigrasikan database SQL dari sumber yang berbeda ke Google Cloud. Di antara sumber yang didukung ada dan instance Cloud SQL lainnya. Satu-satunya keterbatasan adalah bermigrasi ke region berbeda, tetapi bukan ke project yang berbeda.

Filestore

Seperti yang dijelaskan sebelumnya dalam dokumen ini, fitur pencadangan dan pemulihan Filestore memungkinkan Anda membuat cadangan berbagi file yang dapat dikembalikan ke region lain. Fitur ini dapat digunakan untuk melakukan migrasi region.

Bigtable

Seperti halnya dengan Cloud SQL, Bigtable mendukung replikasi. Anda dapat menggunakan fitur ini untuk mereplikasi model pola yang dijelaskan. Buka Daftar lokasi Bigtable jika layanan tersedia di tujuan teritorial Anda.

Selain itu, seperti halnya dengan Filestore, Bigtable mendukung pencadangan dan pemulihan. Fitur ini dapat digunakan, seperti pada Filestore, untuk mengimplementasikan migrasi dengan membuat dan memulihkannya di instance lain di region baru.

Opsi terakhir adalah mengekspor tabel, misalnya, di Cloud Storage. Ini ekspor akan menjadi {i>host<i} data di layanan lain, dan data itu kemudian tersedia untuk impor ke instance di region tersebut.

Firestore

Lokasi Firestore mungkin terikat dengan keberadaan App Engine di project Anda, yang beberapa skenario memaksa instance Firestore untuk multi-region. Dalam skenario migrasi ini, Anda juga perlu mempertimbangkan akun App Engine untuk mendesain solusi yang tepat untuk Firestore. Bahkan, jika Anda sudah memiliki aplikasi App Engine dengan lokasi us-central atau
europe-west, database Firestore Anda dianggap multi-regional.

Anda memiliki lokasi regional dan Anda ingin bermigrasi ke lokasi lain, tindakan layanan ekspor dan impor terkelola memungkinkan Anda mengimpor dan mengekspor entity Firestore menggunakan bucket Cloud Storage. Metode ini dapat digunakan untuk memindahkan instance dari satu region ke region lainnya. Lainnya adalah menggunakan Firestore fitur pencadangan dan pemulihan. Opsi ini lebih murah dan lebih mudah dipahami dibandingkan impor dan ekspor.

Mempersiapkan penghentian lingkungan sumber

Anda harus mempersiapkan diri terlebih dahulu sebelum menonaktifkan lingkungan sumber dan beralihlah ke project baru.

Secara umum, Anda harus mempertimbangkan hal berikut sebelum menonaktifkan lingkungan sumber:

  • Pengujian lingkungan baru: Sebelum Anda mengalihkan traffic dari lingkungan lama dengan lingkungan baru, Anda dapat melakukan tes untuk memvalidasi keakuratan aplikasi. Selain unit klasik dan yang dapat dilakukan pada aplikasi yang baru dimigrasikan, ada adalah strategi pengujian yang berbeda. Lingkungan baru dapat diperlakukan sebagai lingkungan versi baru dari perangkat lunak dan migrasi lalu lintas dapat yang diterapkan dengan pola umum seperti pengujian A/B digunakan untuk validasi. Pendekatan lainnya adalah mereplikasi lalu lintas yang masuk melalui lingkungan sumber dan di lingkungan baru untuk memeriksa apakah fungsi dipertahankan.
  • Perencanaan Periode nonaktif: Jika Anda memilih strategi migrasi seperti biru-hijau, di mana Anda mengalihkan lalu lintas dari satu lingkungan ke lingkungan lain, mempertimbangkan adopsi periode nonaktif yang direncanakan. Periode nonaktif memungkinkan transisi harus dipantau dengan lebih baik dan untuk menghindari kesalahan yang tidak dapat diprediksi di sisi klien.
  • Rollback: Bergantung pada strategi yang diterapkan untuk memigrasikan traffic, mungkin Anda perlu menerapkan rollback jika terjadi error atau kesalahan konfigurasi lingkungan baru. Agar dapat melakukan rollback Anda harus memiliki infrastruktur pemantauan untuk mendeteksi status lingkungan baru.

Anda hanya dapat mematikan layanan di region pertama setelah pengujian yang diperpanjang di wilayah baru dan ditayangkan di wilayah baru tanpa error. Rab sebaiknya simpan cadangan region pertama dalam jumlah terbatas, hingga Anda yakin bahwa tidak ada masalah di region yang baru dimigrasikan.

Anda juga harus mempertimbangkan jika ingin mempromosikan wilayah lama menjadi tempat bencana pemulihan situs, dengan asumsi belum ada solusi yang tersedia. Pendekatan ini memerlukan desain tambahan untuk memastikan bahwa situs tersebut dapat diandalkan. Untuk selengkapnya informasi tentang cara merancang dan merencanakan DR dengan benar, lihat Panduan perencanaan pemulihan dari bencana.

Langkah Berikutnya

Kontributor

Penulis: Valerio Ponza | Konsultan Solusi Teknis

Kontributor lainnya: