Dokumen ini mengenai membahas pola arsitektur untuk menemukan dan mengumpulkan informasi mengenai aset pada Google Cloud, pada platform cloud lainnya, dan pada penyimpanan lokal dengan menggunakan pendeteksi berbasis cloud ServiceNow. Dokumen ini ditujukan untuk tim arsitektur atau tim operasional cloud yang terbiasa dengan IT operations management (ITOM); Information technology infrastructure library (ITIL); layanan Google Cloud seperti mesin Compute Engine, Google Kubernetes Engine (GKE), dan Cloud Asset Inventory; dan ServiceNow Cloud Discovery.
Ringkasan
Banyak perusahaan besar menggunakan penerapan infrastruktur IT hybrid yang menggabungkan Google Cloud, platform cloud lainnya, dan infrastruktur lokal. Penerapan hybrid tersebut biasanya merupakan iterasi awal dalam strategi migrasi cloud. Departemen IT pada perusahaan ini diharuskan untuk menemukan dan melacak semua aset pada ekosistem teknis mereka yang jumlahnya berpotensi mencapai jutaan. Departemen IT harus membuat sistem pengelolaan konfigurasi yang mengikat aset ini dengan layanan teknis yang disediakan aset. Sistem ini juga harus memantau aset dan layanan dengan cara yang mendukung praktik terbaik IT operations management (ITOM) dan IT service management (ITSM).
Untuk pelanggan Google Cloud, arsitektur umum menggunakan ServiceNow, pencarian sumber berbasis cloud untuk mencari dan mengumpulkan informasi tentang aset pada Google Cloud, platform cloud lain, dan penyimpanan lokal. ServiceNow menawarkan berbagai alat untuk mengotomatiskan alur kerja IT pengelolaan resource di beberapa penyedia cloud. Alat seperti Cloud Operations Workspace memungkinkan departemen IT membuat dasbor referensi multi-cloud dan mengelola konfigurasi yang kompleks melalui antarmuka terpadu (terkadang disebutsingle pane of glass ). Dokumen ini menampilkan serangkaian pola arsitektur untuk skenario, ringkasan komponen tingkat tinggi, dan diskusi tentang pertimbangan desain umum.
Komponen ServiceNow untuk arsitektur ini
Komponen platform ServiceNow dalam pola arsitektur ini mencakup hal berikut:
- Contoh ServiceNow yang berisi configuration management database (CMDB) dari configuration items (CI). Setiap CI mewakili komponen di lingkungan operasional Anda yang terlibat dalam pengiriman layanan digital. CI memiliki beberapa atribut yang berisi metadata spesifik mengenai komponen dan hubungannya dengan CI lainnya.
- Satu atau beberapa Server ServiceNow Management, Instrumentation, and Discovery (MID), yang berjalan di project Google Cloud Anda. Server MID mengumpulkan metadata untuk CI dan menyimpannya di CMDB.
Pola arsitektur ini menentukan beberapa praktik umum untuk mengimpor data Cloud Asset Inventory Google ke penemuan inventaris aset Google Cloud Platform di ServiceNow.
Pola arsitektur untuk pengintegrasian Google Cloud
Dokumen ini membahas pola arsitektur berikut untuk mengintegrasikan Google Cloud ke dalam ServiceNow:
Contoh pola arsitektur ini dirancang untuk deployment hybrid yang mencakup beberapa infrastruktur di Google Cloud dan yang lainnya di cloud ServiceNow. Mereka mendemonstrasikan cara ServiceNow beroperasi di Google Cloud antara infrastruktur yang dikelola Google dan infrastruktur yang dikelola pelanggan. Server MID ServiceNow membuat kueri semua infrastruktur yang dikelola Google dengan menggunakan Cloud API Google. Untuk informasi selengkapnya tentang API yang digunakan, lihat API Google Cloud Platform yang digunakan aplikasi ITOM.
Pada masing-masing pola berikut ini, komponen arsitektur bekerja sama dalam Proses penemuan inventaris aset Google Cloud Platform untuk mengumpulkan informasi mengenai inventaris aset cloud yang diperlukan oleh aplikasi ServiceNow Discovery dan alat terkait.
Pola penemuan Google Cloud
Pola dasar arsitektur penemuan cloud ServiceNow menggunakan Server ServiceNow MID untuk memanggil Google Cloud Assets Inventory dan Google Cloud API lainnya untuk mengumpulkan data mengenai resource seperti berikut:
- Instance VM
- Tag (kunci/nilai)
- Volume penyimpanan dan pemetaan penyimpanan
- Resource pusat data, termasuk jenis hardware
- Jaringan cloud, subnet, dan gateway
- Image
- Load balancer cloud dan zona ketersediaan
- Database cloud dan pengelompokan database
- Penampung (GKE)
- Pemetaan layanan berdasarkan label resource
Dalam pola ini, Server MID tidak memerlukan kredensial, karena tidak perlu login ke VM untuk mengumpulkan data. Hal ini membatasi kemampuan proses penemuan untuk mengumpulkan informasi tambahan. Namun, hal ini memangkas biaya operasional karena tidak perlu mengelola dan merotasi kredensial Server MID.
Diagram berikut mengilustrasikan pola arsitektur ini.
Bagian Google Cloud dari pola ini terdiri dari:
- Satu project Google Cloud (Project Layanan A pada diagram), yang terdiri dari dua load balancer Google Cloud, satu atau lebih instance VM, satu instance GKE, dan satu atau beberapa Server MID ServiceNow. Setiap Server MID berjalan di VM-nya sendiri.
- Project Google Cloud kedua (Project Layanan B pada diagram), yang terdiri dari Server MID yang berjalan di VM-nya sendiri.
- Project Google Cloud ketiga (Host Project C pada diagram), yang terdiri dari interkoneksi partner.
- Layanan terkelola tambahan, seperti Cloud API, BigQuery, dan Cloud Storage.
- Rute jaringan yang disiapkan dari Server MID ke Google Cloud API.
Bagian ServiceNow terdiri dari instance ServiceNow, yang mengambil metadata dari Server MID dan menyimpannya di CMDB.
Pola penemuan berbasis IP tanpa agen dari Google Cloud
Pola arsitektur ini menambahkan Penemuan berbasis IP ke pola penemuan cloud dasar menggunakan tugas batch dan Google Cloud akun layanan untuk login ke VM dan mengumpulkan detail tambahan. Pola ini memerlukan lebih banyak beban operasional untuk mengelola Server MID daripada pola dasar, karena Anda harus mengelola dan merotasi kredensial Server MID. Namun, tindakan ini memperluas proses penemuan di luar data yang disediakan oleh Inventaris Aset Cloud untuk menyertakan data tambahan, seperti berikut:
- Sekuritas dan pengelolaan kredensial OS
- Penemuan yang lebih baik, seperti penemuan berbasis file dan penemuan lisensi
- Rincian OS
- Proses yang berjalan
- Koneksi TCP
- Software yang diinstall
Dalam pola arsitektur ini, satu atau beberapa Server MID ServiceNow berada di Google Cloud, sedangkan instance ServiceNow dihosting di platform cloud ServiceNow. Server MID terhubung ke instance ServiceNow melalui Antrean MID Server External Communication Channel (ECC) (tidak ditampilkan). Arsitektur ini ditampilkan pada diagram berikut.
Bagian Google Cloud dari pola ini terdiri dari:
- Project Layanan A, yang terdiri dari dua load balancer Google Cloud, satu atau beberapa VM, instance GKE, dan satu atau beberapa Server MID ServiceNow. Setiap Server MID berjalan di VM-nya sendiri.
- Project Layanan B, yang terdiri dari Server MID yang berjalan dalam VM-nya sendiri.
- Project Host C, yang terdiri dari interkoneksi partner.
- Layanan terkelola tambahan, seperti Cloud API, BigQuery, dan Cloud Storage.
- ServiceNow Kubernetes Discovery di-deploy pada infrastruktur GKE.
- Rute jaringan yang disiapkan dari Server MID ke Google Cloud API.
- Akun layanan yang memungkinkan Server MID login ke VM Google Cloud mana pun yang memerlukan penemuan alamat IP tanpa server.
- Rute jaringan yang disiapkan dari Server MID ke VM Google Cloud mana pun yang memerlukan penemuan alamat IP tanpa server.
Bagian ServiceNow terdiri dari instance ServiceNow, yang mengambil metadata dari Server MID dan menyimpannya di CMDB.
Penemuan Google Cloud dengan pola Agent Client Collector
Pola arsitektur ini mencakup hal berikut:
- Penemuan cloud awal.
- Satu atau lebih Server MID.
Agen ServiceNow tambahan, Agent Client Collector, yang Anda instal di VM. Agen ini terhubung langsung ke Server MID dan merelai informasi tambahan berikut ke ServiceNow:
- Penemuan mendekati real-time berbasis dorongan
- Pengukuran software
- Tampilan CI live
- Otomasi alur kerja ke server
Diagram berikut mengilustrasikan pola arsitektur ini.
Bagian Google Cloud dari pola ini terdiri dari:
- Project Layanan A, yang terdiri dari dua load balancer Google Cloud, satu atau lebih instance VM, instance GKE, dan satu atau beberapa Server MID ServiceNow. Setiap Server MID berjalan di VM-nya sendiri.
- Project Layanan B, yang terdiri dari Server MID yang berjalan di VM-nya sendiri.
- Project Host C, yang terdiri dari interkoneksi partner.
- ServiceNow Kubernetes Discovery di-deploy pada infrastruktur GKE.
- Layanan terkelola tambahan, seperti Cloud API, BigQuery, dan Cloud Storage.
- Rute jaringan yang disiapkan dari Server MID ke Google Cloud API.
- Rute jaringan yang disiapkan dari Server MID ke VM Google Cloud yang telah menginstal Agen Discovery ServiceNow.
Bagian ServiceNow terdiri dari:
- Instance ServiceNow, yang mendapatkan metadata dari Server MID dan menyimpannya di CMDB.
- Agen penemuan ServiceNow yang diinstal di VM Google Cloud yang dikelola pelanggan.
Alur kerja penemuan aset cloud
Bagian berikut membahas alur kerja penemuan aset Google Cloud. Alur kerja ini berlaku untuk ketiga pola arsitektur yang dijelaskan dalam dokumen ini.
Menginstal dan melakukan konfigurasi komponen ServiceNow
- Mengaktifkan Cloud Asset Inventory API.
- Instal Agent Client Collector pada VM Anda. Untuk informasi selengkapnya, lihat Penginstalan Kolektor Klien Agen.
- Alokasikan resource untuk komputer yang menghosting Server MID.
- Konfigurasikan aturan firewall untuk mengizinkan koneksi pada port 443 antara instance VM dan komputer yang menghosting Server MID.
- Mengonfigurasi konektivitas jaringan MID Server.
- Instal Server MID.
- Konfigurasikan Server MID untuk memanggil Google Cloud API yang relevan. Pastikan Server MID memiliki rute jaringan yang valid untuk memanggil Google Cloud API.
Alur kerja
- Inventaris Aset Cloud menyusun database semua jenis aset yang didukung di lingkungan Google Cloud. ServiceNow menggunakan Inventaris Aset Cloud sebagai sumber untuk mendapatkan informasi tambahan guna memperbarui CMDB.
- Server MID ServiceNow membuat kueri database Inventaris Aset Cloud untuk mengetahui informasi tentang semua aset di lingkungan Google Cloud.
- Server MID menyimpan informasi aset cloud dalam bucket Cloud Storage.
- Tidak semua informasi yang diperlukan dapat diperoleh dari database Inventaris Aset Cloud. Dalam pola tanpa agen, informasi VM tidak menyertakan versi patch OS yang digunakan. Untuk tingkat detail ini, Server MID melakukan pencarian mendalam dengan melakukan hal berikut:
- Server MID membuat tugas batch berdasarkan alamat IP VM yang memerlukan penemuan lebih dalam.
- Dalam tugas batch, Server MID akan login ke setiap VM dan mengkueri OS untuk pembuatan versi patch dan informasi lainnya.
- Jika Kolektor Klien Agen diinstal, data yang mereka ambil akan dipindahkan ke Server MID secara langsung, bukan disimpan dalam database Inventaris Aset Cloud. Untuk informasi selengkapnya, lihat Persiapan Jaringan dan Konfigurasi Server MID.
- Setelah mengumpulkan data penemuan aset, Server MID menyimpannya ke CMDB sebagai berikut:
- Server MID membuat CI di CMDB untuk merepresentasikan kemampuan operasional yang disediakan oleh setiap aset.
- Server MID secara otomatis menemukan label dari Google Cloud dan menyimpannya di CMDB. Label ini dipetakan ke CI secara otomatis dan berguna untuk membuat peta layanan.
Proses alur kerja harus diulang berkala sesuai kebutuhan. Bergantung pada skala dan konfigurasi deployment, Anda dapat memilih penemuan berdasarkan peristiwa atau jadwal. Untuk informasi selengkapnya, lihat "Mengelola siklus proses CI" di Panduan Desain CMDB.
Pertimbangan desain
Bagian berikut menyediakan panduan desain untuk mengimplementasikan salah satu pola arsitektur yang dijelaskan dalam dokumen ini.
Lokasi instance ServiceNow
Untuk sebagian besar kasus penggunaan, sebaiknya lakukan deploy Server MID di Google Cloud. Dengan begitu, instance mendekati aset cloud tempat mereka melakukan penemuan mendalam
Pola arsitektur dalam dokumen ini mengasumsikan bahwa CMDB Anda menyimpan data penemuan untuk semua resource dan semua resource lokal, bukan hanya aset Google Cloud Anda. CMDB dapat disimpan di cloud ServiceNow, di Google Cloud, atau secara lokal. Keputusan akhir terkait lokasi CMDB di lingkungan Anda bergantung pada persyaratan spesifik Anda.
Memutuskan untuk menggunakan agen Server MID
Pertimbangan desain lainnya adalah mengenai penggunaan menggunakan agen Server MID dan akun layanan. Jika proses penemuan Anda perlu mengumpulkan informasi di luar metadata yang disediakan Inventaris Aset Cloud, Anda harus menggunakan infrastruktur Server MID dengan akun layanan, atau sebagai alternatif, Server MID dengan Klien Agen Kolektor. Salah satunya dapat memengaruhi biaya dukungan operasional, yang harus Anda pertimbangkan dalam desain. Pendekatan yang harus digunakan tergantung pada data yang perlu diambil dan bagaimana datanya akan digunakan. Biaya operasional pengambilan data mungkin lebih besar dibandingkan nilai datanya sendiri.
Dukungan multi-region untuk Server MID
Jika perusahaan Anda memerlukan dukungan multi-region dari infrastruktur Server MID, Anda harus merencanakan deploy setiap Server MID setidaknya di dua zona ketersediaan dan mereplikasinya ke region lain.
Implikasi biaya
Saat Anda memilih tempat untuk men-deploy komponen ServiceNow untuk penemuan aset Google Cloud, biaya traffic keluar dan biaya komputasi perlu dipertimbangkan
Biaya traffic keluar
Biaya traffic keluar dikenakan setiap kali data dipindahkan dari Google Cloud. Maka, Anda harus menganalisis biaya traffic keluar untuk kasus penggunaan Anda untuk menentukan opsi penempatan komponen ServiceNow. Biasanya, Server MID yang melakukan penemuan mendalam akan dikenai biaya traffic keluar yang lebih rendah jika dijalankan pada Google Cloud dibandingkan pada cloud lain atau secara lokal.
Biaya komputasi
Komponen ServiceNow yang berjalan di Google Cloud dikenakan biaya komputasi yang harus Anda analisis guna menentukan nilai terbaik bagi perusahaan Anda.
Misalnya, Anda harus mempertimbangkan jumlah Server MID yang Anda deploy di instance Compute Engine Google Cloud. Men-deploy lebih banyak Server MID akan mempercepat proses penemuan aset. Namun, ini akan meningkatkan biaya komputasi, karena setiap Server MID di-deploy dalam instance VM-nya sendiri. Untuk informasi selengkapnya mengenai rencana deploy di satu atau beberapa Server MID, lihat Menginstal beberapa Server MID pada satu sistem.
Pertimbangan dukungan operasional
Deployment Anda kemungkinan mencakup kontrol keamanan jaringan seperti firewall, sistem perlindungan intrusi, sistem deteksi penyusup, dan infrastruktur duplikasi paket. Jika kontrol keamanan jaringan terlalu luas antara Google Cloud dan lingkungan tempat Server MID di-deploy, dapat menimbulkan masalah dukungan operasional. Untuk menghindari masalah ini, sebaiknya Anda host Server MID di Google Cloud atau sedekat mungkin dengan infrastruktur Google Cloud yang akan dikueri oleh penemuan mendalam.
Pengamanan Server MID
Kami merekomendasikan praktik keamanan berikut untuk instance Server MID Anda:
- Pastikan Server MID diisolasi untuk membantu memastikan bahwa hanya administrator tepercaya yang dapat terhubung ke server tersebut.
- Pastikan Server MID terlindungi dari penghapusan.
- Pastikan peran IAM diterapkan untuk membatasi perubahan hanya pada yang disetujui melalui proses ITIL atau melalui pipeline CI/CD.
Pengamanan akun layanan
Kami menyarankan praktik keamanan berikut untuk mengelola akun layanan:
- Jika Anda menghosting server MID di Google Cloud, autentikasi akan ditangani secara otomatis menggunakan akun layanan yang terkait. Jika Anda menghosting server MID di luar Google Cloud, Anda bertanggung jawab untuk membuat kunci akun layanan yang dikelola pengguna untuk autentikasi, lalu mengamankan dan mengaudit kredensial yang persisten. Untuk informasi selengkapnya, lihat Praktik terbaik untuk mengelola kunci akun layanan.
- Pastikan Server MID menggunakan akun layanan yang hanya memiliki peran dan izin IAM yang benar-benar diperlukan untuk penemuan aset. Untuk informasi selengkapnya, lihat Praktik terbaik untuk menggunakan akun layanan.
Struktur Folder dan project
Folder dan project adalah rangkaian dalam hierarki resource Google Cloud. Guna mendukung penemuan aset, struktur folder dan project Anda harus mencerminkan struktur aplikasi dan lingkungan tempat aplikasi di-deploy. Membuat struktur resource dengan cara ini juga memungkinkan ServiceNow memetakan aset Anda ke layanan teknis yang disediakan.
Perhatikan perubahan yang Anda lakukan pada struktur folder dan project untuk mendukung penemuan ServiceNow. Peran utama struktur folder dan project adalah untuk mendukung penagihan dan akses IAM. Oleh karena itu, setiap perubahan yang Anda lakukan untuk mendukung ServiceNow harus mendukung dan selaras dengan struktur penagihan Google Cloud organisasi Anda. Untuk praktik terbaik dalam menyusun struktur organisasi, folder, dan hierarki project Google Cloud Anda, lihat Hierarki resource serta Membuat dan mengelola organisasi singkat berikut.
Diagram berikut menunjukkan contoh hierarki resource Google Cloud secara lengkap. Pada contoh berikut, struktur folder menentukan aplikasi, dan setiap project menentukan lingkungan.
Pelabelan
Label adalah key-value pair yang dapat Anda tempatkan ke resource cloud. (ServiceNow, AWS, dan Azure merujuk ke label sebagai tag.)
ServiceNow menggunakan label yang Anda tempatkan pada aset Google Cloud untuk mengidentifikasi aset dan secara opsional memetakannya ke layanan. Memilih skema pelabelan yang baik akan membantu ServiceNow memantau infrastruktur Anda untuk membuat pelaporan yang akurat dan kesesuaian ITOM/ITSM.
Kami sarankan gunakan label untuk setiap resource yang memerlukan identifikasi unik, yang lebih spesifik dari yang diizinkan oleh struktur folder dan project Anda. Misalnya, Anda mungkin menggunakan label dalam kasus berikut:
- Jika terdapat persyaratan kepatuhan yang ketat untuk aplikasi, Anda dapat melabeli semua resource aplikasi sehingga organisasi Anda dapat mengidentifikasi dengan mudah semua infrastruktur yang berada dalam cakupan.
- Dalam lingkungan multi-cloud, Anda dapat menggunakan label untuk mengidentifikasi penyedia dan region cloud dari semua resource.
- Jika Anda memerlukan visibilitas yang lebih mendetail dari ketersediaan default laporan Penagihan Google Cloud atau ekspor Penagihan Cloud ke BigQuery , data tersebut dapat difilter menurut label.
Google akan otomatis memindahkan label ke aset yang dikelola Google yang berjalan di VPC Anda. Label yang ditetapkan Google berawalan goog-. Server MID Anda tidak diperbolehkan melakukan pemeriksaan mendalam pada aset ini. Untuk informasi selengkapnya tentang label untuk resource yang dikelola Google, lihat Pemetaan Berbasis Tag dan Memberi label pada resource secara otomatis berdasarkan notifikasi real-time Inventaris Aset Cloud
Tabel berikut mencantumkan label yang ditetapkan oleh layanan Google Cloud ke resource yang dikelola layanannya.
| Layanan Google Cloud | Label atau prefiks label |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
Untuk mendukung pengelolaan resource secara efektif, proses deployment organisasi Anda harus membuat struktur project dan folder, serta menetapkan label aset secara konsisten di seluruh organisasi. Ketidakkonsistenan dalam infrastruktur dan pelabelan menyulitkan dalam mempertahankan kesesuaian CMDB tanpa proses manual yang cenderung tidak dapat didukung dan menimbulkan tantangan penskalaan dalam jangka panjang.
Berikut daftar praktik terbaik untuk membuat proses deployment Anda konsisten dan dapat diulang:
- Gunakan infrastruktur sebagai kode (IaC) atau sistem penyediaan otomatis seperti Terraform, ServiceNow ITOM, atau Penyediaan dan tata kelola cloud dengan Google Cloud Deployment Manager.
- Siapkan proses tata kelola yang baik untuk label Anda. Untuk ringkasan tentang tata kelola pelabelan, lihat Tata Kelola Tag dalam dokumentasi ServiceNow.
Langkah selanjutnya
- Untuk tambahan praktik terbaik guna menyusun struktur resource Penagihan Cloud, lihat Panduan Pengelolaan Akses & Organisasi Resource Penagihan Cloud dan panduan penyiapan Cloud Insights untuk Google Cloud.
- Untuk mengetahui praktik terbaik dalam menyusun izin IAM organisasi Anda, lihat Praktik terbaik untuk akun dan organisasi perencanaan serta Penyediaan dan Tata Kelola Cloud.
- Untuk praktik terbaik dalam merancang struktur kebijakan firewall VPC di seluruh organisasi, lihat Kebijakan firewall hierarkis.
- Pelajari cara menggunakan label untuk mendukung penemuan berbasis tag ServiceNow.
- Pelajari ServiceNow Agent Client Collector, mekanisme push yang berjalan di project Google Cloud Anda dan mengirim data output ke instance ServiceNow melalui Server MID, menyimpan peristiwa dan metrik dalam {i>database<i} yang relevan.
- Untuk arsitektur referensi, diagram, dan praktik terbaik lainnya, telusuri Pusat Arsitektur Cloud.