Perlu diperhatikan bahwa Anda sedang melihat dokumentasi Looker. Untuk melihat dokumentasi Looker Studio, buka https://support.google.com/looker-studio.

Halaman ini diterjemahkan oleh Cloud Translation API.

Migrasi mandiri dari Looker (asli) ke Looker (Google Cloud core)

Dokumen ini menguraikan langkah-langkah teknis untuk memigrasikan instance Looker yang ada dari lingkungan Looker (asli) ke Looker (Google Cloud core).

Looker (Google Cloud core) adalah lingkungan deployment yang terintegrasi secara mendalam dengan platform Google Cloud. Looker (inti Google Cloud) dihosting di infrastruktur Google Cloud; Anda dapat mengelolanya langsung melalui konsol Google Cloud; dan memiliki integrasi mendalam dengan banyak produk, layanan, dan kemampuan Google Cloud lainnya.

Sebelum memulai

Pelajari prinsip dan alat Google Cloud dengan meninjau dokumentasi berikut:

Hubungi perwakilan akun Anda untuk mengetahui informasi tentang migrasi dan apakah instance Looker (asli) Anda memenuhi syarat. Jika instance Anda memenuhi syarat, dan jika Anda telah mengupgrade kontrak Looker (asli) yang ada untuk mencakup Looker (Google Cloud core), Anda dapat menyelesaikan langkah-langkah dalam dokumen ini untuk memigrasikan instance.
Untuk mendapatkan izin yang diperlukan guna mempersiapkan migrasi, minta administrator untuk memberi Anda peran IAM berikut pada project Google Cloud tempat instance Looker (inti Google Cloud) akan berada:
- Buat instance Looker (Google Cloud core): Looker Admin (roles/looker.admin).
- Tetapkan peran IAM dalam project Google Cloud Anda: Project IAM Admin (roles/resourcemanager.projectIamAdmin).
- Buat bucket Cloud Storage: Storage Admin (roles/storage.admin).
Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.
Untuk mengelola instance Looker (asli) sebagai persiapan migrasi, Anda harus memiliki peran Looker Admin di instance tersebut.
Buat instance Looker (Google Cloud core) "kosong" baru.

Pastikan untuk memilih edisi, jenis koneksi jaringan (IP publik atau IP pribadi), dan atribut konfigurasi lainnya (CMEK, VPC-SC) yang sesuai untuk instance Looker (inti Google Cloud) baru Anda guna memastikan bahwa instance tersebut memiliki kemampuan yang diperlukan. Beberapa fitur di Looker (Google Cloud core) bergantung pada edisi yang dipilih atau jenis jaringan yang dipilih.

Biarkan instance "kosong"; jangan isi dengan data apa pun seperti file model, pengguna, koneksi, Jelajah, dasbor, atau folder. Selama langkah impor, setelan atau konten apa pun akan dihapus total dan diganti dengan data dari migrasi.

Namun, atribut konfigurasi Looker (inti Google Cloud) yang ditentukan melalui konsol Google Cloud, atau yang hanya dapat ditentukan selama pembuatan instance, tidak akan ditimpa selama proses migrasi.

Ringkasan

Pada tingkat tinggi, proses migrasi terdiri dari langkah-langkah berikut.

Pastikan instance Looker (asli) Anda siap untuk dimigrasikan.
Ekspor data dari instance Looker (asli) Anda.
Impor data ke instance Looker (Google Cloud core) "kosong" yang baru.
Menyelesaikan penyiapan instance Looker (Google Cloud core).
Nonaktifkan instance Looker (asli).

Bagian berikut memberikan detail tentang setiap langkah ini.

Memastikan instance Looker (asli) Anda siap untuk dimigrasikan

Instance Looker (asli) Anda harus memenuhi prasyarat berikut agar memenuhi syarat untuk migrasi:

Instance Looker (asli) Anda harus dikelola oleh Google (dengan kata lain, bukan dihosting pelanggan) dan dihosting di Google Cloud atau Amazon Web Services.
Instance Looker (asli) Anda harus menggunakan versi dalam satu rilis bulanan dari versi Looker (Google Cloud core) saat ini. Untuk menemukan versi Looker (inti Google Cloud) saat ini, lihat catatan rilis Looker dan temukan pengumuman deployment terbaru.

Catatan: Instance Looker (asli) dalam program Extended Support Release (ESR) tidak dapat dimigrasikan hingga diupgrade ke versi yang kompatibel.

Selain itu, lakukan aktivitas berikut sebelum migrasi:

Ada serangkaian kecil perbedaan fitur antara Looker (asli) dan Looker (Google Cloud core). Tinjau perbedaan ini untuk memastikan bahwa fitur di Looker (inti Google Cloud) memenuhi kebutuhan Anda yang berkelanjutan.

Tips: Sebaiknya nonaktifkan fitur di instance Looker (asli) yang tidak memiliki padanan di Looker (Google Cloud core)—misalnya, fitur lama dan fitur Lab—selama beberapa waktu sebelum migrasi, untuk memastikan Anda dapat beroperasi tanpa fitur tersebut.
Jika instance Looker (asli) Anda menggunakan sistem tertutup, setelan untuk opsi Sistem Tertutup harus cocok untuk instance Looker (Google Cloud core) pada saat impor dan instance Looker (asli) pada saat ekspor. Tindakan ini memastikan bahwa Anda tidak akan terkunci dari instance Looker (inti Google Cloud) setelah data diimpor ke dalamnya. Anda dapat memastikan setelannya sama dengan salah satu cara berikut:
- Sebelum mengekspor data Looker (asli), nonaktifkan opsi Closed System di instance Looker (asli) dan pastikan setelan tersebut juga dinonaktifkan di instance Looker (Google Cloud core).
- Sebelum mengekspor data Looker (asli), pastikan opsi Closed System diaktifkan di instance Looker (asli), dan aktifkan setelan tersebut di instance Looker (inti Google Cloud) baru Anda.
Migrasi akan menyalin semua project Mode Produksi dan file model yang dikandungnya, tetapi tidak menyalin project Mode Pengembangan milik masing-masing pengguna. Untuk memastikan file Mode Pengembangan ditransfer melalui migrasi, Anda harus melakukan commit semua file di semua project Mode Pengembangan ke repositori Git sebelum memulai migrasi.

Catatan: Jika instance Anda menggunakan repositori telanjang, repositori ini akan disalin ke instance Looker (Google Cloud core), bukan dibagikan antara instance Looker (asli) dan Looker (Google Cloud core).
Looker (Google Cloud core) hanya mendukung metode autentikasi Google OAuth, SAML, dan OpenID Connect.
- Jika instance Looker (asli) Anda menggunakan metode autentikasi yang berbeda (misalnya, email dan sandi, LDAP, dll.), Anda harus mengonversi semua pengguna ke metode autentikasi yang didukung oleh Looker (inti Google Cloud).
- Jika instance Looker (asli) Anda sudah menggunakan Google OAuth, semua data pengguna akan ditransfer, tetapi Anda tetap harus membuat izin IAM secara manual untuk pengguna di project instance Looker (inti Google Cloud) Anda.
- Jika instance Looker (asli) Anda menggunakan SAML, setelan Gabungkan pengguna menggunakan di halaman panel Admin Autentikasi SAML harus disetel ke Google atau OIDC untuk menghindari error saat Anda menguji autentikasi SAML.
- Jika instance Looker (asli) Anda menggunakan OIDC, setelan Gabungkan pengguna menggunakan di halaman panel Admin Autentikasi OpenID Connect harus disetel ke Google atau SAML untuk menghindari error saat Anda menguji autentikasi OpenID Connect.
- Jika menggunakan penyedia identitas eksternal, Anda harus memperbarui URL callback di penyedia identitas ke URL Looker (Google Cloud core) untuk mengizinkan autentikasi ke instance Looker (Google Cloud core) baru.
- Jika instance Looker (Google Cloud core) Anda akan menggunakan SAML atau OpenID Connect sebagai metode autentikasi, sebaiknya siapkan juga Google OAuth, yang berfungsi sebagai metode autentikasi cadangan untuk Looker (Google Cloud core).
- Jika Anda akan menggunakan domain kustom dengan instance Looker (inti Google Cloud), jangan siapkan SAML atau OpenID Connect untuk instance tersebut hingga domain kustom diaktifkan.
Selama migrasi, dua instance Looker—satu Looker (asli), satu Looker (Google Cloud core)—akan berjalan secara paralel selama beberapa waktu. Setiap aktivitas otomatis yang terjadi (seperti pemberitahuan dan pengiriman data terjadwal, serta aktivitas latar belakang yang mengakses database backend) dapat diduplikasi. Untuk menghindari aktivitas duplikat, hapus pemberitahuan dan jadwal otomatis di instance Looker (asli) atau Looker (Google Cloud core).

Mengekspor data dari instance Looker (asli)

Mengekspor data dari instance Looker (asli) memerlukan dua langkah:

Buat tempat untuk menyimpan data migrasi.
Mulai ekspor.

Membuat tempat untuk menyimpan data migrasi

Lakukan semua operasi berikut di project Google Cloud yang sama tempat Anda membuat instance Looker (Google Cloud core).

Buat bucket Cloud Storage baru (misalnya, <bucket-name>).
- Bucket ini akan digunakan untuk menyimpan data migrasi.
- Ikuti petunjuk di halaman dokumentasi Membuat bucket.
- Perhatikan bahwa <bucket-name> harus unik di seluruh Google Cloud. Sebaiknya beri awalan nama bucket dengan ID unik, seperti project ID Anda.
Tentukan nama untuk folder di dalam bucket Cloud Storage (misalnya, <folder-name>). Jangan buat folder sekarang. Tentukan nama folder selama permintaan ekspor. File ini akan dibuat secara otomatis selama proses ekspor.
Buat key ring dan kunci di Cloud KMS (misalnya, <kms_keyring_id> dan <kms-key-id>).
- Kunci ini akan digunakan untuk mengenkripsi data migrasi. Karena ini adalah kunci KMS, Anda hanya perlu mengungkapkan nama kunci, bukan kunci itu sendiri, ke halaman Export di panel Admin Looker (asli).
- Ikuti petunjuk di halaman dokumentasi Membuat key ring dan Membuat kunci.
Buat akun layanan baru khusus untuk migrasi (misalnya, <export-service-account>).
- Akun ini bukan akun layanan yang sama dengan akun layanan Looker.
- Ikuti petunjuk di halaman dokumentasi Membuat akun layanan.
Berikan dua peran IAM tertentu kepada <export-service-account>:
- Storage Object Creator di bucket Cloud Storage
- Cloud KMS CryptoKey Encrypter di kunci KMS
- Ikuti petunjuk di halaman dokumentasi Menggunakan izin IAM (Cloud Storage) dan Kontrol akses dengan IAM (KMS).
Catatan: Peran yang baru saja dijelaskan memberikan izin minimum yang diperlukan untuk mengekspor data.
Buat kunci akun layanan yang dikaitkan dengan <export-service-account>, dan download file kunci JSON.
- Ikuti petunjuk di halaman dokumentasi Membuat dan menghapus kunci akun layanan.
Perhatian: Kunci akun layanan akan berisiko keamanan jika tidak dikelola dengan benar. Anda bertanggung jawab atas keamanan kunci pribadi dan atas operasi lainnya yang dijelaskan oleh Praktik terbaik untuk mengelola kunci akun layanan. Jika Anda tidak dapat membuat kunci akun layanan, pembuatan kunci akun layanan mungkin dinonaktifkan untuk organisasi Anda. Untuk mengetahui informasi selengkapnya, lihat Mengelola resource organisasi yang aman secara default.

Meminta ekspor

Setelah memastikan bahwa instance Anda siap untuk dimigrasikan, membuat instance Looker (inti Google Cloud) "kosong", dan membuat tempat untuk menyimpan data migrasi, masukkan informasi berikut ke halaman Export di panel Admin instance Looker (asli) Anda:

Nama bucket Cloud Storage yang Anda buat.
Nama folder Cloud Storage - folder dengan nama ini akan otomatis dibuat selama ekspor. Setelah ekspor selesai, file ekspor akan muncul di subfolder berstempel waktu dalam folder ini di bucket Cloud Storage yang Anda buat.
Nama kunci KMS.
Teks JSON yang berisi kunci akun layanan.

Setelah Anda memasukkan informasi di halaman Ekspor, klik Minta Ekspor untuk memulai ekspor.

Proses ekspor memerlukan waktu beberapa menit hingga beberapa jam. Setelah ekspor selesai, Anda akan melihat beberapa file ekspor (dalam format yang tidak dapat dibaca manusia) di bucket dan folder Cloud Storage. File ini adalah input untuk langkah impor berikut.

Mengimpor data ke instance Looker (Google Cloud core) "kosong" baru

Setelah data instance diekspor, Anda dapat mengimpornya ke instance Looker (inti Google Cloud).

Ikuti petunjuk di halaman Mengimpor data dari Cloud Storage ke instance Looker (inti Google Cloud), dengan mengarahkan perintah ke bucket dan folder tempat file ekspor ditempatkan.

Singkatnya, hal ini mencakup hal berikut:

Memberikan peran berikut untuk akses ke bucket dan kunci KMS ke akun layanan Looker (bukan <export-service-account>):
- Storage Object User di bucket Cloud Storage
- Cloud KMS CryptoKey Decrypter di kunci KMS
Memicu impor melalui konsol Google Cloud atau gcloud CLI

Operasi impor memerlukan waktu beberapa menit hingga berjam-jam. Setelah selesai, instance Looker (Google Cloud core) Anda akan dimulai ulang, dengan semua data yang dimigrasikan.

Menyelesaikan penyiapan instance Looker (Google Cloud core)

Pada tahap ini, admin Looker dapat membuka URL instance dan login ke instance untuk menyelesaikan penyiapan.

Proses migrasi menyalin sebanyak mungkin konfigurasi instance Looker (asli). Namun, beberapa item tidak dapat dimigrasikan, atau berfungsi sedikit berbeda di Looker (Google Cloud core), dan harus disesuaikan.

Beberapa item yang diketahui memerlukan perhatian khusus meliputi hal-hal berikut:

Setelan Umum (di panel Admin Looker)	Sebagian besar opsi untuk Setelan Umum (dan setelan lainnya di seluruh panel Admin) tidak otomatis disalin, karena cenderung berbeda atau tidak ada dalam bentuk yang sama di Looker (inti Google Cloud). Anda harus meninjau dan mengonfigurasi semua setelan dengan cermat dalam konteks konfigurasi Looker (inti Google Cloud) yang dipilih. Lihat halaman dokumentasi Mengelola instance Looker (Google Cloud core) dari Looker dan Mengelola instance Looker (Google Cloud core) dari konsol Google Cloud untuk mengetahui informasi selengkapnya tentang setelan di Looker (Google Cloud core).
Pengguna	Looker (Google Cloud core) hanya mendukung metode autentikasi Google OAuth, SAML, dan OpenID Connect. Jika instance Looker (asli) juga dikonfigurasi untuk Google OAuth, data pengguna dan atributnya akan disalin (asalkan dikaitkan dengan ID Google dan alamat email yang sama di kedua instance). Admin IAM Project harus memberikan peran IAM Looker Admin atau Looker Instance User kepada setiap pengguna di project Google Cloud tempat instance berada. Jika instance Looker (asli) dikonfigurasi untuk SAML atau OpenID Connect, pastikan kolom Gabungkan pengguna menggunakan untuk metode autentikasi hanya menunjukkan metode autentikasi yang didukung oleh Looker (inti Google Cloud). Jika beberapa pengguna instance Looker (asli) melakukan autentikasi melalui mekanisme yang tidak didukung di Looker (inti Google Cloud) (seperti LDAP atau email/sandi), akun pengguna tersebut harus dibuat ulang dan dikonversi ke metode autentikasi yang didukung.
Koneksi database	Looker (Google Cloud core) mendukung kumpulan dialek database yang sedikit berbeda dengan Looker (asli). Semua properti konfigurasi untuk koneksi database (termasuk string koneksi dan sandi, jika ada) akan disalin. Namun, topologi jaringan yang berbeda di Looker (inti Google Cloud) dapat mencegah koneksi database berfungsi dengan segera. Misalnya, jika database diakses melalui firewall atau tunnel yang khusus untuk instance Looker (asli), Anda mungkin perlu mengonfigurasi ulang firewall atau tunnel. Anda harus menguji setiap koneksi dan membuat ulang koneksi tersebut jika perlu.
Koneksi database menggunakan OAuth	Migrasi dari Looker (asli) ke Looker (Google Cloud core) tidak mempertahankan akses OAuth atau token refresh untuk koneksi database pengguna individual ke BigQuery atau Snowflake. Setelah migrasi, pengguna Looker (Google Cloud core) akan diminta untuk mengautentikasi ulang OAuth saat mereka melihat Jelajahi atau dasbor yang mereferensikan koneksi database OAuth. Pengguna juga dapat mengautentikasi ulang ke database mereka dengan membuka halaman Akun dan memilih Login untuk setiap database di bagian judul Kredensial Koneksi OAuth. Setiap jadwal atau pemberitahuan otomatis yang dimiliki oleh satu pengguna dan mereferensikan koneksi OAuth akan rusak hingga pengguna tersebut login dengan kredensial OAuth-nya.
Koneksi repositori Git	Jika instance menggunakan repositori Git biasa, instance tersebut akan berfungsi tanpa modifikasi (disalin, tetapi tidak dibagikan). Namun, jika instance terhubung ke repositori jarak jauh, koneksi ini mungkin perlu diverifikasi dan diaktifkan kembali, mirip dengan koneksi database.
Konfigurasi jaringan lainnya	Instance Looker mungkin memiliki jenis koneksi jaringan lain, baik masuk maupun keluar (misalnya, dalam konteks IP pribadi, Action Hub, Marketplace, email, dll.). Koneksi jaringan ini juga harus diverifikasi.
URL untuk mengakses instance Looker (Google Cloud core)	Instance Looker (Google Cloud core) dilengkapi dengan URL utama yang ditetapkan secara acak. Jika instance perlu diakses melalui URL tertentu, Anda dapat mengonfigurasi domain kustom.
Jadwal dan pemberitahuan	Jika instance Looker (asli) dan Looker (Google Cloud core) aktif secara bersamaan, instance tersebut dapat menghasilkan tindakan terjadwal dan pemberitahuan duplikat, serta melakukan operasi latar belakang duplikat yang mengakses database yang terhubung. Aktivitas ini harus dinonaktifkan di salah satu instance sesegera mungkin. Setiap jadwal atau pemberitahuan otomatis yang dimiliki oleh satu pengguna dan mereferensikan koneksi OAuth individual pengguna tersebut akan rusak hingga pengguna tersebut login dengan kredensial OAuth-nya.
Masa pemeliharaan	Tidak seperti di Looker (asli), kebijakan pemeliharaan dapat ditentukan untuk Looker (Google Cloud core).
Aktivitas Sistem Elite	Data Aktivitas Sistem Elite tidak disalin sebagai bagian dari migrasi. Instance Looker (Google Cloud core) akan dimulai dengan histori baru.
Domain kustom	Anda dapat membuat domain kustom untuk instance Looker (Google Cloud core). Anda harus menetapkan data DNS untuk memastikan deployment sertifikat SSL. Selain itu, pastikan untuk memperbarui URL callback di klien autentikasi ke domain kustom setelah domain kustom diaktifkan dan metode autentikasi disiapkan. Domain kustom tidak dapat dibuat untuk Looker (Google Cloud core) menggunakan domain `looker.com`. Jika Anda ingin membuat domain kustom untuk instance Looker (inti Google Cloud) menggunakan URL kustom instance Looker (asli), domain kustom harus disiapkan setelah migrasi selesai dan setelah Anda mengonfirmasi bahwa instance Looker (inti Google Cloud) siap digunakan. Setelah domain kustom diaktifkan, pengguna akan melihat instance Looker (Google Cloud core), bukan instance Looker (asli) saat mereka mengunjungi URL instance. Jangan siapkan SAML atau OpenID Connect untuk instance Looker (inti Google Cloud) hingga instance siap digunakan, data DNS telah diperbarui, dan domain kustom telah diaktifkan.
Bookmark	Jika Anda menggunakan URL kustom di instance Looker (asli) (yang tidak menggunakan domain `looker.com`), proses migrasi ini akan mempertahankan bookmark pengguna jika Anda membuat domain kustom untuk instance Looker (inti Google Cloud) menggunakan URL yang sama dengan instance Looker (asli). Setelah domain kustom diaktifkan, bookmark ke konten Looker (asli) seperti `https://www.yourcustomdomain.com/dashboard/123` akan mengarah ke bagian konten dalam instance Looker (Google Cloud core). (Catatan: Edisi Enterprise dan Embed Looker (inti Google Cloud) menggunakan slug konten alfanumerik di URL-nya, bukan ID konten numerik, tetapi bookmark dengan ID konten akan tetap dialihkan dengan benar ke konten yang sama.) Proses ini tidak dapat digunakan dengan URL Looker (asli) yang menggunakan domain `looker.com`.

Ini bukan merupakan daftar lengkap. Uji semua aspek instance yang paling penting bagi Anda, sebelum menganggap migrasi telah selesai.

Setelah migrasi selesai dan Anda yakin tidak memerlukan ekspor lain, Anda dapat menghapus <export-service-account> yang dibuat sebelumnya, sehingga kunci JSON yang dibagikan untuknya menjadi tidak berguna.

Menghentikan penggunaan instance Looker (asli)

Setelah instance Looker (inti Google Cloud) yang dimigrasikan berfungsi dengan memuaskan, Anda dapat mengirimkan URL untuk instance tersebut kepada pengguna dan meminta mereka untuk mulai mengaksesnya dan berhenti mengakses instance Looker (asli).

Pemecahan masalah

Bagian berikut dapat membantu Anda menyelesaikan masalah selama impor atau ekspor.

Masalah selama ekspor

Jika ada masalah dengan ekspor data Looker (asli) Anda, status ERROR akan muncul di halaman Ekspor pada panel Admin. Mengklik status ERROR akan menampilkan pesan error.

Sumber error yang umum adalah sebagai berikut:

Bucket Cloud Storage, kunci KMS, atau <export-service-account> tidak valid.
<export-service-account> tidak memiliki izin yang diperlukan.

Sebaiknya konfirmasi status objek ini sebelum mengirimkan permintaan ekspor Anda.

Masalah selama impor

Jika operasi impor tidak selesai setelah empat jam (atau mungkin lebih jika instance sumber sangat besar), atau jika operasi tersebut keluar dengan error, Anda mungkin perlu membuka tiket dengan Cloud Customer Care untuk menyelesaikan masalah tersebut. Ada relatif sedikit diagnostik yang dapat dilihat langsung oleh pelanggan untuk operasi ini.