SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Archives for September 2021

Penerapan Instance Cluster Failover SQL Server di Huawei Cloud

by Leave a Comment

Huawei Cloud ketersediaan tinggi ECS IaaS

* PENOLAKAN: Meskipun yang berikut ini sepenuhnya mencakup porsi ketersediaan tinggi dalam cakupan produk kami, ini hanya “panduan” pengaturan dan harus disesuaikan dengan konfigurasi Anda sendiri.

Gambaran AWAN HUAWEI adalah penyedia layanan cloud terkemuka tidak hanya di China tetapi juga memiliki jejak global dengan banyak pusat data di seluruh dunia. Mereka menyatukan lebih dari 30 tahun keahlian Huawei dalam produk dan solusi infrastruktur TIK dan berkomitmen untuk menyediakan layanan cloud yang andal, aman, dan hemat biaya untuk memberdayakan aplikasi, memanfaatkan kekuatan data, dan membantu organisasi dari semua ukuran tumbuh di era sekarang ini. dunia yang cerdas. HUAWEI CLOUD juga berkomitmen untuk menghadirkan layanan cloud dan AI yang terjangkau, efektif, dan andal melalui inovasi teknologi.

DataKeeper Cluster Edition menyediakan replikasi di cloud pribadi virtual (VPC) dalam satu wilayah di seluruh zona ketersediaan untuk cloud Huawei. Dalam contoh pengelompokan SQL Server khusus ini, kami akan meluncurkan empat instance (satu instance pengontrol domain, dua instance SQL Server, dan instance kuorum/saksi) ke dalam tiga zona ketersediaan.

Arsitektur HA Penjaga Data Huawei Cloud SIOS

DataKeeper Cluster Edition menyediakan dukungan untuk node replikasi data di luar cluster dengan semua node di cloud Huawei. Dalam contoh pengelompokan SQL Server khusus ini, empat contoh diluncurkan (satu contoh pengontrol domain, dua contoh SQL Server dan contoh kuorum/saksi) ke dalam tiga zona ketersediaan. Kemudian instans DataKeeper tambahan diluncurkan di wilayah kedua termasuk instans VPN di kedua wilayah. Silahkan lihat Konfigurasi Replikasi Data Dari Node Cluster ke Situs DR Eksternal untuk informasi lebih lanjut. Untuk informasi tambahan tentang penggunaan beberapa wilayah, silakan lihat Menghubungkan Dua VPC di Wilayah Berbeda .

Arsitektur Huawei Cloud SIOS Datakeeper DR

DataKeeper Cluster Edition juga menyediakan dukungan untuk node replikasi data di luar cluster dengan hanya node di luar cluster di Huawei Cloud. Dalam contoh pengelompokan SQL Server khusus ini, WSFC1 dan WSFC2 berada dalam kluster di tempat yang mereplikasi ke instans Huawei Cloud. Kemudian instans DataKeeper tambahan diluncurkan di suatu wilayah di Huawei Cloud. Silahkan lihat Konfigurasi Replikasi Data Dari Node Cluster ke Situs DR Eksternal untuk informasi lebih lanjut.

Arsitektur Hibrid DR Penjaga Data Huawei Cloud SIOS

Persyaratan

Keterangan Persyaratan
Awan Pribadi Virtual Dalam satu wilayah dengan tiga zona ketersediaan
Jenis Instance Jenis instans minimum yang disarankan: s3.large.2
Sistem operasi Lihat Matriks Dukungan DKCE
IP elastis Satu alamat IP elastis yang terhubung ke pengontrol domain
Empat contoh Satu instance pengontrol domain, dua instance SQL Server, dan satu instance kuorum/saksi
Setiap SQL Server ENI (Elastic Network Interface) dengan 4 IP · IP ENI Primer didefinisikan secara statis di Windows dan digunakan oleh DataKeeper Cluster Edition · Tiga IP dikelola oleh ECS saat digunakan oleh Windows Failover Clustering, DTC, dan SQLFC
Volume Tiga volume (hanya EBS dan NTFS) · Satu volume utama (drive C) · Dua volume tambahan o Satu untuk Failover Clustering o Satu untuk MSDTC

Catatan Rilis Sebelum memulai, pastikan Anda membaca Catatan Rilis Edisi DataKeeper Cluster untuk informasi terbaru. Sangat disarankan agar Anda membaca dan memahami Panduan Instalasi DataKeeper Cluster Edition .

Buat Virtual Private Cloud (VPC) Awan pribadi virtual adalah objek pertama yang Anda buat saat menggunakan DataKeeper Cluster Edition.

* Virtual Private Cloud (VPC) adalah cloud pribadi terisolasi yang terdiri dari kumpulan sumber daya komputasi bersama yang dapat dikonfigurasi di cloud publik.

  1. Menggunakan alamat email dan kata sandi yang ditentukan saat mendaftar Huawei Cloud , masuk ke Konsol Manajemen Cloud Huawei .
  2. Dari Jasa tarik-turun, pilih Awan Pribadi Virtual .

  1. Di sisi kanan layar, klik Buat VPC dan pilih wilayah yang ingin Anda gunakan.
  2. Masukkan nama yang ingin Anda gunakan untuk VPC
  3. Tentukan subnet cloud pribadi virtual Anda dengan memasukkan CIDR (Perutean Antar-Domain Tanpa Kelas) seperti yang dijelaskan di bawah ini
  4. Masukkan nama subnet, lalu klik Buat sekarang .

* Tabel Rute akan secara otomatis dibuat dengan asosiasi “utama” ke VPC baru. Anda dapat menggunakannya nanti atau membuat Tabel Rute lain.

* LINK BERMANFAAT: Huawei Membuat Virtual Private Cloud (VPC) Luncurkan Instance Berikut ini memandu Anda dalam meluncurkan instance ke subnet Anda. Anda akan ingin meluncurkan dua instans ke dalam satu zona ketersediaan, satu untuk instans pengontrol domain dan satu untuk instans SQL Anda. Kemudian Anda akan meluncurkan instans SQL lain ke zona ketersediaan lain dan instans saksi kuorum ke zona ketersediaan lain.

* LINK BERMANFAAT: Instans Huawei Cloud ECS

  1. Menggunakan alamat email dan kata sandi yang ditentukan saat mendaftar Huawei Cloud , masuk ke Konsol Manajemen Cloud Huawei .
  2. Dari Daftar Layanan tarik-turun, pilih Server Cloud Elastis .

  1. Pilih Beli ECS dan pilih Mode Penagihan, Wilayah, dan AZ (Zona Ketersediaan) untuk menerapkan Instans
  2. Pilih Jenis Instans Anda. ( Catatan: Pilih s3.large.2 atau lebih besar.).
  3. Pilih Gambar. Di bawah Gambar Publik, pilih Windows Server 2019 Pusat Data 64bit Bahasa Inggris gambar
    1. Untuk Konfigurasi Jaringan , pilih VPC Anda.
    2. Untuk Subnet , pilih Subnet yang ingin Anda gunakan, pilih Alamat IP yang ditentukan secara manual dan masukkan alamat IP yang ingin Anda gunakan
    3. Pilih Grup Keamanan untuk menggunakan atau Edit dan pilih yang sudah ada.
    4. Tetapkan EIP jika Anda memerlukan instans ECS untuk mengakses internet
    5. Klik Konfigurasikan Pengaturan Lanjut dan berikan nama untuk ECS, gunakan Kata sandi untuk Mode Masuk dan berikan kata sandi aman untuk login Administrator
    6. Klik Konfigurasi Sekarang pada Opsi Lanjutan Tambah sebuah Menandai untuk memberi nama instance Anda dan Klik pada Mengonfirmasi
  4. Lakukan tinjauan akhir Instance dan klik Kirim .

* PENTING: Catat kata sandi administrator awal ini. Ini akan diperlukan untuk masuk ke instance Anda.

Ulangi langkah di atas untuk semua instance.

Hubungkan ke Instance Anda dapat terhubung ke instance pengontrol domain Anda melalui Login Jarak Jauh dari panel ECS.

Masuk sebagai administrator dan masukkan Anda kata sandi administrator .

* PRAKTEK TERBAIK: Setelah masuk, praktik terbaik adalah mengubah kata sandi Anda.

Konfigurasikan Instance Pengontrol Domain Sekarang setelah instance telah dibuat, kami mulai dengan menyiapkan instance Layanan Domain.

Panduan ini bukan tutorial tentang cara menyiapkan instance server Domain Aktif. Kami merekomendasikan membaca artikel tentang cara mengatur dan mengkonfigurasi server Active Directory. Sangat penting untuk dipahami bahwa meskipun instance berjalan di cloud Huawei, ini adalah instalasi reguler Active Directory.

Alamat IP Statis Konfigurasikan Alamat IP Statis untuk Instans Anda

  1. Hubungkan ke instance pengontrol domain Anda.
  2. Klik Awal / Panel kendali .
  3. Klik Jaringan dan pusat Berbagi .
  4. Pilih antarmuka jaringan Anda.
  5. Klik Properti .
  6. Klik Protokol Internet Versi 4 (TCP/IPv4) , kemudian Properti .
  7. Dapatkan saat ini alamat IPv4 , gerbang default dan server DNS untuk antarmuka jaringan dari Amazon .
  8. Dalam Properti Internet Protocol Version 4 (TCP/IPv4) kotak dialog, di bawah Gunakan alamat IP berikut , Masukkan alamat IPv4 .
  9. Dalam Subnetmask kotak, ketik subnet mask yang terkait dengan subnet cloud pribadi virtual Anda.
  10. Dalam Gerbang Default kotak, ketik alamat IP dari gateway default dan kemudian klik oke .
  11. Untuk Server DNS Pilihan , Masukkan Alamat IP Primer Pengontrol Domain Anda (mis. 15.0.1.72).
  12. Klik Oke , lalu pilih Menutup . keluar Jaringan dan pusat Berbagi .
  13. Ulangi langkah di atas pada instance Anda yang lain.

Bergabunglah dengan Dua Instance SQL dan Instance Witness ke Domain * Sebelum mencoba bergabung dengan domain, lakukan penyesuaian jaringan ini. Pada adaptor jaringan Anda, Tambah/Ubah server DNS Pilihan ke alamat Pengontrol Domain baru dan server DNS-nya. Gunakan ipconfig /flushdns untuk menyegarkan daftar pencarian DNS setelah perubahan ini. Lakukan ini sebelum mencoba bergabung dengan Domain.

* Memastikan bahwa Jaringan Inti dan Berbagi File dan Printer opsi diizinkan di Windows Firewall.

  1. Pada setiap contoh, klik Awal , lalu klik kanan Komputer dan pilih Properti .
  2. Di paling kanan, pilih Ubah pengaturan .
  3. Klik Mengubah .
  4. Masukkan yang baru Nama komputer .
  5. Pilih Domain .
  6. Memasuki Nama domain – (mis. docs.huawei.com).
  7. Klik Berlaku .

* Menggunakan Panel kendali untuk memastikan semua instans menggunakan zona waktu yang benar untuk lokasi Anda.

* PRAKTEK TERBAIK: Disarankan agar File Halaman Sistem diatur ke sistem dikelola (tidak otomatis) dan untuk selalu menggunakan drive C:.

Panel Kontrol > Pengaturan sistem lanjutan > Kinerja > Pengaturan > Lanjutan > Memori Virtual. Pilih Ukuran yang dikelola sistem , Volume C: saja, lalu pilih Mengatur untuk menyimpan.

Tetapkan IP Pribadi Sekunder ke Dua Instance SQL Selain IP Primer, Anda perlu menambahkan tiga IP tambahan (IP Sekunder) ke antarmuka jaringan elastis untuk setiap instans SQL.

  1. Dari Daftar Layanan tarik-turun, pilih Server Cloud Elastis .
  2. Klik instance yang ingin Anda tambahkan alamat IP pribadi sekundernya.
  3. Pilih NIC > Kelola Alamat IP Virtual .
  4. Klik Tetapkan alamat IP Virtual dan pilih manual masukkan alamat IP yang berada dalam rentang subnet untuk instance (mis. Untuk 15.0.1.25, masukkan 15.0.1.26). Klik Oke .
  5. Klik pada Lagi dropdown pada baris alamat IP, dan pilih Ikat ke Server , pilih server untuk mengikat alamat IP, dan kartu NIC.
  6. Klik oke untuk menyimpan pekerjaan Anda.
  7. Lakukan hal di atas pada kedua Instance SQL .

* LINK BERMANFAAT: Mengelola Alamat IP Virtual Mengikat Alamat IP Virtual ke EIP atau ECS Buat dan Lampirkan Volume DataKeeper adalah solusi replikasi volume tingkat blok dan mengharuskan setiap node dalam cluster memiliki volume tambahan (selain drive sistem) yang berukuran sama dan huruf drive yang sama. Silakan tinjau Pertimbangan Volume untuk informasi tambahan mengenai persyaratan penyimpanan.

Buat Volume Buat dua volume di setiap zona ketersediaan untuk setiap instance SQL server, total empat volume.

  1. Dari Daftar Layanan tarik-turun, pilih Server Cloud Elastis .
  2. Klik instance yang ingin Anda kelola
  3. Pergi ke Disk tab
  4. Klik Tambahkan Disk untuk menambahkan volume baru pilihan dan ukuran Anda, pastikan Anda memilih volume di AZ yang sama dengan server SQL yang ingin Anda lampirkan
  5. Pilih kotak centang untuk menyetujui SLA dan Kirim
  6. Klik Kembali ke Konsol Server
  7. Menempel disk jika perlu ke instance SQL
  8. Lakukan ini untuk keempat volume.

* LINK BERMANFAAT: Layanan Volume Elastis Konfigurasikan Cluster Sebelum menginstal DataKeeper Cluster Edition, penting untuk mengonfigurasi Windows Server sebagai cluster menggunakan kuorum mayoritas node (jika ada jumlah node ganjil) atau kuorum mayoritas berbagi node dan file (jika ada jumlah genap node). Lihat dokumentasi Microsoft tentang pengelompokan selain topik ini untuk petunjuk langkah demi langkah.Catatan: Microsoft merilis perbaikan terbaru untuk Windows 2008R2 yang memungkinkan penonaktifan suara simpul yang dapat membantu mencapai tingkat ketersediaan yang lebih tinggi dalam konfigurasi klaster multi-situs tertentu.

Tambahkan Pengelompokan Failover Tambahkan fitur Failover Clustering ke kedua instance SQL.

  1. Meluncurkan Manajer Server .
  2. Pilih Fitur di panel kiri dan klik Tambah Fitur dalam Fitur Ini memulai Tambahkan Fitur Wizard .
  3. Pilih Pengelompokan failover .
  4. Pilih Install .

Memvalidasi Konfigurasi

  1. Membuka Manajer Cluster Failover .
  2. Pilih Failover Cluster Manager, pilih Memvalidasi Konfigurasi .
  3. Klik Lanjut , lalu tambahkan dua Contoh SQL .

Catatan: Untuk mencari, pilih Jelajahi , lalu klik Canggih dan Cari sekarang . Ini akan mencantumkan instance yang tersedia.

  1. Klik Lanjut .
  2. Pilih Jalankan Hanya Tes yang Saya Pilih dan klik Lanjut .
  3. Dalam Seleksi Tes layar, batalkan pilihan Penyimpanan dan klik Lanjut .
  4. Pada layar konfirmasi yang dihasilkan, klik Lanjut .
  5. Tinjauan Laporan Ringkasan Validasi lalu klik Menyelesaikan .

Buat Cluster

  1. Di dalam Manajer Cluster Failover , klik Buat Cluster lalu klik Lanjut .
  2. Masukkan dua Anda Contoh SQL .
  3. pada Peringatan Validasi halaman, pilih Tidak lalu klik Lanjut .
  4. pada Titik Akses untuk Mengelola Cluster halaman, masukkan nama unik untuk Cluster WSFC Anda. Kemudian masukkan Alamat IP Failover Clustering untuk setiap node yang terlibat dalam cluster. Ini yang pertama dari ketiganya alamat IP sekunder ditambahkan sebelumnya ke setiap instance.
  5. PENTING! Hapus centang pada kotak “Tambahkan semua penyimpanan yang tersedia ke kluster”. Drive cermin DataKeeper tidak boleh dikelola secara asli oleh cluster. Mereka akan dikelola sebagai Volume DataKeeper.
  6. Klik Lanjut di Konfirmasi
  7. Pada Ringkasan halaman, tinjau peringatan apa pun lalu pilih Menyelesaikan .

Konfigurasikan Kuorum/Saksi

  1. Buat folder pada contoh kuorum/saksi (saksi) Anda.
  2. Bagikan foldernya.
    1. Klik kanan folder dan pilih Bagikan Dengan / Orang Tertentu ….
    2. Dari tarik-turun, pilih Setiap orang dan klik Menambahkan .
    3. Dibawah Tingkat Izin , Pilih Baca tulis .
    4. Klik Membagikan , kemudian Selesai . (Catat jalur berbagi file ini untuk digunakan di bawah.)
  3. Di dalam Manajer Cluster Failover , klik kanan cluster dan pilih Lebih Banyak Tindakan dan Konfigurasikan Pengaturan Kuorum Cluster . Klik Lanjut .
  4. pada Pilih Konfigurasi Kuorum , memilih Node dan Berbagi File Mayoritas dan klik Lanjut .
  5. pada Konfigurasikan File Share Witness layar, masukkan path ke file share yang dibuat sebelumnya dan klik Lanjut .
  6. pada Konfirmasi halaman, klik Lanjut .
  7. pada Ringkasan halaman, klik Menyelesaikan .

Instal dan Konfigurasi DataKeeper Setelah cluster dasar dikonfigurasi tetapi sebelum sumber daya cluster dibuat, instal dan lisensi Edisi Cluster DataKeeper pada semua node cluster. Lihat Panduan Instalasi DataKeeper Cluster Edition untuk petunjuk rinci.

  1. Lari Penyiapan DataKeeper untuk memasang Edisi Cluster DataKeeper pada kedua contoh SQL.
  2. Masukkan kunci lisensi dan reboot saat diminta.
  3. Luncurkan GUI DataKeeper dan sambungkan ke server .

* Catatan : Domain atau akun server yang digunakan harus ditambahkan ke Grup Administrator Sistem Lokal. Akun harus memiliki hak administrator di setiap server tempat DataKeeper diinstal. Mengacu pada Layanan DataKeeper Login ID dan Pemilihan Kata Sandi untuk informasi tambahan.

  1. Klik kanan pada Pekerjaan dan terhubung ke kedua server SQL.
  2. Buat Pekerjaan untuk setiap cermin yang akan Anda buat. Satu untuk sumber daya DTC Anda, dan satu untuk sumber daya SQL Anda..
  3. Saat ditanya apakah Anda ingin mendaftarkan volume secara otomatis sebagai volume cluster, pilih Ya .

* Catatan: Jika menginstal DataKeeper Cluster Edition di Windows “Core” (Windows tanpa GUI), pastikan untuk membaca Menginstal dan Menggunakan DataKeeper di Platform Inti Server Windows 2008R2/2012 untuk petunjuk rinci.

Konfigurasikan MSDTC

  1. Untuk Windows Server 2012 dan 2016, di GUI Pengelola Gugus Failover , Pilih Peran , lalu pilih Konfigurasikan Peran .
  2. Pilih Koordinator Transaksi Terdistribusi (DTC) , dan klik Lanjut .

* Untuk Windows Server 2008, di GUI Pengelola Gugus Failover , Pilih Layanan dan Aplikasi , lalu pilih Konfigurasikan Layanan atau Aplikasi dan klik Lanjut .

  1. pada Titik Akses Klien layar, masukkan nama, lalu masukkan Alamat IP MSDTC untuk setiap node yang terlibat dalam cluster. Ini adalah yang kedua dari tiga alamat IP sekunder ditambahkan sebelumnya ke setiap instance. Klik Lanjut .
  2. Pilih Volume MSDTC dan klik Lanjut .
  3. pada Konfirmasi halaman, klik Lanjut .
  4. sekali Ringkasan tampilan halaman, klik Menyelesaikan .

Instal SQL pada Instance SQL Pertama

  1. Di server pengontrol domain, buat folder dan bagikan..
    1. Misalnya “TEMPSHARE” dengan izin Semua Orang.
  2. Buat sub folder “SQL” dan salin penginstal SQL .iso ke dalam sub folder itu.
  3. Di server SQL, buat drive jaringan dan lampirkan ke folder bersama di pengontrol domain.
    • . Misalnya “penggunaan bersih S: \TEMPSHARE
  4. Di server SQL, drive S: akan muncul. CD ke folder SQL dan temukan penginstal SQL .iso. Klik kanan pada file .iso dan pilih Gunung . Penginstal setup.exe akan muncul dengan penginstal SQL .iso.

F:>Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster

  1. Pada Siapkan Aturan Dukungan , klik oke .
  2. pada Kunci produk dialog, masukkan kunci produk dan klik Lanjut .
  3. pada Persyaratan Lisensi dialog, terima perjanjian lisensi dan klik Lanjut .
  4. pada Pembaruan Produk dialog, klik Lanjut .
  5. pada Siapkan File Dukungan dialog, klik Install .
  6. pada Siapkan Aturan Dukungan dialog, Anda akan menerima peringatan. Klik Lanjut , mengabaikan pesan ini, karena pesan tersebut diharapkan berada di kluster penyimpanan multi-situs atau non-bersama.
  7. Memeriksa Konfigurasi Node Cluster dan klik Lanjut .
  8. Konfigurasikan Anda Jaringan Kluster dengan menambahkan alamat IP sekunder “ketiga” untuk instance SQL Anda dan klik Lanjut . Klik Ya untuk melanjutkan dengan konfigurasi multi-subnet.
  9. Memasuki kata sandi untuk akun layanan dan klik Lanjut .
  10. pada Pelaporan Kesalahan dialog, klik Lanjut .
  11. pada Tambahkan Aturan Node dialog, peringatan operasi yang dilewati dapat diabaikan. Klik Lanjut .
  12. Verifikasi fitur dan klik Install .
  13. Klik Menutup untuk menyelesaikan proses instalasi.

Instal SQL pada Instance SQL Kedua Menginstal instance SQL kedua mirip dengan yang pertama.

  1. Di server SQL, buat drive jaringan dan lampirkan ke folder bersama di pengontrol domain seperti yang dijelaskan di atas untuk server SQL pertama.
  2. Setelah penginstal .iso dipasang, jalankan Pengaturan SQL sekali lagi dari baris perintah untuk melewati Mengesahkan Buka sebuah Memerintah jendela, telusuri ke Direktori instalasi SQL dan ketik perintah berikut:

Setup /SkipRules=Cluster_VerifyForErrors /Action=AddNode /INSTANCENAME=”MSSQLSERVER” ( Catatan : Ini mengasumsikan Anda menginstal instance default pada node pertama)

  1. Pada Siapkan Aturan Dukungan , klik oke .
  2. pada Kunci produk dialog, masukkan kunci produk dan klik Lanjut .
  3. pada Persyaratan Lisensi dialog, terima perjanjian lisensi dan klik Lanjut .
  4. pada Pembaruan Produk dialog, klik Lanjut .
  5. pada Siapkan File Dukungan dialog, klik Install .
  6. pada Siapkan Aturan Dukungan dialog, Anda akan menerima peringatan. Klik Lanjut , mengabaikan pesan ini, karena pesan tersebut diharapkan berada di kluster penyimpanan multi-situs atau non-bersama.
  7. Memeriksa Konfigurasi Node Cluster dan klik Lanjut .
  8. Konfigurasikan Anda Jaringan Kluster dengan menambahkan alamat IP sekunder “ketiga” untuk Instans SQL Anda dan klik Lanjut . Klik Ya untuk melanjutkan dengan konfigurasi multi-subnet.
  9. Memasuki kata sandi untuk akun layanan dan klik Lanjut .
  10. pada Pelaporan Kesalahan dialog, klik Lanjut .
  11. pada Tambahkan Aturan Node dialog, peringatan operasi yang dilewati dapat diabaikan. Klik Lanjut .
  12. Verifikasi fitur dan klik Install .
  13. Klik Menutup untuk menyelesaikan proses instalasi.

Konfigurasi Cluster Umum

Bagian ini menjelaskan konfigurasi cluster yang direplikasi 2-simpul umum .

  1. Konfigurasi awal harus dilakukan dari UI Penjaga Data berjalan di salah satu node cluster. Jika tidak mungkin menjalankan DataKeeper UI pada node cluster, seperti saat menjalankan DataKeeper di server Windows Core saja, instal UI DataKeeper di komputer mana pun yang menjalankan Windows XP atau lebih tinggi dan ikuti instruksi di Inti Saja bagian untuk membuat cermin dan mendaftarkan sumber daya cluster melalui baris perintah.
  2. Setelah UI DataKeeper berjalan, terhubung ke masing-masing node di klaster.
  3. Buat Pekerjaan menggunakan UI DataKeeper. Proses ini membuat cermin dan menambahkan sumber daya Volume DataKeeper ke Penyimpanan yang Tersedia.

! PENTING: Pastikan bahwa Nama Jaringan Virtual untuk koneksi NIC identik pada semua node cluster.

  1. Jika cermin tambahan diperlukan, Anda dapat Tambahkan Cermin ke Pekerjaan .
  2. Dengan Volume Penjaga Data sekarang di Penyimpanan yang Tersedia , Anda dapat membuat sumber daya cluster (SQL, File Server, dll.) dengan cara yang sama seperti jika ada sumber daya disk bersama di cluster. Lihat dokumentasi Microsoft untuk informasi tambahan selain di atas untuk petunjuk konfigurasi cluster langkah-demi-langkah.

Konektivitas ke IP cluster (virtual) Selain IP Primer dan IP sekunder, Anda juga perlu mengonfigurasi alamat IP virtual di Huawei Cloud agar dapat dirutekan ke node aktif.

  1. Dari Daftar Layanan tarik-turun, pilih Server Cloud Elastis .
  2. Klik salah satu contoh SQL yang ingin Anda tambahkan alamat IP virtual cluster (satu untuk MSDTC, satu untuk SQL Failover Cluster)
  3. Pilih NIC > Kelola Alamat IP Virtual .
  4. Klik Tetapkan alamat IP Virtual dan pilih manual masukkan alamat IP yang berada dalam rentang subnet untuk instance (mis. Untuk 15.0.1.25, masukkan 15.0.1.26). Klik Oke .
  5. Klik pada Lagi dropdown pada baris alamat IP, dan pilih Ikat ke Server , pilih server untuk mengikat alamat IP, dan kartu NIC.
  6. Gunakan langkah 4. dan 5 yang sama untuk IP virtual MSDTC dan SQLFC
  7. Klik oke untuk menyimpan pekerjaan Anda.

Pengelolaan Setelah volume DataKeeper terdaftar dengan Windows Server Failover Clustering, semua pengelolaan volume tersebut akan dilakukan melalui antarmuka Windows Server Failover Clustering. Semua fungsi manajemen biasanya tersedia di DataKeeper akan dinonaktifkan pada setiap volume yang berada di bawah kendali cluster. Sebagai gantinya, sumber daya cluster DataKeeper Volume akan mengontrol arah cermin, jadi ketika Volume DataKeeper online pada sebuah node, node tersebut menjadi sumber mirror. Properti sumber daya cluster Volume DataKeeper juga menampilkan informasi pencerminan dasar seperti sumber, target, jenis, dan status cermin.

Penyelesaian masalah Gunakan sumber daya berikut untuk membantu memecahkan masalah:

Sumber daya tambahan: Langkah-demi-Langkah: Mengonfigurasi Cluster Multi-Situs 2-Node di Windows Server 2008 R2 – Bagian 1 — http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93 -Bagian 1/ Langkah-demi-Langkah: Mengonfigurasi Cluster Multi-Situs 2-Node di Windows Server 2008 R2 – Bagian 3 — http://clusteringformeremortals.com/2009/10/07/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93 -bagian-3/

Memulai dengan Baik itu Hebat, Tapi Mempertahankan Uptime Membutuhkan Kewaspadaan

by Leave a Comment

Memulai dengan Baik itu Hebat, Tapi Mempertahankan Uptime Membutuhkan Kewaspadaan

Penulis Isabella Poretsis menyatakan, “Memulai sesuatu bisa jadi mudah, menyelesaikannya adalah rintangan tertinggi.” Sangat bagus untuk mengadakan pertemuan awal.Ini menyegarkan, dan menggairahkan. Manajer dan pemimpin melihat ke lapangan hijau dengan semangat dan optimisme yang tinggi.Tapi, momen kickoff ini, dan bahkan momen bermunculannya Champagne dari penyebaran yang sukses hanyalah permulaan. Mempertahankan uptime membutuhkan kewaspadaan yang berkelanjutan.

Ketersediaan tinggi dan empat sembilan waktu aktif yang sulit dipahami untuk aplikasi dan database penting Anda bukanlah kejadian sesaat, melainkan, upaya terus-menerus untuk mengakhiri rubah kecil yang menghancurkan kebun anggur.Tetap mengikuti perkembangan ancaman, up-to-date pada pembaruan, dan terlatih dan siap adalah pekerjaan yang tim Anda “tidak pernah berhak untuk berlibur.”

Bagi yang ingin tetap waspada dalam menjaga uptime, berikut lima tipsnya:

1. Pantau Lingkungan

Sangat sedikit perangkat lunak perusahaan yang masih mengikuti pola pikir “atur dan lupakan”.Semuanya, sejak hari Anda membuka sumbat sampanye pembukaan hingga sekarang, telah bergerak menuju keadaan menurun.Jika Anda tidak memantau server, beban kerja, lalu lintas jaringan, dan perangkat keras (virtual atau fisik), Anda mungkin kehilangan waktu aktif dan stabilitas.

2. Lakukan Pemeliharaan

Satu hal yang selalu saya perhatikan dalam lebih dari dua puluh tahun pengembangan dan layanan perangkat lunak adalah bahwa semua perangkat lunak dilengkapi dengan pembaruan.Terapkan mereka.Ingatlah untuk menjalankan kebijakan pemeliharaan yang baik, termasuk mengambil dan memverifikasi cadangan. Seorang penulis teknologi menyarankan satu-satunya pembaruan yang Anda sesali adalah pembaruan yang gagal Anda lakukan.

3. Belajar Terus-menerus

Pengenalan pertama saya untuk ketersediaan tinggi datang ketika saya mencabut salah satu ujung Token Ring untuk server di lab kami sebagai pekerja magang, baru dari lab CE-211.Administrator ada di depan saya dalam beberapa menit.Setelah earful, dia memberi saya pendidikan.Idealnya, Anda dan tim Anda ingin belajar tanpa mematikan jaringan Anda, tetapi Anda benar-benar ingin terus belajar.Lihat kursus berbayar tentang teknologi yang ada, rilis baru, infrastruktur yang muncul.Periksa vendor Anda untuk kursus dan item yang terkait dengan proses, lingkungan, penerapan perangkat lunak, dan perusahaan perusahaan Anda.Kursus gratis untuk banyak hal juga ada jika uang menjadi masalah.

4. Lipat gandakan pembelajarannya

Selain belajar terus menerus, buatlah rencana untuk memperbanyak belajar.Sebagai Wakil Presiden Pengalaman Pelanggan di SIOS, kami telah melihat perbedaan luar biasa antara tim yang berbagi pembelajaran dan yang tidak.Tim yang berbagi pembelajaran mereka menghindari kesenjangan dalam pengetahuan yang membahayakan waktu henti.Cara terbaik untuk mengetahui bahwa Anda mempelajari sesuatu adalah dengan mengajarkannya kepada orang lain. Saat Anda belajar, bagikan pembelajaran dengan anggota tim untuk mengurangi risiko waktu henti karena kesalahan, dan dalam hal ini liburan.

5. Akhiri dengan baik. . .sebelum awal berikutnya

Semua proyek, server, dan perangkat lunak memiliki akhir.Akhiri dengan baik.Penonaktifan dengan benar.Mulailah fase berikutnya, penerapan, hubungan perangkat lunak, dll dengan baik dengan menutup ujung yang longgar, mendokumentasikan apa yang berjalan dengan baik, apa yang tidak, dan apa yang harus dilakukan selanjutnya.Perlakukan vendor yang ada dengan baik.Anda mungkin membutuhkannya lagi nanti.Pahami sistem yang ada dan solusi ketersediaan tinggi sebelum melanjutkan penerapan baru.Akhir yang tepat ini membantu Anda memulai lagi dari tempat awal yang lebih baik menuju hasil yang lebih kuat.

Menjaga agar sistem tetap tersedia adalah proses yang berkelanjutan.Atur dan lupakan itu adalah frasa yang bagus, tetapi kenyataannya adalah bahwa waktu aktif membutuhkan kewaspadaan, pemantauan terus-menerus, perawatan yang tepat, dan konstan.

-Cassius Rhee, VP, Pengalaman Pelanggan Direproduksi dengan izin dari SIOS

Memahami dan Menghindari Skenario Otak Terpisah

by Leave a Comment

 

 

Memahami dan Menghindari Skenario Otak Terpisah

Membelah otak. Sebagian besar pembaca blog kami pasti pernah mendengar istilah tersebut, dalam konteks komputasi, namun kami tidak bisa tidak bersimpati dengan mereka yang citra mental pertamanya adalah kekacauan yang akan terjadi jika seseorang memiliki dua otak, keduanya sama-sama memegang kendali pada saat itu. waktu yang sama.

Apa itu Skenario Failover Cluster Split Brain?

Dalam skenario failover cluster split brain, tidak ada node yang dapat berkomunikasi dengan yang lain, dan server siaga dapat mempromosikan dirinya sendiri untuk menjadi server aktif karena diyakini bahwa node aktif telah gagal. Hal ini menyebabkan kedua node menjadi ‘aktif’ karena masing-masing akan melihat yang lain gagal. Akibatnya, integritas dan konsistensi data terganggu karena data pada kedua node akan berubah. Ini disebut sebagai otak terbelah.

Ada dua jenis skenario split-brain yang mungkin terjadi untuk hierarki sumber daya SAP HANA jika langkah-langkah yang tepat tidak diambil untuk menghindarinya.

  • Otak Pemisahan Sumber Daya HANA: Sumber daya HANA Aktif (ISP) pada beberapa node cluster. Situasi ini biasanya disebabkan oleh pemadaman jaringan sementara yang mempengaruhi jalur komunikasi antara node cluster.
  • Replikasi Sistem SAP HANA Split Brain: Sumber daya HANA Aktif (ISP) pada node utama dan Siaga (OSU) pada node cadangan, tetapi database berjalan dan terdaftar sebagai situs replikasi utama pada kedua node. Situasi ini biasanya disebabkan oleh kegagalan untuk menghentikan database pada node utama sebelumnya selama failover, mengaktifkan Autostart untuk database, atau administrator database secara manual menjalankan “hdbnsutil -sr_takeover” di situs replikasi sekunder di luar lingkungan perangkat lunak pengelompokan .

Menghindari Masalah Otak Terbelah

Rekomendasi untuk menghindari atau menyelesaikan setiap jenis skenario otak terbelah dalam Suite Perlindungan SIOS lingkungan pengelompokan diberikan di bawah ini.

Saat dalam skenario split-brain, pesan yang mirip dengan berikut ini dicatat dan disiarkan ke semua konsol terbuka setiap interval quickCheck (default 2 menit) hingga masalah teratasi.

EMERG:hana:quickCheck:HANA-SPS_HDB00:136363:WARNING: Terjadi kegagalan komunikasi sementara antara server hana2-1 dan hana2-2. Intervensi manual diperlukan untuk meminimalkan risiko kehilangan data. 
Untuk mengatasi situasi ini, harap hentikan salah satu hierarki sumber daya berikut: HANA-SPS_HDB00 pada hana2-1 atau HANA-SPS_HDB00 pada hana2-2. 
Server tempat hierarki sumber daya dihentikan layanannya akan menjadi situs Replikasi Sistem SAP HANA sekunder.

Rekomendasi untuk resolusi:

  1. Selidiki database pada setiap node cluster untuk menentukan instance mana yang berisi data paling mutakhir atau relevan. Penentuan ini harus dilakukan oleh administrator database yang memenuhi syarat yang akrab dengan data.
  2. Sumber daya HANA pada simpul yang berisi data yang perlu dipertahankan akan tetap Aktif (ISP) di LifeKeeper, dan hierarki sumber daya HANA pada simpul yang akan didaftarkan ulang sebagai situs replikasi sekunder akan ditiadakan sepenuhnya di Penjaga Kehidupan. Klik kanan pada setiap sumber daya daun dalam hierarki sumber daya HANA pada simpul di mana hierarki harus dihentikan dan klik Sedang dalam perbaikan …
  3. Setelah hierarki sumber daya SAP HANA berhasil dihentikan, LifeKeeper akan mendaftarkan ulang node Siaga sebagai situs replikasi sekunder selama interval quickCheck berikutnya (default 2 menit). Setelah replikasi dilanjutkan, semua data pada node Siaga yang tidak ada pada node Aktif akan hilang. Setelah node Siaga didaftarkan ulang sebagai situs replikasi sekunder, hierarki SAP HANA telah kembali ke status sangat tersedia.

Replikasi Sistem SAP HANA Resolusi Otak Split

Saat dalam skenario split-brain ini, pesan yang mirip dengan yang berikut ini dicatat dan disiarkan ke semua konsol yang terbuka setiap saat. Periksa interval (default 2 menit) hingga masalah teratasi.

EMERG:hana:quickCheck:HANA-SPS_HDB00:136364:PERINGATAN: Basis data SAP HANA HDB00 berjalan dan terdaftar sebagai master utama pada hana2-1 dan hana2-2. Intervensi manual diperlukan untuk meminimalkan risiko kehilangan data. Untuk mengatasi situasi ini, harap hentikan instance database HDB00 pada hana2-2 dengan menjalankan perintah 'su – spsadm -c “sapcontrol -nr 00 -function Stop”' di server tersebut. Setelah dihentikan, itu akan menjadi situs Replikasi Sistem SAP HANA sekunder.

Rekomendasi untuk resolusi:

  1. Selidiki database pada setiap node cluster untuk menentukan apakah ada data penting di node siaga yang tidak ada di node aktif. Jika data penting telah dikomit ke database pada node Standby saat dalam keadaan split-brain, data perlu disalin secara manual ke node Aktif. Penentuan ini harus dilakukan oleh administrator database yang memenuhi syarat yang akrab dengan data.
  2. Setelah data yang hilang telah disalin dari database pada node Siaga ke node Aktif, hentikan database pada node Siaga dengan menjalankan perintah yang diberikan dalam pesan peringatan LifeKeeper:

    su – adm -c “sapcontrol -nr <Inst#> -function Stop” di mana ID Sistem SAP huruf kecil untuk instalasi HANA dan <Inst#> adalah nomor instans untuk instans HDB (misalnya, nomor instans, misalnya, HDB00 adalah 00)

  3. Setelah database berhasil dihentikan, LifeKeeper akan mendaftarkan ulang node Siaga sebagai situs replikasi sekunder selama interval quickCheck berikutnya (default 2 menit). Setelah replikasi dilanjutkan, semua data pada node Siaga yang tidak ada pada node Aktif akan hilang. Setelah node Siaga didaftarkan ulang sebagai situs replikasi sekunder, hierarki SAP HANA telah kembali ke status sangat tersedia.

Menyadari skenario otak terbelah yang umum dan mengambil langkah-langkah ini untuk menguranginya dapat menghemat waktu Anda dan melindungi integritas data.

Direproduksi dengan izin dari SIOS

Arsitektur Ketersediaan Tinggi dan Praktik Terbaik

by Leave a Comment

 

 

Arsitektur Ketersediaan Tinggi dan Praktik Terbaik

13 Fakta yang Sedikit Diketahui tentang Ketersediaan Tinggi

1. Hypervisor HA tidak Sama dengan Aplikasi HA

Kesalahpahaman utama adalah bahwa saya memiliki ketersediaan tinggi karena saya memiliki redundansi di perangkat keras atau hypervisor saya. Namun, redundansi perangkat keras dan hypervisor tidak menjamin ketersediaan tinggi untuk aplikasi. Ini juga bukan jaminan bahwa orkestrasi aplikasi akan dijalankan dengan benar dalam kegagalan.

2. Dalam Ketersediaan Tinggi, Lebih Besar Tidak Sama Lebih Baik

Jika Anda seorang powerlifter, beban yang lebih besar lebih baik dan repetisi yang lebih kecil lebih baik. Atau, jika kita berbicara tentang pelukan. (Kamu ingat pelukan adalah hal yang biasa kita lakukan ketika kita melihat seorang teman dari kota yang berbeda, yang sudah lama tidak kita lihat.) Tapi, lebih besar tidak selalu berarti lebih baik. Batu ginjal yang lebih besar, misalnya, jelas tidak lebih baik. Dalam ketersediaan yang lebih tinggi, membuat solusi yang lebih besar dan lebih kompleks tidak selalu berarti bahwa Anda akan meningkatkan ketersediaan tinggi Anda. Ini mungkin berarti Anda memiliki ketersediaan yang sama atau kurang. Ini juga dapat berarti bahwa Anda memiliki sistem yang lebih besar dan lebih kompleks dengan banyak bagian yang bergerak untuk disortir saat pemadaman listrik.

3. Semuanya gagal… terkadang

Bahasa pemrograman aplikasi sudah ada sejak tahun 1950-an. Dan sementara bahasa, prosesor, IDE, dan kualitas kode telah meningkat, kenyataannya adalah “semua aplikasi gagal di beberapa titik.” Kegagalan karena pengecualian, bug, penghentian yang tidak tertangani, penghentian yang tidak disengaja, kehabisan sumber daya, dan banyak lagi terjadi. Memiliki strategi ketersediaan aplikasi aktif/aktif, atau aktif/pasif tetap diperlukan.

4. Fokus pada ‘mengapa’ sebanyak ‘bagaimana’

Kecenderungan alami kita untuk beralih ke mode penyelesaian tugas adalah aset yang diperlukan, tetapi perlu diatur dan dipandu oleh jawaban atas pertanyaan kita tentang mengapa. Menambahkan solusi ke lingkungan tanpa memahami kebutuhan bisnis, aplikasi, database, dan pemangku kepentingan akan menghasilkan:

  • Kegagalan
  • Lebih dari pengeluaran
  • Di bawah rata-rata
  • Kebingungan dan arsitektur berlebihan
  • Semua yang di atas

Alih-alih hanya berfokus pada penerapan ketersediaan, gunakan sumber daya dan upaya yang diperlukan untuk memahami kebutuhan bisnis dan jawaban atas “mengapa”

5. Masalah yang belum ditambal adalah sumber penyesalan yang umum

Jika Anda melakukannya atau tidak, Anda akan memiliki konsekuensi. Konsekuensi dari semua masalah yang belum terselesaikan adalah penyesalan. Sebagai Wakil Presiden Pengalaman Pelanggan, saya telah melihat secara langsung waktu henti yang disebabkan oleh pelanggan yang gagal mengatasi masalah yang diketahui secara tepat waktu.

6. Masalah yang tidak terdokumentasi juga menyebabkan waktu henti

Bayangkan adegannya. Admin baru sedang mencari server di jaringan. Laporan penggunaan menunjukkan server tidak aktif dan tidak ada klien yang terhubung. Tidak mengenali server dan tidak menemukan “tag”, dokumentasi, atau pengidentifikasi lainnya, admin baru percaya bahwa itu harus dimatikan. Sayangnya, instance yang tidak terdokumentasi dan tidak terkomunikasikan sebenarnya adalah server siaga yang penghapusannya akan menyebabkan waktu henti saat server utama mogok secara tidak terduga. Ini bukan cerita fiksi, ini adalah kisah nyata dari admin baru yang salah mengidentifikasi server sebagai sistem QA yang menganggur dan mematikannya sebelum latihan patching.

7. Rasa puas diri juga merupakan musuh

Kita semua akan senang jika ketersediaan di tempat atau di cloud, atau di mana pun di antaranya adalah sesuatu yang dapat kita “atur dan lupakan.” Tetapi, sedikit, jika ada sesuatu dalam hidup yang benar-benar sesederhana “atur dan lupakan.” Salah satu musuh terbesar ketersediaan Anda di masa depan, adalah kesuksesan Anda dengan ketersediaan tinggi sekarang. Ketika bencana sedikit dan jarang terjadi, dan tim merasa yakin bahwa mereka telah menyadari stabilitas yang berkelanjutan, rasa puas diri bisa masuk. Sukses menggoda kita untuk berpikir tidak ada yang akan berubah, dan rasa puas diri sehubungan dengan ketersediaan tinggi adalah musuh ketersediaan tinggi. Hal-hal di sekitar perusahaan Anda dan di dalam perusahaan Anda sedang berubah. Cloud berubah, kebutuhan bisnis Anda berubah, dan aplikasi serta Sistem Operasi juga berubah.

8. Perubahan itu sulit

Perubahan itu sulit. Tanyakan saja kepada siapa saja yang menyukai makanan manis yang telah mencoba melepaskan potongan kue kedua sebelum tidur. Resistensi serupa terjadi bahkan dalam ketersediaan tinggi. Tim, bahkan yang mengalami bencana, seringkali enggan untuk berubah meskipun perubahan itu baik. Mereka membutuhkan visi, pemahaman tentang mengapa, dan dukungan. Tim lain, yang memiliki solusi, enggan meningkatkan ketersediaan tinggi karena takut menimbulkan ketidakstabilan atau mengekspos diri mereka pada risiko baru.

9. Semua perubahan bukanlah perubahan yang baik

Perubahan itu baik, ketika perubahan itu baik. Saat mempertimbangkan perubahan pada solusi dan arsitektur ketersediaan yang lebih tinggi, sangat penting bahwa perubahan dianalisis terhadap tujuan, persyaratan, dan dalam lingkup peningkatan ketersediaan. Perubahan yang meningkatkan stabilitas, menambahkan perlindungan untuk komponen penting, menghilangkan solusi, mengoptimalkan ketersediaan layanan, dan diuji secara menyeluruh adalah perubahan yang baik.

10. Lebih murah tidak selalu lebih baik

Lebih murah tidak selalu lebih baik. Meskipun solusi yang lebih murah biasanya memiliki label harga yang lebih rendah, solusi tersebut mungkin juga memiliki sejumlah keterbatasan yang membuatnya kurang ideal. Ketika ada label harga yang lebih rendah, waspadalah terhadap fitur yang hilang seperti kurangnya kesadaran aplikasi, orkestrasi terbatas, kompleksitas tersembunyi, pemulihan manual dan kegagalan , dan terbatas pada tidak ada validasi pengguna. Solusi yang lebih murah mungkin juga gagal menyertakan dukungan pelanggan. Pastikan untuk memahami apakah solusi Anda yang lebih murah termasuk dukungan, atau jika dukungan tersebut merupakan tambahan, dan biaya tambahan yang besar.

Hal yang sama berlaku untuk penerapan yang lebih murah dengan komputasi, disk, atau penyimpanan yang lebih sedikit. Meskipun label harga dan biaya bulanan mungkin lebih rendah, solusi Anda mungkin juga berfungsi pada kapasitas yang kurang ideal.

11. Keras tidak sama dengan efektif

Pernah mendengar cerita tentang anak laki-laki yang menangis serigala. Solusi pemantauan aplikasi yang menghasilkan badai peringatan lebih cepat daripada solusi yang diabaikan. Memiliki solusi yang memberikan peringatan itu bagus, tetapi jika solusi itu memicu peringatan kritis karena kesalahan atau berlebihan, itu tidak efektif.

12. Ketersediaan Tinggi adalah budaya dan pola pikir, bukan hanya solusi produk atau perangkat keras

Perangkat lunak, perangkat keras, proses, solusi, dan layanan semuanya merupakan bagian dari ketersediaan tinggi. Namun, tanpa dukungan di seluruh fungsi TI dan unit bisnis, itu akan penuh dengan frustrasi dan terus-menerus menjadi sumber diskusi anggaran alih-alih diskusi tentang nilai, stabilitas bisnis, peningkatan kepuasan pelanggan, dan pengurangan risiko.

13. Sekarang belum terlambat

Harapan bukanlah strategi untuk ketersediaan tinggi, juga tidak berharap bahwa Anda tidak akan mengalami bencana kritis atau kegagalan aplikasi perlu menjadi strategi. Merancang dan merancang arsitektur perusahaan yang sangat tersedia dapat dimungkinkan sekarang, bahkan jika sudah berminggu-minggu atau berbulan-bulan sejak bencana terakhir.

Hubungi SIOS untuk mempelajari lebih lanjut tentang solusi ketersediaan tinggi untuk aplikasi Anda.

– Cassius Rhee, VP, Pengalaman Pelanggan Direproduksi dari SIOS

12 Pertanyaan untuk Mempermudah Migrasi Cloud Anda

by Leave a Comment

12 Pertanyaan untuk Mempermudah Migrasi Cloud Anda

Praktik terbaik migrasi cloud

“Cloud menjadi lebih rumit,” itu adalah pernyataan pertama dalam webinar berdurasi satu jam yang merinci perubahan dan peluang dengan ledakan komputasi awan dan migrasi cloud.Presenter melanjutkan dengan garis besar hal-hal terkait cloud yang dihadapi TI tradisional dalam perjalanan mereka ke AWS , Biru langit , GCP atau penyedia lainnya.

Ada sembilan area yang muncul sebagai komplikasi dalam transisi tradisional ke cloud:

  • definisi
  • Harga
  • Jaringan
  • Keamanan
  • Pengguna, Peran, dan Profil
  • Aplikasi dan Lisensi
  • Layanan dan Dukungan
  • Ketersediaan
  • Cadangan

Sebagai Wakil Presiden Pengalaman Pelanggan untuk SIOS Technology Corp, saya telah melihat bagaimana area berikut dapat memengaruhi transisi ke cloud. Untuk mengurangi komplikasi ini, konsumen beralih ke penyedia layanan terkelola, arsitek solusi cloud, kontraktor dan konsultan, dan sekumpulan layanan terkait, panduan, posting blog, dan artikel terkait. Seringkali dalam proses beralih ke sumber daya luar atau outsourcing, komplikasi ke cloud tidak sepenuhnya dihilangkan.Sebaliknya, perusahaan dan tim yang mereka pekerjakan untuk membantu atau mentransisikannya ke cloud masih menghadapi hambatan, hambatan, hambatan, dan kemunduran.

Paling sering komplikasi dan kelambatan dalam migrasi ke cloud ini berasal dari dua belas pertanyaan yang tidak terjawab:

  1. Apa tujuan kami pindah ke cloud?
  2. Apa arsitektur lokal Anda saat ini?Apakah Anda memiliki dokumen, daftar, diagram alur, atau buku masak?
  3. Apakah semua aplikasi, database, ketersediaan, dan vendor terkait Anda didukung pada platform penyedia cloud target Anda?
  4. Apa risiko dan batasan lokal Anda saat ini?Aplikasi apa yang tidak terlindungi, apa masalah paling umum yang dihadapi di tempat?
  5. Siapa yang bertanggung jawab atas arsitektur dan desain cloud?Bagaimana arsitektur dan desain ini menjelaskan definisi Anda saat ini dan definisi penyedia cloud?
  6. Siapa pemangku kepentingan utama, dan apa pencapaian mereka, penggerak bisnis, dan tenggat waktu untuk proyek bisnis?
  7. Sudahkah Anda membagikan rencana dan pencapaian proyek Anda dengan vendor Anda?
  8. Apa proses, tata kelola, dan persyaratan bisnis saat ini?
  9. Berapa anggaran migrasi dan apakah itu termasuk penambahan staf, pelatihan, dan layanan? Berapa perkiraan Anda untuk biaya pemeliharaan, lisensi, dan operasional yang sedang berlangsung?
  10. Apa keterampilan dan tanggung jawab tim Anda saat ini?
  11. Siapa yang akan bertanggung jawab untuk memperbarui tata kelola, proses, model cloud baru, dan berbagai peran dan tanggung jawab tradisional?
  12. Apa saja aplikasi, layanan, atau fungsi yang akan berpindah dari model IaaS ke SaaS?

Ketahui Tujuan Anda untuk Cloud

Jadi, bagaimana menjawab dua belas pertanyaan ini akan meningkatkan migrasi cloud Anda. Seperti yang Anda lihat dari pertanyaan, memahami tujuan Anda untuk cloud adalah langkah pertama dan terpenting.Hampir diterima secara universal bahwa “penyedia layanan cloud seperti AWS, Azure, atau Google dapat menyediakan server, penyimpanan, dan sumber daya komunikasi yang dibutuhkan aplikasi tertentu,” tetapi bagi banyak pelanggan, ini hanya menghilangkan “dia membutuhkan komputer. perangkat keras dan personel untuk mengelola perangkat keras itu.” Karena fakta ini, seringkali pelanggan berfokus pada konsolidasi atau pengurangan peralatan atau pusat data, tanpa mempertimbangkan bahwa ada peluang dan celah cloud tambahan yang masih perlu mereka pertimbangkan. Misal seperti awan melakukan menghilangkan manajemen perangkat keras, tetapi “ tidak menghilangkan semua kebutuhan yang dimiliki aplikasi dan dependensinya untuk pemantauan dan pemulihan,” jadi jika tujuan Anda adalah mendapatkan semua ketersediaan Anda dari cloud, Anda mungkin tidak mencapai tujuan itu, atau mungkin memerlukan lebih dari sekadar pindah di tempat untuk model IaaS.Mengetahui tujuan Anda akan sangat membantu Anda memetakan perjalanan cloud Anda.

Ketahui Arsitektur Lokal Anda Saat Ini

Kategori pertanyaan penting kedua yang diperlukan untuk migrasi yang tepat ke cloud, (atau platform baru apa pun) adalah memahami arsitektur lokal saat ini. Langkah ini tidak hanya membantu mengidentifikasi aplikasi penting Anda yang membutuhkan ketersediaan, tetapi juga dependensi yang mendasarinya, dan setiap perubahan yang diperlukan untuk aplikasi, database, dan solusi pencadangan tersebut berdasarkan penyimpanan, jaringan, dan perubahan komputasi awan.Menjawab pertanyaan ini juga merupakan langkah kunci dalam menilai kesiapan aplikasi dan solusi Anda untuk cloud dan mengukur risiko Anda saat ini.

Area ketiga yang akan sangat diuntungkan dari mengerjakan pertanyaan-pertanyaan ini terjadi ketika Anda mendiskusikan dan mengukur keterbatasan saat ini.Seringkali, kita melihat fase penemuan ini membuka pintu untuk keterbatasan solusi saat ini yang tidak ada di cloud.Misalnya, baru-baru ini tim layanan kami bekerja dengan pelanggan yang terpengaruh oleh masalah kinerja di cluster database SQL mereka.Seorang pakar SIOS yang membantu migrasi mereka menanyakan tentang solusi dan arsitektur, serta keputusan ukuran VM. Setelah beberapa saat, instans berukuran aplikasi yang lebih besar dikerahkan untuk memperbaiki batasan yang telah diterima pelanggan karena batasan lokal mereka pada komputasi, memori, dan penyimpanan.Demikian pula kami telah bekerja dengan pelanggan yang sensitif terhadap penyimpanan.Mereka akan menjalankan aplikasi dengan disk yang lebih kecil dan kebijakan pengubahan ukuran yang sering, karena keterbatasan kapasitas disk. Sementara biaya penyimpanan harus dipertimbangkan, berjalan dengan margin minimal bisa menjadi batasan di masa lalu.

Memahami Perubahan Bisnis dan Tata Kelola

Kelompok pertanyaan terakhir membantu tim Anda memahami jadwal, dampak bisnis, tenggat waktu, dan perubahan tata kelola yang perlu diperbarui atau diganti karena mungkin tidak lagi berlaku di cloud. Bermigrasi ke cloud dapat menjadi transisi dan perjalanan yang mulus.Namun, gagal menilai di mana Anda berada dalam perjalanan dan kapan Anda harus menyelesaikan perjalanan dapat membuatnya menjadi mimpi buruk. Memahami waktu adalah penting dan dapat sangat dibantu dengan mempertimbangkan pemangku kepentingan, vendor aplikasi, pencapaian bisnis, dan musim bisnis.Secara egois, SIOS Technology Corp. ingin pelanggan memahami pencapaian mereka karena sebagai penyedia Layanan, hal itu meminimalkan kejutan. Namun, kami juga mendorong pelanggan untuk menjawab pertanyaan-pertanyaan ini karena mereka sering menemukan ketidakselarasan antara departemen dan pemangku kepentingan. DBA percaya bahwa cutover akan terjadi pada akhir pekan terakhir bulan ini, tetapi Finance berniat menutup pembukuan selama akhir pekan terakhir di bulan yang sama; atau tim TI percaya bahwa pengalihan dapat terjadi pada hari Senin, tetapi tim aplikasi tidak tersedia hingga hari Rabu, dan mungkin yang terpenting tim hukum belum menyisir daftar NDA baru, perjanjian, lisensi, dan perubahan tata kelola yang diperlukan untuk menariknya bersama.

Saat pelanggan mengerjakan pertanyaan, dengan keamanan dan empati, yang sering muncul adalah potongan-potongan teka-teki, kepemilikan, proses, dan pengambil keputusan yang perlu disatukan kembali menggunakan kotak penyedia cloud dan percakapan jujur tentang anggaran, kepegawaian, pelatihan , dan layanan.Hasil akhirnya mungkin bukan migrasi yang sempurna, tetapi pasti akan menjadi migrasi yang berhasil.

Untuk bantuan dengan strategi migrasi cloud Anda dan penerapan ketersediaan tinggi, hubungi SIOS Technology Corp. – Cassius Rhue, VP, Pengalaman Pelanggan Pelajari lebih lanjut tentang umum tantangan migrasi cloud .

Baca tentang beberapa kesalahpahaman tentang ketersediaan di awan.

Direproduksi dari SIOS