Pelatihan Admin SIOS LifeKeeper untuk Linux tersedia di Udemy

Pelatihan Admin SIOS, yang sebelumnya dapat diakses terutama melalui acara dua bulanan yang telah dijadwalkan sebelumnya, kini tersedia sesuai permintaan melalui Udemy.

Teknologi SIOStelah mengumumkan ketersediaan pelatihan SIOS LifeKeeper untuk Admin LinuxUdemy, pasar keterampilan online dan platform pembelajaran. Perkembangan ini menggarisbawahi dedikasi SIOS untuk memfasilitasi ketersediaan aplikasi penting dengan melengkapi bisnis di seluruh dunia dengan ketersediaan tinggi dan pemulihan bencana yang komprehensif (HA/DR) pelatihan teknis.

Platform Udemy menawarkan kenyamanan dan fleksibilitas yang tak tertandingi, memungkinkan pelajar mengakses pelatihan Admin SIOS kapan saja, di mana saja. Pelatihan SIOS LifeKeeper untuk Admin Linux mencakup konsep dan metodologi utama yang diperlukan untuk memastikan bahwa aplikasi penting Linux, ERP, dan database selalu tersedia, bahkan saat menghadapi kegagalan perangkat keras atau perangkat lunak.

“Kemitraan dengan Udemy ini menandai tonggak penting dalam misi kami untuk menjadikan keahlian SIOS HA/DR dapat diakses oleh semua orang,” kata Margaret Hoagland, VP Penjualan & Pemasaran Global, SIOS Technology Corp. “Dengan memanfaatkan platform Udemy, kami dapat menjangkau lebih banyak orang audiens profesional TI, memberdayakan mereka dengan pengetahuan dan keterampilan yang diperlukan untuk memastikan ketersediaan tinggi dan pemulihan bencana di organisasi mereka.”

Calon pelajar dapat mengakses kursus pelatihan SIOS LifeKeeper untuk Admin Linux dengan terlebih dahulu membuat akun gratis di Udemy, (www.udemy.com) dan mendaftar dengan email bisnis mereka. Setelah terdaftar, mereka menyerahkan formulir diSitus Pelatihan SIOS, menggunakan email bisnis yang sama dengan yang mereka gunakan untuk mendaftar di Udemy, untuk menerima undangan kursus.

Direproduksi dengan izin dariSIOS

Teknologi SIOS Bergabung dengan Program Mitra Nutanix Elevate

SIOS Teknologi Corp. mengumumkan keanggotaannya diProgram Mitra Nutanix Elevate, menandai tonggak sejarah dalam menyediakan solusi clustering HA yang mudah digunakan untuk aplikasi penting dalam lingkungan Nutanix AHV.

Penyelesaian penunjukan validasi Nutanix Ready yang diberikan kepada SIOS menunjukkan SIOSPenjaga KehidupanDanPenjaga Datainteroperabilitas dengan infrastruktur Nutanix. Sebagai bagian dari validasi ini, kedua mitra berkolaborasi untuk membantu pelanggan bersama mendapatkan manfaat dari inovasi berkelanjutan.

Rekam jejak SIOS mencakup implementasi yang sukses bagi pelanggan yang memungkinkan HA dan DR dengan lebih dari 80.000 lisensi terpasang secara global, melindungi aplikasi untuk perusahaan di berbagai industri.

Produk LifeKeeper dan DataKeeper telah menyelesaikan pengujian verifikasi, yang dapat menambah keyakinan pelanggan mengenai kompatibilitas solusi. LifeKeeper untuk Linux memungkinkan Nutanix menawarkan kepada pelanggan HA yang sederhana dan andal untuk aplikasi bisnis penting yang didukung oleh keahlian HA yang mendalam. Dengan produk SIOS, pelanggan Nutanix dengan lingkungan yang secara intrinsik kompleks, seperti SAP, HANA, SQL Server, dan lainnya yang berjalan di SUSE Linux, Red Hat Linux, Oracle Linux, Rocky Linux, dan Windows Server dapat menghemat waktu dan menghilangkan downtime yang mahal dengan menerapkan, memelihara , dan mengelola lingkungan HA yang stabil dan andal.

Margaret Hoagland, VP pemasaran global, SIOS, mengatakan: “Bergabung dengan Nutanix Elevate Partner Program merupakan bukti komitmen kami untuk memberikan solusi HA yang kuat kepada pelanggan, memperluas jangkauan kami dan memberikan keandalan dan kesederhanaan yang dibutuhkan pengguna Nutanix untuk memastikan tidak ada gangguan. operasi untuk aplikasi penting mereka.”

Produk-produk SIOS yang mendapatkan penghargaan “Nutanix Ready Validated”, meliputi:

• Penjaga Kehidupan untuk Linux 9.8.0
• Penjaga Kehidupan untuk Windows 8.10.0
• Penjaga Data untuk Windows 8.10.0

LifeKeeper untuk Linux menyediakan HA untuk spektrum terluas distribusi, versi, dan platform OS Linux; lokal, virtual, dan cloud. Portofolio produk HA/DR SIOS mencakup replikasi tingkat blok berbasis host yang efisien bandwidth, kit pemulihan aplikasi (ARK) untuk memungkinkan kesadaran aplikasi untuk SAP, HANA, dan database dan aplikasi populer lainnya serta ARK umum yang dapat disesuaikan. LifeKeeper untuk Linux menyediakan pemantauan otomatis, deteksi masalah, dan pemulihan cerdas untuk aplikasi, database, dan penyimpanan untuk memastikan sistem dan aplikasi penting tetap tersedia.

Lebih lanjut tentang solusi SIOS-Nutanix

Langkah-demi-Langkah – SQL Server 2019 Failover Cluster Instance (FCI) di OCI

Perkenalan

Jika Anda menerapkan aplikasi bisnis penting di Oracle Cloud Infrastructure (OCI), penting untuk memahami dan memanfaatkan ketersediaan SLA (Service Level Agreement) yang disediakan oleh OCI untuk uptime dan keandalan yang optimal. SLA OCI bervariasi berdasarkan strategi penerapan yang Anda pilih:

Penerapan di seluruh Domain Ketersediaan:OCI menawarkan SLA ketersediaan 99,99% saat Anda menyebarkan dua atau lebih Mesin Virtual (VM) di Domain Ketersediaan berbeda dalam wilayah OCI yang sama.

Penerapan di seluruh Domain Kesalahan:Jika Anda menyebarkan VM di seluruh Fault Domains, OCI menyediakan SLA ketersediaan 99,95%. Penting untuk dicatat bahwa tidak setiap wilayah OCI memiliki beberapa Domain Ketersediaan, jadi di beberapa wilayah, penerapan di seluruh Domain Kesalahan akan menjadi satu-satunya pilihan Anda.

Penerapan VM Tunggal:Untuk penerapan yang melibatkan satu VM, SLA mencapai 99,9%.

Kerangka kerja ini berarti bahwa OCI menjamin tingkat konektivitas eksternal tertentu berdasarkan cara Anda menyebarkan VM Anda:

Penting untuk diperhatikan bahwa SLA mencakup ketersediaan VM itu sendiri, bukan aplikasi atau layanan yang berjalan di dalamnya. Untuk memastikan ketersediaan aplikasi, tindakan tambahan seperti pemantauan aplikasi, perencanaan pemulihan, replikasi data, dan replikasi transaksional (untuk database seperti SQL Server) diperlukan. Strategi mungkin mencakup penyeimbangan beban, pengelompokan, atau replikasi data untuk mengelola ketersediaan aplikasi secara efektif.

Untuk memenuhi kriteria SLA ketersediaan 99,99% di OCI, penting untuk menyebarkan VM Anda di beberapa Domain Ketersediaan. Posting ini akan memandu Anda dalam merancang infrastruktur OCI untuk memfasilitasi Instans Kluster Failover SQL Server yang mencakup Domain Ketersediaan, memastikan waktu aktif dan keandalan maksimum untuk aplikasi bisnis penting Anda.

Buat VCN dan Subnet

Dalam panduan ini, saya berasumsi Anda sudah familiar dengan Oracle Cloud Infrastructure (OCI) dan pemahaman dasar tentang konsep jaringan. Saya akan mengilustrasikan tugas konfigurasi umum dengan deskripsi, dan jika perlu, memberikan panduan tambahan untuk mengatasi beberapa tantangan umum yang dihadapi dalam jaringan OCI.

Memulai dengan rencana jaringan yang dipikirkan dengan matang sangatlah penting. Dokumen ini tidak akan membahas seluk-beluk perencanaan jaringan cloud, jadi contoh berikut sebaiknya dianggap hanya salah satu dari banyak kemungkinan. Konfigurasi jaringan Anda mungkin sangat bervariasi. Namun, pertimbangan penting adalah merencanakan penggunaan setidaknya tiga Domain Ketersediaan, mengalokasikan satu untuk setiap node cluster dan satu lagi untuk saksi berbagi file. Hal penting yang diperlukan untuk clustering adalah setiap Availability Domain HARUS berada di subnet yang berbeda.

Meskipun kami tidak membahas konfigurasi yang mencakup Domain Kesalahan dan bukan Domain Ketersediaan, hal yang sama berlaku untuk klaster yang mencakup Domain Kesalahan – semua node harus berada di subnet yang berbeda.

Dalam skenario kami, kami akan menyiapkan tiga subnet di tiga Domain Ketersediaan berbeda dalam satu Jaringan Cloud Virtual (VCN) di OCI.

VCN: 10.0.0.0/16

• IKLAN1: 10.0.0.0/18
• IKLAN2: 10.0.64.0/18
• IKLAN3: 10.0.128.0/18

Antarmuka pengguna OCI dapat berubah, tetapi pada saat penulisan ini, proses untuk membuat VCN baru dan tiga subnet dapat dilakukan dengan mudah di konsol OCI. Detailnya dapat ditemukan di dokumentasi OCI atau melalui antarmuka penggunanya, yang memandu Anda melalui langkah-langkah yang diperlukan untuk pembuatan VCN dan subnet.

Buat VCNnya

Buat tiga subnet di VCN

Buat gerbang Internet

Gerbang internet adalah cara instans kita mendapatkan akses ke internet. Di jaringan Anda, Anda mungkin tidak ingin instance Anda dapat mengakses internet, namun untuk contoh ini kami akan mengaktifkannya dan menambahkannya ke tabel rute default kami.

Edit Daftar Keamanan Default

Edit tabel rute

Edit tabel rute sehingga semua lalu lintas yang ditujukan di luar VCN dirutekan melalui gateway internet.

Buat Grup Keamanan Jaringan

Edit daftar keamanan

Pengaturan ini memungkinkan akses tanpa batas di seluruh domain ketersediaan, dan memungkinkan akses RDP dari mana saja. Anda dapat mempertimbangkan untuk membatasi alamat IP mana yang dapat melakukan RDP pada instans Anda atau bahkan menyiapkan “jump VM” yang digunakan secara eksklusif untuk akses RDP dari jaringan publik.

Edit opsi DHCP

Agar direktori aktif berfungsi dengan benar, Anda harus mengatur DC1 sebagai server DNS utama dalam opsi DHCP seperti yang ditunjukkan di bawah ini. Dalam hal ini, kami menyetelnya ke 10.0.0.100, yang merupakan IP statis pengontrol domain yang kami konfigurasi. Anda juga harus menambahkan domain Anda ke domain pencarian khusus. Dalam hal ini, kita akan menggunakan domain bernama datakeeper.local, yang akan kita buat nanti saat kita mengonfigurasi pengontrol domain kita.

Sediakan VM

Setelah VCN dikonfigurasi, sekarang saatnya untuk mulai menyediakan VM. Dalam contoh ini kita akan menggunakan Windows Server 2022 dan SQL Server 2019. Namun, langkah-langkah yang dijelaskan dalam artikel ini hampir sama di semua versi Windows Server dan SQL Server, jadi Anda tidak akan mengalami masalah apa pun versinya. Windows atau SQL Server yang ingin Anda gunakan.

Sebelum memulai, sekali lagi penting untuk memulai dengan sebuah rencana. Dalam hal ini Anda ingin merencanakan nama server Anda, alamat IP dan penempatan zona ketersediaannya. Seperti disebutkan sebelumnya, setiap node cluster dan saksi berbagi file masing-masing harus berada di zona ketersediaan yang berbeda.

Dalam contoh konfigurasi, kami akan menerapkan direktori aktif dalam sebuah instance (DC1) yang juga akan bertindak sebagai saksi berbagi file.

AD1 – DC1 (10.0.0.100)

AD2 – SQL1 – (10.0.64.100, 10.0.64.101, 10.0.64.102)

AD3 – SQL2 – (10.0.128.100, 10.0.128.101, 10.0.128.102)

Anda mungkin telah memperhatikan bahwa setiap node cluster (SQL1, SQL2) memiliki tiga alamat IP. Alamat pertama adalah alamat IP pribadi dari instance tersebut. Dua alamat IP lainnya akan ditambahkan sebagai alamat sekunder pada setiap instans. Alamat IP ini memperhitungkan alamat IP cluster inti dan alamat IP virtual yang terkait dengan sumber daya nama jaringan SQL Server FCI.

Saat kami menyediakan node cluster, kami akan menggunakan image dasar Windows Server 2022 tanpa menyertakan perangkat lunak SQL Server. Sebagai gantinya, kami akan mengunduh media instalasi SQL Server dan menggunakan lisensi SQL Server yang abadi, bukan lisensi “bayar sesuai pemakaian” yang tersedia di Marketplace.

Bagian berikut menggambarkan proses penyediaan tiga VM yang digunakan dalam contoh ini.

Ketentuan DC1 di FD1

Saat memilih jenis instans, Anda harus mengukurnya dengan benar untuk beban kerja. Hal ini mirip dengan apa yang akan Anda lakukan jika Anda mengukur server fisik untuk digunakan di lokasi, namun perbedaannya adalah Anda dapat menyesuaikan ukurannya dengan mudah jika Anda melakukan provisi berlebihan, atau kurang menyediakan pada kali pertama, atau jika beban kerja Anda bertambah atau berkurang seiring berjalannya waktu.

Saat menentukan detail instans, pastikan Anda memilih VCN dan subnet yang tepat untuk penempatan yang tepat. Pada layar pertama ini Anda juga menentukan IP statis yang ingin Anda kaitkan dengan instance ini.

Penyediaan SQL1 di FD2

Seperti yang dibahas sebelumnya, contoh ini menggunakan instalasi dasar Windows Server 2022. SQL Server 2019 akan diunduh nanti dan digunakan untuk instalasi SQL Server FCI.

Penyediaan SQL2 di FD3

Menambahkan Volume Tambahan

Setiap server di cluster memerlukan setidaknya satu volume tambahan. Volume ini sangat penting untuk kebutuhan penyimpanan SQL Server FCI dan direplikasi oleh SIOS DataKeeper.

Beberapa Volume

Anda dapat menambahkan beberapa volume untuk memisahkan data, log, dan cadangan.

Jenis Penyimpanan: Berbagai jenis penyimpanan tersedia untuk memenuhi kebutuhan yang berbeda.

Metode Lampiran

Ada beberapa cara untuk melampirkan penyimpanan ke server Anda.

Contoh Konfigurasi

Di bawah ini, kami telah menyertakan tangkapan layar yang menunjukkan salah satu dari banyak kemungkinan konfigurasi penyimpanan. Ini berfungsi sebagai contoh praktis untuk membantu memahami proses pengaturan. Proses ini harus diselesaikan pada SQL1 dan SQL2.

Buat Volume Blok

Pertama, buat volume blok di domain Ketersediaan yang tepat untuk SQL1 dan SQL2.

Lampirkan Volume

Sekarang volume telah dibuat, Anda harus melampirkannya ke instance.

Poin-Poin Penting yang Perlu Diingat

Pengaturannya fleksibel. Anda dapat mengonfigurasi satu atau lebih volume berdasarkan kebutuhan spesifik Anda.

Pertimbangkan berbagai jenis penyimpanan dan metode lampiran yang tersedia untuk konfigurasi Anda.

Tambahkan Alamat IP Sekunder

Agar Clustering Failover Windows Server berfungsi dengan baik di OCI, Anda harus menambahkan alamat IP cluster sebagai alamat sekunder pada antarmuka jaringan virtual (VNIC) yang melekat pada SQL1 dan SQL1. Seingat Anda, kami membahas penggunaan alamat IP berikut pada setiap node cluster kami.

	SQL1	SQL2
alamat utama	10.0.64.100	10.0.128.100
Cluster IP 1 (sumber daya cluster inti)	10.0.64.101	10.0.128.101
IP Kluster 2(IP Kluster SQL Server)	10.0.64.102	10.0.128.102

Pada SQL1 dan SQL2, edit VNIC terlampir untuk menambahkan alamat sekunder.

	SQL1	SQL2
Primary Address	10.0.64.100	10.0.128.100
Cluster IP 1 (core cluster resource)	10.0.64.101	10.0.128.101
Cluster IP 2 (SQL Server Cluster IP)	10.0.64.102	10.0.128.102

 

Buat Domainnya

Untuk ketahanan, Anda harus menyediakan beberapa pengontrol AD ​​di zona ketersediaan yang berbeda, namun untuk tujuan panduan ini, kami hanya akan menyediakan satu pengontrol AD. Ikuti tangkapan layar di bawah untuk mengonfigurasi AD di DC1.

Masuk menggunakan kredensial yang tercantum di bagian Detail Instans. Anda akan diminta untuk mengatur ulang kata sandi Anda.

Aktifkan Layanan Domain Direktori Aktif

Promosikan Server ke Pengontrol Domain

Sebelum Anda memulai proses ini, aktifkan akun Administrator lokal di server dan atur kata sandi. Jika tidak, Anda akan menerima pesan ini saat mencoba mempromosikan pengontrol domain.

Setelah Anda mengaktifkan akun Administrator dan mengatur kata sandi, lanjutkan dengan Konfigurasi Pasca-Penerapan

Sebelum mengaktifkan Layanan Domain Direktori Aktif, Anda harus mengaktifkan akun Administrator lokal dan masuk dengan akun tersebut.

Menggunakan program RDP favorit Anda, sambungkan ke DC1 menggunakan alamat IP publik yang terkait dengan instans. Tambahkan peran Layanan Domain Direktori Aktif.

Setelah instalasi selesai, promosikan server ini ke pengontrol domain.

Untuk tujuan kami, kami akan membuat domain baru.

Nyalakan ulang DC1 dan lanjutkan ke bagian berikutnya.

Gabungkan SQL1 dan SQL2 ke Domain

Siapkan Penyimpanan

Setelah SQL1 dan SQL2 ditambahkan ke domain, sambungkan ke instans dengan akun Admin Domain yang Anda buat untuk menyelesaikan langkah konfigurasi selanjutnya. Hal pertama yang perlu Anda lakukan adalah melampirkan dan memformat volume EBS yang kami tambahkan ke SQL1 dan SQL2 seperti yang ditunjukkan di bawah ini.

Konfigurasikan Fitur Pengelompokan Failover

Aktifkan fitur Failover Clustering pada SQL1 dan SQL2.

Jalankan perintah PowerShell ini pada SQL1 dan SQL2

Instal-WindowsFeature -Nama Failover-Clustering -SertakanAlat Manajemen

Validasi Cluster Anda

Jalankan perintah PowerShell ini dari SQL1 atau SQL2

Uji-Kluster -Node sql1,sql2

Tergantung pada versi Windows Server yang Anda gunakan, Anda akan melihat beberapa peringatan tentang Jaringan dan kemungkinan penyimpanan. Peringatan jaringan kemungkinan akan memberi tahu Anda bahwa setiap node cluster dapat diakses melalui satu antarmuka. Versi Windows sebelumnya akan memperingatkan Anda tentang kurangnya penyimpanan bersama.

Anda dapat mengabaikan kedua kesalahan tersebut seperti yang diharapkan dalam klaster yang dihosting di OCI. Selama Anda tidak menerima Kesalahan, Anda dapat melanjutkan ke bagian berikutnya. Jika Anda menerima kesalahan apa pun, perbaiki, lalu jalankan validasi lagi dan lanjutkan ke bagian berikutnya.

Buat Klaster

Selanjutnya, Anda akan membuat cluster. Pada contoh di bawah, Anda akan melihat saya menggunakan dua alamat IP yang kami rencanakan untuk digunakan, 10.0.64.101 dan 10.0.128.101. Anda dapat menjalankan Powershell ini dari salah satu node cluster.

Cluster Baru -Nama cluster1 -Node sql1,sql2 -StaticAddress 10.0.64.101, 10.0.128.101

Tolong dicatat:JANGAN mencoba membuat cluster melalui WSFC GUI. Anda akan menemukan bahwa karena instance menggunakan DHCP, GUI tidak akan memberi Anda opsi untuk menetapkan alamat IP untuk cluster dan sebaliknya akan membagikan alamat IP duplikat.

Tambahkan Saksi Berbagi File

Untuk mempertahankan kuorum cluster, Anda perlu menambahkan saksi. Di OCI, tipe saksi yang ingin Anda gunakan adalah File Share Witness. Saksi berbagi file harus berada di server yang berada di Domain Kesalahan yang berbeda dari dua node cluster.

Pada contoh di bawah, saksi berbagi file akan dibuat di DC1, yang berada di FD1.

Di DC1, buat berbagi file dan tetapkan izin baca-tulis objek nama klaster (CNO) pada folder tersebut. Tambahkan izin untuk CNO pada tab Bagikan dan Keamanan pada folder yang Anda buat, Pada contoh di bawah ini saya membuat folder bernama “Witness”.

Setelah folder dibuat dan izin yang sesuai telah ditetapkan ke CNO, jalankan perintah PowerShell berikut pada SQL1 atau SQL2.

Set-ClusterQuorum -Cluster cluster1 -FileShareWitness \\dc1\Witness

Klaster Anda sekarang akan terlihat seperti berikut ketika Anda meluncurkan Failover Cluster Manager di SQL1 atau SQL2.

Membuat SQL Server FCI

Instal Edisi Cluster DataKeeper

Sebelum melanjutkan ke langkah selanjutnya, Anda perlu menginstal DataKeeper Cluster Edition di SQL1 dan SQL2. Unduh pengaturan yang dapat dieksekusi dan jalankan pengaturan DataKeeper di kedua node. Mengacu kepadadokumentasi SIOSuntuk panduan khusus tentang instalasi.

Buat Sumber Daya Volume DataKeeper

Luncurkan UI DataKeeper di salah satu node cluster dan buat Sumber Daya Volume DataKeeper Anda seperti yang ditunjukkan di bawah ini.

Hubungkan ke kedua server, pertama SQL1 dan kemudian SQL2

Jika Anda telah terhubung ke kedua server dan penyimpanan dikonfigurasi dengan benar, Laporan Ikhtisar Server akan terlihat seperti ini.

Klik Buat Pekerjaan untuk memulai Wizard Pembuatan Pekerjaan

DataKeeper mendukung replikasi sinkron dan asinkron. Untuk replikasi antar zona ketersediaan di wilayah yang sama, pilih sinkron. Jika Anda ingin mereplikasi antar wilayah atau bahkan antar penyedia cloud, pilih asynchronous

Klik “Ya” di sini untuk mendaftarkan sumber daya Volume DataKeeper di Penyimpanan yang Tersedia di

DataKeeper Volume D sekarang muncul di Failover Cluster Manager di Penyimpanan yang Tersedia.

Instal Node Pertama SQL Server FCI di SQL1

Sekarang cluster inti telah dibuat dan sumber daya volume DataKeeper berada di Penyimpanan yang Tersedia, sekarang saatnya menginstal SQL Server pada node cluster pertama. Seperti disebutkan sebelumnya, contoh di sini mengilustrasikan konfigurasi kluster menggunakan SQL 2019 dan Windows 2022, namun semua langkah yang dijelaskan dalam contoh ini hampir sama, terlepas dari versi Windows Server atau SQL Server mana yang Anda coba terapkan.

Ikuti contoh di bawah ini untuk menginstal SQL Server di SQL1

Nama yang Anda tentukan di bawah ini adalah titik akses klien. Ini adalah nama yang akan digunakan server aplikasi Anda ketika mereka ingin menyambung ke SQL Server FCI.

Di layar ini Anda akan menambahkan alamat IP sekunder SQL1 yang kami identifikasi sebelumnya di bagian perencanaanBagian 1dari seri ini.

Dalam contoh ini kami meninggalkan tempdb di drive D. Namun, untuk kinerja terbaik, Anda disarankan untuk menemukan tempdb pada volume yang tidak direplikasi.

Instal simpul kedua dari SQL Server FCI di SQL2

Sekarang saatnya menginstal SQL Server di SQL2.

Setelah Anda menginstal SQL Server di kedua node cluster, Failover Cluster Manager akan terlihat seperti ini.

Instal Studio Manajemen SQL Server

Pada SQL Server Versi 2016 dan yang lebih baru, Anda harus mengunduh dan menginstal SSMS sebagai opsi terpisah seperti yang ditunjukkan di bawah ini. Catatan: Di versi SQL Server yang lebih lama, SQL Server Management Studio (SSMS) adalah opsi yang dapat Anda pilih untuk diinstal selama instalasi SQL.

Setelah SSMS terinstal, sambungkan ke cluster melalui titik akses klien. FCI SQL Server Anda akan terlihat seperti ini.

Pertimbangan Multi-Subnet

Salah satu pertimbangan terbesar untuk menjalankan SQL Server FCI di OCI adalah kenyataan bahwa node cluster berada di subnet yang berbeda. Microsoft mulai memperhitungkan fakta bahwa node cluster mungkin berada di subnet yang berbeda dengan menambahkan fungsionalitas “ATAU” di Windows Server 2008 R2 seperti yang dijelaskan dalam Microsoftdokumentasi.

Diambil dariPengelompokan Multi-Subnet SQL Server (SQL Server)

Hal penting yang dijelaskan dalam dokumentasi adalah konsep RegisterAllProvidersIP pada sumber daya nama jaringan, yang diaktifkan secara default saat Anda membuat SQL Server FCI. Seperti dijelaskan, bila ini diaktifkan, dua catatan A akan didaftarkan di DNS dengan sumber daya nama jaringan, satu untuk setiap alamat IP.

Dengan menggunakan fungsionalitas “ATAU”, hanya alamat IP yang terkait dengan subnet aktif yang akan online dan alamat IP lainnya akan ditampilkan sebagai offline. Jika klien Anda mendukung penambahan multisubnetfailover=true ke string koneksi, maka kedua alamat IP akan dicoba secara bersamaan dan klien akan secara otomatis terhubung ke node aktif. Itu adalah metode pengalihan klien yang paling mudah dan default dalam cluster multi-subnet.

Dokumentasi selanjutnya mengatakan bahwa jika klien Anda TIDAK mendukung fungsionalitas multisubnetfailover=true, Anda harus “mencoba menyesuaikan batas waktu koneksi dalam string koneksi klien sebanyak 21 detik untuk setiap alamat IP tambahan. Hal ini memastikan bahwa upaya koneksi ulang klien tidak habis waktu sebelum dapat menelusuri semua alamat IP di FCI multi-subnet Anda.”

Menonaktifkan RegisterAllProvidersIP adalah opsi lain yang bisa digunakan. Dengan menonaktifkan RegisterAllProvidersIP Anda hanya akan memiliki satu catatan A di DNS. Catatan DNS A akan diperbarui setiap kali klaster melakukan failover dengan alamat IP klaster aktif yang terkait dengan sumber daya nama.

Kelemahan dari konfigurasi skenario ini adalah klien Anda akan menyimpan alamat IP lama dalam cache hingga time to live (TTL) berakhir. Untuk meminimalkan penundaan koneksi ulang, disarankan agar Anda mengubah TTL pada nama sumber daya. Proses ini dijelaskanDi Sinidan contohnya ditunjukkan di bawah ini yang menyetel TTL menjadi 5 menit.

Dapatkan-ClusterResource -Nama sqlcluster | Set-ClusterParameter -Nama HostRecordTTL -Nilai 300

Ingatlah bahwa mungkin diperlukan beberapa waktu agar perubahan pada server DNS terintegrasi AD Anda diterapkan ke seluruh forest Anda.

Ringkasan

Panduan teknis ini memberikan gambaran umum komprehensif tentang menyiapkan Instans Kluster Failover (FCI) SQL Server 2019 di Oracle Cloud Infrastructure (OCI). Hal ini dimulai dengan menyoroti pentingnya memahami SLA ketersediaan OCI, yang berbeda berdasarkan strategi penerapan: 99,99% untuk penerapan di seluruh Domain Ketersediaan, 99,95% di seluruh Domain Kesalahan, dan 99,9% untuk penerapan VM tunggal. Panduan ini menekankan bahwa SLA mencakup ketersediaan VM, bukan aplikasi atau layanan yang berjalan di dalamnya, sehingga memerlukan tindakan tambahan untuk ketersediaan aplikasi.

Panduan ini merinci langkah awal pembuatan Virtual Cloud Network (VCN) dan subnet di OCI, menekankan perlunya rencana jaringan yang mengakomodasi setidaknya tiga Domain Ketersediaan untuk tujuan pengelompokan. Setiap Domain Ketersediaan harus berada dalam subnet yang berbeda, persyaratan ini juga berlaku untuk klaster yang mencakup Domain Kesalahan. Ini memberikan konfigurasi khusus untuk menyiapkan tiga subnet di Domain Ketersediaan berbeda dalam satu VCN.

Lebih lanjut, panduan ini menjelaskan proses pembuatan gateway internet dan mengedit daftar keamanan default dan tabel rute untuk memfasilitasi akses dan keamanan di seluruh Domain Ketersediaan. Panduan ini juga mencakup konfigurasi opsi DHCP untuk kompatibilitas Direktori Aktif dan menguraikan langkah-langkah untuk menyediakan VM dengan Windows Server 2022 dan SQL Server 2019, menekankan pentingnya merencanakan nama server, alamat IP, dan penempatan zona ketersediaan.

Panduan ini kemudian mempelajari penambahan volume tambahan untuk kebutuhan penyimpanan SQL Server FCI, merinci proses pembuatan dan melampirkan volume blok ke instans. Ini juga menginstruksikan tentang mengonfigurasi alamat IP sekunder untuk Windows Server Failover Clustering di OCI.

Selanjutnya, panduan ini membahas pengaturan pengontrol domain, termasuk mengaktifkan Layanan Domain Direktori Aktif dan mempromosikan server ke pengontrol domain. Panduan ini memandu persiapan penyimpanan dan pengaktifan fitur Failover Clustering di SQL1 dan SQL2, serta proses validasi dan pembuatan cluster.

Panduan ini selanjutnya membahas penambahan File Share Witness untuk mempertahankan kuorum cluster dan menginstal DataKeeper Cluster Edition untuk replikasi volume. Ini memberikan pendekatan langkah demi langkah untuk menginstal SQL Server pada node cluster dan SQL Server Management Studio, bersama dengan pertimbangan untuk penerapan multi-subnet.

Singkatnya, panduan ini menawarkan cetak biru terperinci untuk menerapkan dan mengonfigurasi SQL Server 2019 FCI di OCI, yang mencakup aspek mulai dari penyiapan jaringan dan penyediaan VM hingga pengelompokan, konfigurasi penyimpanan, dan penyiapan kontrol domain, memastikan waktu aktif dan keandalan maksimum untuk aplikasi penting bisnis .

Unduh panduan Langkah demi Langkah di sini.

Direproduksi dengan izin dariSIOS

Empat tips untuk memilih solusi ketersediaan tinggi yang tepat

Ketersediaan Tinggi dan Lebron adalah Debat Terbesar Sepanjang Masa (KAMBING).

Saya kalah di Spades. Saya kalah di Kahoot. Saya kalah dalam pertandingan bola basket, dan semuanya dari pesaing ramah yang sama, Brandon. Jadi, untuk mengalihkan perhatiannya, saya kembali ke debat saya- “Lebron adalah yang terhebat sepanjang masa!” Menit-menit yang penuh ketegangan berikutnya diisi dengan kata-kata kasar yang diwarnai dengan nama-nama beberapa pemain bola basket hebat: Michael Jordan, Julius Erving, Wilt Chamberlain, Bob Cousy, Shaq, Bill Russell, Jerry West, Steph Curry, Kevin Durant, Kobe Bryant , Ajaib dan Layak, dan Lebron. Dia bercanda dengan, “Bagaimana Anda bisa mengatakan Lebron adalah yang terhebat, Kobe punya naluri membunuh!” Perdebatan verbal kami akan meluas ke apa saja persyaratannya, apa yang membuat seseorang menjadi bagian dari percakapan yang hebat, atau bahkan kandidat untuk bagian dari diskusi. Apakah mereka membutuhkan umur panjang, mencetak rekor, kecakapan bertahan, penghargaan dan kehormatan lainnya? Berapa minimal penghargaan Pemain Paling Berharga yang harus mereka miliki? Bagaimana dengan transendensi zaman mereka? Bagaimana dengan ini atau itu, dan tentu saja teman saya Brandon selalu cepat memberikan gelar!

Cara Memilih Solusi Ketersediaan Tinggi Terbaik

Tapi, apa hubungannya dengan iniKetersediaan Tinggi? Senang Anda bertanya. Seberapa sering Anda diminta untuk menyediakan atau memilih solusi ketersediaan terbaik atau ketersediaan lebih tinggi dari sekian banyak pesaing? Anda telah memutuskan bahwa akhir pekan terakhir yang dirusak oleh kerusakan aplikasi yang tidak direncanakan atau server produksi yang tidak berfungsi adalah akhir pekan terakhir yang akan dirusak oleh kurangnya pemantauan dan pemulihan otomatis. Namun, solusi mana yang terbaik di antara nama-nama besar seperti: Microsoft Failover Clustering, SuSE High Availability Extensions, PaceMaker, NEC ClusterPro, vWare HA, SIOS Protection Suite, dan SIOS AppKeeper? Empat hal yang saya pelajari dalam perdebatan tentang Yang Terhebat Sepanjang Masa yang akan membantu Anda mengatasi kesulitan ketersediaan Anda yang semakin tinggi.

Persyaratan HA

Pertama, apa saja persyaratannya? Jika saya menginginkan penembak murni terbaik sepanjang masa, saya akan dengan mudah dan siap memasukkan Steph Curry. Jika saya menginginkan kehadiran fisik yang paling mengintimidasi, saya akan memilih seseorang seperti Shaq. Jika saya membutuhkan rekan setim terbaik, pemimpin pendukung, atau orang-orang hebat lainnya, maka saya pikir Lebron James, Magic Johnson, Jerry West, Larry Bird ada dalam percakapan. Demikian pula, sebelum Anda mulai membuat solusi HA, pahami apa yang Anda butuhkan. Adalahreplikasi datapenting atau opsional? Apakah kamu membutuhkanSQLatau apakah Anda juga cenderung menggunakan database lain? Aplikasi dan paket lain apa yang diperlukan? Apakah Anda memerlukan solusi yang dapat mengantarkan Anda ke cloud, namun pertama-tama solusi tersebut harus menjinakkan sistem lama, vmWare, dan fisik? Apakah Anda akan menjadi toko aplikasi Windows sepenuhnya, atau campuran? Cobalah untuk memikirkan tim Anda juga. Apakah Anda memiliki pergantian karyawan yang tinggi yang membuat pengelolaan berbagai solusi menjadi sulit, kursus pelatihan penting, danorang-orang nyata yang mendukungkritis? Apakah Anda memerlukan kemudahan penggunaan atau hanya mengutamakan ketahanan? Di manakah kesesuaian umur panjang dan stabilitas penawaran, produk, dan perusahaan?

Kedua, bagaimana Anda memprioritaskan kebutuhan Anda? Bagaimana Anda akan memprioritaskan hal-hal hebat dibandingkan dengan persyaratan yang telah ditetapkan? Temanku Brandon selalu cepat memberikan gelar. Dia selalu membalas, berapa gelar yang dimiliki Lebron? Gelar adalah raja dalam perdebatannya. Saya biasanya, dan dengan sinis membalas dengan menyatakan bahwa bahkan pemain ke-12 di bangku cadangan mendapat cincin. Saya menyoroti fakta bahwa Robert Horry, seorang penyerang yang luar biasa, memiliki lebih banyak gelar daripada Lebron dan MJ. Lakukan percakapan yang jujur ​​dan jujur ​​tentang prioritas persyaratan. Saat Anda memilih solusi HA, seberapa penting kemudahan penggunaan, dukungan OS, dan luasnya dukungan aplikasi dibandingkan dengan RTO/RPO? Fitur dan persyaratan apa yang dianggap wajib, harus dimiliki, dan enak untuk dimiliki. Sebagai VP Pengalaman Pelanggan, kami pernah bertemu dengan seorang pelanggan yang bersikeras bahwa perangkat lunak cluster mendukung 32 node, meskipun faktanya mereka tidak memiliki rencana untuk membangun cluster yang lebih besar dari dua atau tiga node. Prioritaskan daftarnya.

Mengukur RPO dan RTO untuk Pemulihan Bencana

Ketiga, bagaimana Anda mengukur persyaratan tersebut? Bagaimana Anda mengukur yang terbaik terhadap persyaratan yang ditetapkan? Statistik dalam bola basket menyenangkan, informatif, dan sering kali menyesatkan. Brandon sering mengingatkan saya untuk memeriksa bagaimana gelar pencetak gol dimenangkan sesering saya mengajarkan berapa banyak yang dimenangkan. Kita sering melontarkan pertanyaan tentang siapa yang lebih baik untuk memulai atau menutup permainan dan bagaimana mengukur dorongan, intensitas, dan keinginan untuk menang. Demikian pula, saat Anda menelusuri literatur, tuangkan bukti detail konsep, tentukan dan tentukan bagaimana Anda akan mengukur hal-hal seperti RPO dan RTO. Apakah RTO didasarkan pada waktu koneksi kembali klien atau waktu aplikasi dimulai ulang? Apakah Anda mengukur RTO untuk afailover (kerusakan server), pemulihan (kerusakan aplikasi), peralihan manual (tindakan administratif), atau semua hal di atas? Jika kinerja aplikasi penting bagi Anda, seperti apa pengukurannya? Apakah kinerja baca, kinerja tulis, atau berdasarkan beban kerja aktual atau karakteristik klien? Pikirkan tentang di mana letak tolok ukurnya, atau benarkah? Juga, jujurlah tentang apa yang Anda bandingkan dengan angka-angka tersebut. Mengukur waktu kueri database yang lebih cepat selama pengoperasian normal dan pemulihan adalah hal yang penting, namun bagaimana jika solusi lainnya menimbulkan kelambatan yang dialami lebih tinggi dalam pengalaman pengguna?

Mengevaluasi Ketersediaan Tinggi dan Pemulihan Bencana

Terakhir, teruslah mengevaluasi. Sejak Julius menggoyang bayi hingga tertidur di baseline, hingga saat Jordan lepas landas dari garis lemparan bebas, hingga saat Steph Curry memasukkan satu langkah ke dalam garis setengah lapangan, permainan bola basket telah berkembang. Kesombongan “Jordan Rules” dan “Bad Boy Era” telah diganti dengan seperangkat aturan yang mengutamakan dan menonjolkan kombinasi keterampilan, kekuatan, dan kemahiran. Begitu pula dengan lanskap teknologi yang terus berubah. Solusi yang masuk sepuluh besar ketika server Solaris dan MP-RAS berkuasa, mungkin tidak beradaptasi dengan kegesitan Linux, Windows atau varian lainnya. Solusi berbasis SAN yang memanfaatkan kekuatan Fibre Channel mungkin sudah ketinggalan zamanawanDanDunia tanpa SAN. Jadi, terus evaluasi kehebatannya. Pantau terus bagaimana solusi-solusi dalam sepuluh besar bergerak mengikuti tren, atau lebih baik lagi, tetap mewujudkannya.

Meskipun perdebatan saya dengan Brandon terus berlanjut, dan kemungkinan besar generasi mendatang, bahkan anak-anak kita belum akan memilih pemenangnya, Anda dapat memilih solusi HA yang tepat untuk memenuhi kebutuhan ketersediaan perusahaan Anda.Hubungi perwakilan SIOSuntuk membantu Anda memahami, memprioritaskan, dan mengukur kemampuan SIOS Protection Suites untuk melampaui kebutuhan Anda.

Direproduksi dengan izin dariSIOS

https://www.sios-apac.com/id/2024/04/16300/

Solusi Pemulihan Bencana: Bagaimana Menangani “Rekomendasi” Versus “Persyaratan”

Katakanlah Anda mengalami masalah dilingkungan kluster awan, dan Anda harus menghubungi salah satu vendor aplikasi Anda untuk menyelesaikannya. Mereka memberi Anda resolusi, namun mereka mencatat dalam tanggapan mereka bahwa cara Anda mengkonfigurasi sistem ini “tidak disarankan”. Bagaimana Anda menangani informasi ini? Bagaimanapun, semuanya telah bekerja dengan sangat baik sejauh ini, dan mungkin diperlukan banyak waktu dan sumber daya untuk mengkonfigurasi ulang semuanya dengan cara yang “direkomendasikan”. Di sisi lain, pastinya direkomendasikan oleh vendornya karena suatu alasan bukan? Bagaimana jika hal itu menyebabkan komplikasi lain di kemudian hari? Mari kita lihat apa sebenarnya yang dimaksud dengan rekomendasi, dan cara-cara yang bisa Anda lakukan untuk mendekatinya dari kedua sisi penerimaan.

Konfigurasi yang Direkomendasikan Solusi DR

Anda harus mulai mencari cara menangani rekomendasi dengan memahaminya secara harfiah, yang didefinisikan sebagai “saran atau usulan mengenai tindakan terbaik”. Kita sudah dapat melihat beberapa petunjuk di sini tentang bagaimana kita dapat mendekati mereka dengan kata “saran” dan “proposal” yang digunakan untuk mengidentifikasinya. Melihat hal ini, sangat mudah untuk menolak rekomendasi vendor karena merepotkan, atau mungkin dianggap tidak diperlukan.

Namun, sebelum mengambil tindakan apa pun terhadap suatu rekomendasi, pastikan untuk mempertimbangkannya secara lebih pragmatis. Lagi pula, ada alasan mengapa vendor menyarankan konfigurasi semacam ini. Mereka sama tertariknya dengan kesuksesan Anda seperti halnya Anda sebagai bagian dari hubungan yang berkelanjutan, jadi tentunya hal itu membawa manfaat positif. Bisa jadi tanpa konfigurasi yang disarankan, Anda lebih rentan terhadap jenis kesalahan tertentu. Bisa juga terjadi penurunan kinerja, dimana segala sesuatunya bekerja dengan baik namun bisa saja bekerja lebih baik atau lebih cepat. Dengan mempertimbangkan hal ini, bukankah lebih baik meluangkan waktu dan upaya untuk memenuhi rekomendasi ini sekarang, dibandingkan memulainya setelah Anda terkena dampak buruk karena tidak mengikuti rekomendasi tersebut?

Cara Menangani Konfigurasi Solusi DR Di Luar Rekomendasi

Sekarang kita dapat membangun perspektif penuh kita mengenai rekomendasi dengan menyatukan kedua ujung diskusi ini. Versi ringkasannya adalah: “Tidak apa-apa untuk tidak mengikuti rekomendasi vendor, selama Anda mengetahui mengapa rekomendasi tersebut direkomendasikan dan menerima potensi kerugian dari tindakan tersebut”. Langkah penting pertama adalah berbicara dengan vendor. Ajukan pertanyaan kepada mereka tentang mengapa mereka merekomendasikannya, dampak dari memilikinya versus tidak, apakah mereka memiliki metode atau prosedur untuk dengan mudah bertransisi ke lingkungan yang direkomendasikan, dan hal lain yang dapat Anda pikirkan untuk membantu memberikan informasi yang lebih baik kepada diri Anda dan tim internal Anda. Setelah Anda memahami dampaknya, Anda berada pada posisi yang tepat untuk menolaknya jika Anda memiliki alasan yang tepat. Contoh pembenaran yang baik untuk menolak rekomendasi adalah demi alasan keamanan. Mungkin lingkungan yang direkomendasikan akan menonaktifkan atau mengabaikan langkah-langkah keamanan tertentu yang Anda miliki, jadi menggunakan lingkungan tersebut tidak hanya akan membuat Anda lebih rentan, namun juga dapat menyebabkan pelanggaran terhadap keamanan.SLA, perjanjian mitra, atau standar yang wajib Anda patuhi. Dalam hal ini Anda dapat memberi tahu vendor mengapa Anda tidak mengikuti konfigurasi yang disarankan. Hal ini juga bisa sangat bermanfaat bagi vendor, karena mereka dapat menerima umpan balik ini dan di masa depan menerapkan perbaikan yang memungkinkan konfigurasi yang direkomendasikan dan langkah-langkah keamanan pada saat yang bersamaan. Seperti disebutkan sebelumnya, mereka juga berinvestasi dalam kesuksesan Anda, jadi ini adalah kemenangan bagi semua orang.

Persyaratan Solusi Pemulihan Bencana

Namun terkadang, tidak mudah untuk mengatakan “tidak” terhadap apa yang dikatakan vendor kepada Anda. Di sinilah Anda melintasi batas dari “rekomendasi” vendor ke “persyaratan” vendor, dan hal itu menjadi tidak dapat dihindari. Ketika hal ini disajikan kepada Anda sebagai suatu persyaratan, itu menjadi sesuatu yang tidak bisa Anda tolak begitu saja. Namun, seperti halnya rekomendasi, penting untuk memahami mengapa hal ini merupakan suatu persyaratan, dan untuk apa sebenarnya hal tersebut merupakan suatu persyaratan. Praktik tertentu mungkin diwajibkan sebagai bagian dari SLA yang Anda sepakati dengan vendor, atau TSA untuk produk, aplikasi, atau layanan. Dalam kasus ini, perubahan yang diperlukan untuk memenuhi persyaratan ini harus dilakukan. Persyaratan juga biasanya berada pada sisi yang lebih teknis. Misalnya, spesifikasi ukuran disk, kapasitas I/O, atau sumber daya mesin yang tersedia, hanyalah beberapa di antaranya. Hal ini cenderung diperlukan agar aplikasi dapat berfungsi sebagaimana mestinya, sehingga manfaat dalam memastikan persyaratan ini dipenuhi sudah terlihat jelas.

Fleksibilitas Solusi Pemulihan Bencana

Hanya karena Anda harus mengikuti persyaratan tidak berarti Anda harus mengundurkan diri begitu saja. Masih banyak manfaat yang bisa dilihat dalam memahami mengapa persyaratan tersebut diberlakukan. Seperti halnya rekomendasi, berbicara dengan vendor Anda sangatlah penting. Mungkin alasan Anda tidak menyukai persyaratan tersebut berakar pada kesalahpahaman, dan mendiskusikan alasan tersebut dengan vendor Anda dapat mengungkap hal tersebut dan menghilangkan kekhawatiran. Sekali lagi, masukan Anda mengenai persyaratan ini bisa sangat penting bagi vendor Anda untuk meningkatkan produk atau layanan, dan membantu mereka memahami nilai yang Anda lihat dalam kemampuan melakukan sesuatu dengan cara yang berbeda. Yang diperlukan hanyalah memulai dialog.

Ketersediaan Tinggi SIOS dan Pemulihan Bencana

SIOS Technology Corporation menyediakanketersediaan tinggiDanPemulihan bencanaproduk yang melindungi & mengoptimalkan infrastruktur TI dengan manajemen cluster untuk aplikasi terpenting Anda.Hubungi kami hari iniuntuk informasi lebih lanjut tentang layanan dan dukungan profesional kami.

Direproduksi dengan izin dariSIOS