Mencapai Ketersediaan Tinggi SQL Server yang Hemat Biaya di Google Cloud dengan SIOS DataKeeper

Mencapai Ketersediaan Tinggi SQL Server yang Hemat Biaya di Google Cloud dengan SIOS DataKeeper

Memastikanketersediaan tinggi untuk SQL ServerPenerapan sangat penting untuk menjaga kelangsungan bisnis di Google Cloud Platform (GCP). Saat memilih cara untuk mencapainya, ada dua opsi utama yang tersedia: Always On Availability Groups dan SQL Server Failover Cluster Instances (FCI).

Grup Ketersediaan Selalu Aktifmenawarkan solusi komprehensif untuk ketersediaan tinggi dan pemulihan bencana, tetapi mereka memerlukan SQL Server Enterprise Edition, yang dapat menjadi investasi signifikan, terutama bagi bisnis yang tidak memerlukan rangkaian fitur lengkap yang ditawarkan oleh versi Enterprise.

Instansi Kluster Failover SQL Server (FCI), yang didukung oleh SQL Server Standard Edition, menghadirkan alternatif yang lebih hemat biaya. Namun, FCI biasanya mengandalkan solusi penyimpanan bersama seperti SAN, yang tidak tersedia secara native di GCP. Kurangnya penyimpanan bersama yang mendukung kluster ini menimbulkan tantangan bagi bisnis yang ingin menerapkan FCI di cloud.

Bagaimana SIOS DataKeeper Mengatasi Tantangan FCI di GCP

Penjaga Data SIOSmenyediakan solusi yang menjembatani kesenjangan tersebut, yang memungkinkan organisasi membangun kluster tanpa SAN di GCP. Pendekatan ini menghilangkan kebutuhan akan penyimpanan bersama tradisional dengan mereplikasi data secara sinkron di berbagai zona dalam suatu wilayah.

SIOS DataKeeper tidak hanya mereplikasi disk lokal yang terpasang pada setiap instans cloud, tetapi juga menyajikan disk yang direplikasi ke cluster sebagai sumber daya Volume DataKeeper. Bagi cluster, volume ini muncul sebagai disk bersama, yang terintegrasi dengan lancar denganPengelompokan Kegagalan Windows Server (WSFC)Selama failover, DataKeeper mengontrol arah mirror, memastikan bahwa node aktif tetap menjadi sumber mirror sementara node lainnya menjadi target. Pengaturan ini mempertahankan konsistensi data dan ketersediaan tinggi untuk lingkungan SQL Server Anda, semuanya saat menggunakan SQL Server Standard Edition.

Keuntungan Utama Menggunakan SIOS DataKeeper di GCP

1. Penghematan Biaya:Dengan mengaktifkan penggunaan SQL Server Standard Edition untuk FCI,SIOS DataKeeper membantu organisasi menghindari biaya yang lebih tinggiterkait dengan SQL Server Enterprise Edition.
2. Perlindungan Komprehensif: SIOS DataKeeper mereplikasi seluruh instans SQL Server di seluruh zona, menyediakan perlindungan yang kuat terhadap kegagalan tingkat zona.
3. Kesederhanaan dan Fleksibilitas: Solusi ini menyederhanakan proses pengaturan dan pengelolaan FCI SANless di GCP, membuatnya dapat diakses oleh tim TI dan mengurangi kompleksitas.

Pemikiran Akhir tentang SQL Server HA yang Hemat Biaya di GCP

Untuk bisnis yang berjalanSQL Server di Google Cloud, menemukan keseimbangan yang tepat antara biaya dan ketersediaan sangatlah penting. Meskipun Always On Availability Groups sangat hebat, harganya lebih mahal. SIOS DataKeeper menawarkan alternatif praktis dengan memungkinkan pembuatan kluster SANless yang menyediakan ketersediaan tinggi yang diperlukan sekaligus menjaga biaya tetap terkendali dengan SQL Server Standard Edition.

Untuk panduan langkah demi langkah tentang cara menerapkan solusi ini, saya sarankanmembaca artikel selengkapnya, yang mencakup semuanya mulai dari pengaturan jaringan hingga konfigurasi kluster. Panduan ini akan membantu Anda menerapkan sistem yang sangat tersediaLingkungan SQL Server di GCPdengan percaya diri.

Ambil Langkah Berikutnya dalam Mencapai SQL Server HA yang Hemat Biaya

Siap untuk meningkatkan ketersediaan tinggi SQL Server Anda di Google Cloud tanpa menguras kantong? Jelajahi bagaimana SIOS DataKeeper dapat menyederhanakan penerapan dan memaksimalkan investasi Anda.Hubungi tim kamiuntuk bantuan ahli dalam menyiapkan kluster SANless yang memenuhi kebutuhan bisnis spesifik Anda.

Direproduksi dengan izin dariSIOS

Bagaimana Acara Pagi “Get Up” ESPN Dapat Meningkatkan Strategi Ketersediaan Tinggi Anda

Bagaimana Acara Pagi “Get Up” ESPN Dapat Meningkatkan Strategi Ketersediaan Tinggi Anda

ESPN sering kali menjadi sumber informasi utama tentang NFL. Jaringan ini dikenal menyediakan banyak acara untuk meliput setiap pertandingan, yang menyediakan analisis ekstensif, opini, dan informasi acak tentang tim, pertandingan, jadwal mendatang, dan pelatih di liga serta sorotan pemain tertentu.

Belajar dari ESPN: Tingkatkan Ketersediaan Tinggi Anda dengan Dua Pertanyaan Utama

Dalam segmen yang ditayangkan pada tanggal 13 September 2021, Dan Orlovsky menyesalkan penggunaan quarterback pemula oleh Chicago Bears. Dalam melakukannya, ia secara tidak sengaja memberikan dua cara untuk meningkatkan ketersediaan tinggi Anda hanya dengan dua pertanyaan. Dua pertanyaan yang akan segeratingkatkan ketersediaan tinggi Andadari Dan Orlovsky dari ESPN.

Pertanyaan nomor satu, apa yang kita lakukan di sini?

Serangan Bears menempatkan quarterback pemula Justin Fields di lapangan untuk permainan kedua. Pemain pemula itu dengan cepat melepaskan umpan untuk penyelesaian sejauh tujuh yard. Namun, alih-alih melanjutkan dengan pemain pemula itu, para pemanggil permainan Bears kembali ke QB mereka sebelumnya yang segera melemparkan bola ke tim lain. Permainan ini menimbulkan pertanyaan dari Dan Orlovsky, “Apa yang kita lakukan di sini?”

Oke, jadi menurutku kamu bukan quarterback pemula. Dan, kuharap kamu tidak bermain untuk Bears. Namun, jika kamu bertanggung jawab atas bagian mana pun dari perusahaanmuketersediaan tinggi (HA)Danpemulihan bencana (DR)strategi, termasukkekelompokanBahasa Indonesia:perlindungan dataBahasa Indonesia:replikasi data, orkestrasi aplikasi, tata kelola/kepatuhan danSLA (Sla yang berlaku), maka pertanyaan pertama Orlovsky adalah tempat yang baik untuk memulai.

Apa yang sedang kamu lakukan?

• Apakah Anda ingin menerapkan perangkat lunak dan layanan atau memperbaiki masalah ketersediaan yang diketahui?
• Apakah fokus utama tim Anda adalah merencanakan masa depan, seperti pindah ke cloud, atau menangani beberapa kombinasi perubahan dan persyaratan yang berbeda?
• Apakah tujuan Anda menghemat biaya sekaligus memenuhi persyaratan regulasi, meningkatkan akuisisi klien melalui lebih banyak sumber daya yang tersedia, atau mengoptimalkan dan meningkatkan pemrosesan backend?

Menjawab pertanyaan ini sehubungan dengan strategi ketersediaan tinggi dan pemulihan bencana (HA/DR) perusahaan Anda akan membantu memperjelas banyak hal sehubungan dengansolusi dan arsitekturAnda terapkan, serta tim dan proses yang terkait dengannya.

Pertanyaan nomor dua, mengapa kita melakukannya?

Setelah melontarkan serangkaian komentar cepat tentang rasa frustrasinya dengan kapan dan bagaimana Chicago Bears menggunakan quarterback pemula mereka, Orlovsky mengajukan pertanyaan kedua, “Mengapa kita melakukannya?” Jika, mengutip Orlovsky, “apa” yang dimaksud adalah menempatkan Fields untuk mencentang kotak dan menenangkan para penggemar, maka “mengapa kita melakukannya?” Mengapa hanya mencentang kotak, ketika Anda dapat menggunakan lebih banyak kemampuan pemula yang dinamis untuk mendapatkan keuntungan dan memenangkan pertandingan? Mengapa tidak membuat perubahan yang memberi Anda peluang terbaik untuk berhasil.

Tentu saja, kami bukan pelatih Bears, meskipun saya tidak keberatan untuk melakukan beberapa hal. Namun, pertanyaan tersebut tetap berlaku bagi mereka yang terlibat dalam penerapan ketersediaan perusahaan. Mari kita kembali ke pertanyaan nomor satu. Apa jawaban Anda untuk “apa yang kita lakukan di sini?” Sekarang, jawab pertanyaan “mengapa kita melakukannya?” Beberapa kemungkinan alasannya meliputi:

• Memberikan jaminan ketersediaan data
• Menghemat waktu bisnis
• Menghemat uang bisnis dengan menghindari waktu henti yang tidak direncanakan dan mahal
• Menghemat waktu dan uang bisnis dengan mengotomatiskan pemantauan dan pemulihan
• Menerapkan arsitektur untuk memenuhi Perjanjian Tingkat Layanan (SLA) atau Tujuan Tingkat Layanan (SLO) yang ketat
• Mengurangi RTO dan RPO menjadi nol
• Mencegah bencana tahun lalu terjadi lagi
• Melindungi diri dari ancaman waktu henti yang tidak diketahui
• Memenuhi persyaratan tata kelola
• Mencentang kotak
• Berusaha untuk tidak didenda karena tidak patuh
• Karena manajemen mengatakan demikian

Mengapa kita melakukannya adalah pertanyaan penting yang harus dijawab sebelum, selama, dan setelah sistem ketersediaan tinggi diterapkan. Sebagai VP Pengalaman Pelanggan, saya bekerja dengan pelanggan yang Administrator TI dan Administrator DB-nya memiliki alasan yang sangat berbeda untuk “mengapa kita melakukannya?” Lebih buruk lagi, sponsor eksekutif memiliki pandangan ketiga. Tanpa “mengapa” yang diperiksa dan dikomunikasikan dengan benar, tim kesulitan untuk mengartikulasikan persyaratan dengan benar, dan ketika insiden terjadi, upaya mereka untuk perbaikan sering kali menimbulkan lebih banyak konflik dan pertanyaan.

Kemungkinan ada sejumlah alasan mengapa Chicago Bears tidak berhasil atau tidak memanfaatkan QB muda mereka dengan baik pada down ketiga yang akan datang, dan jumlah pendapat yang sama tentang apa yang ingin mereka capai dengan franchise dan quarterback veteran mereka. Namun, meskipun Orlovsky tidak dapat membantu penggemar Bears menjelaskan apa atau mengapa, ia memberikan kerangka kerja tentang cara segera meningkatkan HA Anda. Jadi, bagaimana Anda akan menjawab dua pertanyaan: Apa yang kita lakukan untuk HA? Mengapa kita melakukannya?

Solusi Ketersediaan Tinggi

SIOS Technology Corporation menyediakan ketersediaan tinggiperangkat lunak klasteryang melindungi & mengoptimalkan infrastruktur TI dengan manajemen kluster untuk aplikasi Anda yang paling penting.Hubungi kamihari ini untuk informasi lebih lanjut tentang layanan dan dukungan profesional kami.

Direproduksi dengan izin dariSIOS

Cara memaksimalkan perintah “GET” di DataKeeper

Cara memaksimalkan perintah “GET” di DataKeeper

Pada bagian 2 dari seri blog dasbor DataKeeper tiga bagian, blog ini merupakan tindak lanjut dariAntarmuka Pengguna DataKeeper vs. Dasbor Mobilblog. Seperti halnya mobil Anda, saat indikator tersebut (warna lampu lalu lintas) di dasbor Anda berkedip, Anda membuka kap mobil untuk mengidentifikasi apa yang dilambangkannya. Titik awal:

• Lampu Baterai = periksa baterai, sambungan kabel, alternator, dll.
• Lampu Oli = memeriksa dipstick untuk oli rendah, tinggi atau tidak ada (Tidak ada oli, JANGAN GUNAKAN MOBIL ANDA)
• Lampu Pendingin = Apakah ada cairan pendingin/air di tangki pengisian penuh?

“Membuka kap mesin” diEdisi Cluster DataKeeperperangkat lunak memiliki beberapa kesamaan dan sering kali berarti menggunakan antarmuka baris perintah untuk Administrasi DataKeeper. Mengenai Penggunaan EMCMD (Extended Mirroring Command) dengan SIOS DataKeeper, perintah GET mencakup 1/3 dari tugas/perintah yang paling umum digunakan dari sekitar 48 perintah. Perhatikan bahwa perintah tersebut hanya bersifat informasional dan tidak akan memengaruhi node Anda. Berikut ini adalah beberapa perintah Get yang bermanfaat dan penggunaannya untuk mengidentifikasi alasan warna peringatan di Antarmuka Pengguna DataKeeper/DataKeeper.msc (warna lampu lalu lintas) di area Penyimpanan, Jaringan, dan Lainnya.

Catatan:

Dari prompt perintah yang ditinggikan/Administrator seperti biasa gunakan:

cd %extmirrbase%(Ini hanyalah jalan pintas ke jalur instalasi <root>\Program Files (x86)\SIOS\DataKeeper>)

Mendapatkan Status Mirror DataKeeper Anda

Tempat yang bagus untuk memulai perawatan awal Anda di bawah ini:

• dapatkanmirrorvolinfo(Lainnya) Ini adalah alat yang paling banyak digunakan karena menyediakan peran Cermin, Sumber/Target, dan 5 status berbeda yang dapat dimiliki Cermin. Alat ini dapat dijalankan pada sumber atau target untuk memeriksa apakah konfigurasi cermin tersedia.

• dapatkan info layanan(Lainnya) – Informasi hebat tentang
  • Versi Driver dan Versi Layanan DataKeeper
  • dan waktu Layanan SIOS DataKeeper dimulai/dihidupkan kembali
• dapatkan daftar volume lengkap(Penyimpanan/Jaringan) – daftar lengkap
  • dari semua disk
  • Volume DataKeeper dan non-DataKeeper
  • Peran mereka (Sumber/Target) dan Total Kapasitas (dalam byte)
• dapatkan info pekerjaan(Penyimpanan/Jaringan) ini menampilkan/menggemakan informasi pekerjaan yang tercantum di konsol DataKeeper
• dapatkan info volume(Penyimpanan, Jaringan) Utilitas hebat saat
  • membandingkan Total Kapasitas Drive dari Volume Sumber (diskmgmt.msc) dan Volume Target (byte)
  • Alamat IP dan status Cermin saat ini

Melakukan referensi silang perintah DataKeeper “GET” ke berbagai Perintah Windows Server

• Dapatkan info pekerjaandan “ipconfig /all” (Jaringan)
  • Apakah alamat IP identik di kedua output? Jika Replikasi Cermin akan disegmentasikan ke jaringan lain maka getjobinfo harus cocok dengan output ipconfig /all. Menjalankanubah titik akhir cerminakan memperbaiki perbedaan ini (akan dibahas di blog lain)
    • Juga informasi mirrorendpoints daridapatkan info pekerjaanoutput harus sesuai dengan alamat IP yang ditemukan di output ipconfig /all
• Setelah melakukanUbah Ukuran Volume Sumber dan Target yang ada, apakahemcmd .dapatkan info volumeperintah mencerminkan Total Ruang yang berbeda dariperintah DISKPARTdan Ukurannya? Melalui DISKPART “extend” atau “extend filesystem” mungkin diperlukan agar volume yang diubah ukurannya dikenali oleh Sistem Operasi
• Dapatkan daftar volume lengkapmemiliki informasi yang mirip dengan applet Manajemen Disk (diskmgmt.msc)
  • Tipe Sistem Berkas
  • Volume Total Ruang (byte)
  • Dapatkan info volumememberikan hasil yang serupa
• Dapatkan info layananserta “net start” dapat memberikan status tentang Layanan SIOS DataKeeper; jika itu adalah Mulai/Berhenti

Ambil Kendali DataKeeper: Terapkan Pengetahuan Perintah GET Anda Sekarang

Sekarang setelah Anda dibekali dengan pengetahuan dasar tentang lampu pada dasbor mobil, Anda akan menjadi DIYer dalam hal Administrasi DataKeeper di blog 3 dalam seri Dasbor DataKeeper.

Direproduksi dengan izin dariSIOS

6 Pelajaran Ketersediaan Tinggi yang Dipetik dari Mimpi Buruk Keamanan Siber

6 Pelajaran Ketersediaan Tinggi yang Dipetik dari Mimpi Buruk Keamanan Siber

Baru-baru ini, penyedia layanan keamanan melaporkan beberapa saran dan rekomendasi praktik terbaik bagi perusahaan terkait meningkatnya ancaman keamanan. Meskipun ancaman keamanan harus menjadi perhatian setiap bisnis, saran ini tidak terbatas pada keamanan siber; saran ini juga relevan bagi mitra dan pelanggan HA dengan aplikasi dan layanan penting yang perlu dilindungi.

Enam Poin Penting untuk HA dari Artikel Terbaru tentang Keamanan Siber

1. Ambil langkah SEGERA untuk meningkatkan HA
   Menunggu insiden downtime dan berfokus pada pemulihan cepat adalah strategi yang buruk. Mempersiapkan danmencegah waktu hentiadalah solusi yang lebih baik. Mulailah mengidentifikasi aplikasi, basis data, dan layanan Tier1 dan Tier2 yang penting. Tier 1 harus mencakup semuasolusi penting bagi bisnisyang tidak dapat diakses. Yaitu, aplikasi yang harus tersedia 24/7 dan akan menimbulkan konsekuensi bisnis yang serius jika tidak dapat diakses. Meskipun aplikasi Tier 2 harus berjalan sesering mungkin, aplikasi tersebut tidak terlalu penting dan bisnis Anda dapat menoleransi pemadaman hingga beberapa jam tanpa dampak bisnis yang signifikan.
2. Menyiapkan rencana perlindungan HA yang komprehensif
   Kembangkan rencana untuk melindungi aplikasi, basis data, dan layanan utama. Pastikan rencana ini mencakup dokumentasi arsitektur dan desain serta tanggung jawab personel untuk menanggapi waktu henti. Selalu persiapkan proses untuk menyebarkan kluster di lingkungan QA atau sandbox dengan tujuan mendokumentasikan aktivitas dan detail ke dalam buku panduan. Sistem sandbox dan QA ini juga dapat digunakan untuk pengujian, pelatihan, dan validasi pemutakhiran, perbaikan terbaru, dan pemeliharaan.
3. Kenali dan atasi risiko ketersediaan tinggi
   Semua organisasi harus menyadari bahwa tidak ada perusahaan yang aman dari gangguan waktu henti, terlepas dari ukuran atau lokasinya. Bisnis kecil, menengah, dan besar semuanya rentan terhadap bencana, baik yang disebabkan oleh alam maupun manusia. Organisasi besar akan mengalami banyak kesalahan pengguna, kegagalan pusat data akibat konstruksi lokal, infrastruktur yang gagal, dan pemadaman dari komponen jaringan. Entitas kecil dan menengah, khususnya yang memiliki solusi lokal atau tim TI yang lebih kecil,perlu menambahkan perlindungan HAjuga. Sementara perusahaan besar mungkin kehilangan lebih banyak uang saat terjadi pemadaman, bisnis kecil hingga menengah kemungkinan juga akan kehilangan jumlah yang sama. Penting untuk dicatat bahwa pindah ke cloud tidak cukup untuk mencegah semua risiko.
4. Para eksekutif bisnis perlu memimpin dalam strategi ketersediaan tinggi
   Mempersiapkan dan menjaga terhadap waktu henti bukan hanya masalah tim TI. Para eksekutif bisnis perlu terlibat dalam melindungi bisnis dari risiko yang diketahui, paparan, dan ancaman waktu henti. Ini berarti para eksekutif utama dan pemangku kepentingan perlu secara proaktif bertanya tentang cakupan HA, rencana, dan staf. Para eksekutif bisnis juga harus bersiap untuk melakukan investasi dalam mempersiapkan hal yang tidak terduga dengan memastikan cakupan penuh aplikasi, basis data, layanan, dan data tingkat 1. Mereka juga harus secara proaktif memperluas cakupan ke tingkat 2 dan seterusnya.
5. Pentingnya Komunikasi Berkelanjutan untuk HA
   Kepemimpinan bisnis, Admin dari semua area (jaringan, penyimpanan, komputasi, cloud, basis data, dan aplikasi) harus sering bertemu untuk membahas ancaman HA yang baru dan yang sudah ada, tantangan baru dan yang sudah ada, dan persyaratan yang sedang berlangsung. Menjaga diskusi tim internal agar memahami persyaratan dan rencana kesinambungan bisnis adalah suatu keharusan. Faktanya, pertimbangan HA perlu menjadi bagian integral dari semua perencanaan dan komunikasi internal yang relevan dari level C hingga level pemula. Namun, komunikasi ini tidak dapat berhenti pada pemangku kepentingan internal. Sebaliknya, para pemimpin bisnis dan pemangku kepentingan HA harus meninjau postur perusahaan, persyaratan HA, dan temuan penting dengan vendor HA dan tim R&D dan dukungan mereka.
6. Jangan menunggu bencana untuk meninjau solusi HA Anda
   Perusahaan perlu meninjau rencana dan kemampuan mereka untuk melaksanakan rencana tersebut secara berkala. Tinjauan ini perlu dilakukan lebih mendalam daripada sekadar membaca buku panduan, dokumentasi, atau desain kluster. Tinjau buku panduan tersebut bersamaan dengan latihan langsung untuk memvalidasi dan memperbarui buku panduan tersebut. Uji proses untuk memulihkan sistem setelah waktu henti, termasuk pemulihan operasi klien dan bisnis.

Bertindak Sekarang untuk Melindungi Sistem Anda dari Downtime

Mirip dengan rekomendasi keamanan, perusahaan harus segera mengambil tindakan untuk mengamankan sistem, solusi, aplikasi, dan data mereka dari waktu henti dan bencana. Jangan menunggu bencana untuk mengungkap celah dalam strategi HA Anda.Hubungi SIOS hari iniuntuk meningkatkan strategi HA Anda dan melindungi bisnis Anda dari gangguan yang tidak terduga.

Direproduksi dengan izin dariSIOS

UI DataKeeper vs. Dasbor Mobil: Panduan untuk Pemantauan Ketersediaan Tinggi

UI DataKeeper vs. Dasbor Mobil: Panduan untuk Pemantauan Ketersediaan Tinggi

Selain berbagi kenikmatan menggunakanEdisi Cluster DataKeeperdengan ituketersediaan tinggiDanpemulihan bencanakemampuan, kebanyakan dari kita memiliki kesamaan. . . kita mengendarai mobil… listrik, bensin atau hibrida. Pada tahun 2022, Forbes menyatakan bahwa 92% rumah tangga memiliki setidaknya satu mobil.

Dan jutaan mobil tersebut memiliki beberapa kesamaan dengan DataKeeper. . .

Dasbor dengan indikator status.

Dalam kasus DataKeeper, antarmuka pengguna (DataKeeper.msc) memiliki apa yang dikenal sebagai Definisi Cermin atau Status Cermin.

Pada mobil, indikator dikenal dengan sebutan “lampu dasbor” atau bagi sebagian dari Anda Generasi X mungkin menyebutnya“lampu bodoh”

Mari kita langsung membahas persamaannya.

Semua mobil memiliki tingkat pembakaran (bahan bakar), listrik (atau tidak) dan kemampuan pendinginan tertentu; Oleh karena itu, lampu terkait pada dashboard biasanya berwarna Merah, Kuning dan Hijau. Seperti dasbor mobil, UI DataKeeper memiliki skema “lampu lalu lintas” di Pohon Konsol.

Seperti yang kami sebutkan, skenario yang mungkin terjadi dalam pemecahan masalah mobil, misalnya baterai, masalah bahan bakar, mesin terlalu panas, seperti mesin Anda, pemecahan masalah DataKeeper juga dapat dikonsolidasikan ke bidang berikut:

• Penyimpanan
• Jaringan
• Lainnya (Keamanan, Administrasi Pengguna, dll.)

Merujuk kembali ke pengidentifikasi “lampu lalu lintas” di Pohon Konsol pada UI DataKeeper, mari kita lihat “di balik terpal” untuk mengidentifikasi keadaan Cermin.

Saat pengemudi membawa mobilnya untuk memperbaiki masalah atau melakukan servis rutin, Penasihat Teknis atau Teknisi Servis dealer, akan menyambungkan konektor OBD (Diagnostik On-board) untuk mendapatkan gambaran umum tentang di mana letak masalahnya. terjadi (pembakaran, listrik atau lainnya)

Identifikasi Warna Status Cermin untuk Mendiagnosis Masalah Penjaga Data

Sebagai pengguna yang mendukung/mendorong DataKeeper, triase tingkat pertama Anda harus mengidentifikasi perubahan “warna” pada cermin tersebut untuk mengonfirmasi apakah Penyimpanan, Jaringan, atau Lainnya telah memengaruhi pengguna, kinerja, dll.

Pengidentifikasi tersebut disebut definisi Cermin. Status cermin, mirip dengan OBD, dapat diidentifikasi dengan meluncurkan perintah yang disebut “emcmd. getmirrorvolinfo <huruf drive>“.

Catatan:

Untuk mendapatkan perintah “emcmd”, (yang merupakan singkatan dari Extended Mirroring Command), kita dapat meluncurkan command prompt (Administrator) yang ditinggikan sebagai berikut:

• “cd %extmirrbase%”
  • Ini adalah jalan pintas ke jalur instalasi tempat utilitas berada, misalnya <root>\Program Files (x86)\SIOS\DataKeeper

Outputnya akan ditampilkan sebagai “# nama host #”

Bilangan bulat pertama mewakili peran Cermin, (1 = Sumber, 2 = Target)

Adapun bilangan bulat terakhir, ada 6 keadaan yang dapat diperoleh Mirror:

1 – Pencerminan (Hijau)

2 – Cermin sedang menyinkronkan ulang (Kuning)

3 – Cermin Pecah (Merah)

4 – Cermin Jeda (Kuning)

5 – Penyuntingan Ulang Tertunda (Kuning)

Dengan beberapa variasi – seperti yang berkaitan dengan mobil atau DataKeeper Anda – seseorang harus mendapatkan titik awal untuk mengidentifikasi “titik nyeri”

• Sopir: Apakah Anda berbagi mobil dengan keluarga Anda? Apakah seseorang membiarkan lampu kubah menyala? Apakah jenis bahan bakarnya berubah dari oktan 94 menjadi 87?
• Administrator DataKeeper: Apakah Anda satu-satunya orang yang mendukung? Apakah departemen lain memiliki akses ke cluster Anda, misalnya Administrator Basis Data, Personil Infrastruktur yang bertanggung jawab atas Penyimpanan, Jaringan, dan lainnya?

Melihat ke Balik Terpal: Langkah-Langkah Pencegahan yang Harus Dilakukan Sebelum Anda Menskalakan Sumber Daya Terklaster Anda

Penyimpanan

Kerjakan pekerjaan rumahmu. Administrator Infrastruktur dan Basis Data ingin meningkatkan skala penyimpanan mereka untuk memenuhi permintaan yang terus meningkat. Mereka sangat berpengetahuan tentang tugas yang ada tetapi jika dilakukan dengan salah atau dalam urutan yang salah, warna Cermin di DataKeeper bisa jadi Merah, Kuning, atau tidak sama sekali. Lihat kamidokumentasi dan video pendukungtentang Cara Mengubah Ukuran Penyimpanan Anda dengan Benar.

Jaringan

Hindari sinkronisasi ulang penuh dengan mudah. Admin infrastruktur dan database mungkin ingin mengelompokkan lalu lintas mirror yang ada ke jaringan lain tanpa downtime atau hilangnya Ketersediaan Tinggi. Dapatkah Anda bayangkan tidak memiliki HA untuk membuat ulang mirror baru dan harus melakukan Sinkronisasi Ulang LENGKAP untuk beberapa Terabyte atau bahkan satu Petabyte data? Lihat kamidokumentasi dan video pendukungtentang bagaimana hal ini dapat dicapai dengan mudah

Lainnya (Keamanan)

Memahami manajemen kata sandi. Kebijakan kata sandi dapat berubah melalui jangka waktu yang ditentukan di Direktori Aktif. Jika hal ini tidak diketahui oleh Administrator, dan jika Layanan SIOS DataKeeper dimulai ulang, kata sandi yang telah diubah untuk akun Layanan SIOS DataKeeper (Direktori Aktif) TIDAK disebarkan secara otomatis. Oleh karena itu, pembaruan manual Kata Sandi Akun Layanan diperlukan dalam applet Layanan. (services.msc) Untuk penggunaan yang benar dari Akun Layanan SIOS DataKeeper, lihat kamidokumentasi pendukung

Mengelola Penyimpanan Data di Berbagai Departemen untuk Menghindari Waktu Henti

Mobil Anda dapat memiliki banyak pengemudi, Teknisi Servis yang berbeda, kondisi jalan yang berbeda dan sejenisnya. DataKeeper juga demikian karena mungkin ada departemen lintas fungsi yang bertanggung jawab atas Penyimpanan, Jaringan, Keamanan, dan lainnya, yang dapat berdampak buruk pada DataKeeper. Mungkin ada sumber daya berkerumun terkait yang memiliki hubungan/ketergantungan dengan DataKeeper. Departemen ini melakukan tugas tanpa sepengetahuan Administrator DataKeeper dan seperti lampu dasbor di mobil Anda, kaca spion Anda akan menampilkan warna “lampu lalu lintas”; terlihat Kuning dan Merah.

Daftar Periksa untuk Memantau Status Cermin DataKeeper dan Perubahan Infrastruktur

• Tinjau warna “Lampu Lalu Lintas”.
• Identifikasi status Mirror melalui emcmd . perintah getmirrorvolinfo
• Jika beberapa departemen terlibat, tanyakan tentang perubahan atau acara terjadwal di seluruh infrastruktur baik Penyimpanan, Jaringan, Keamanan, atau lainnya
• Tingkatkan triase awal Anda melalui log Peraga Peristiwa, keluaran ipconfig /all,dkhealthcheck, hanya untuk beberapa nama

Hubungi Dukungan SIOS untuk Masalah DataKeeper

Jika mobil Anda “kaput” dan meninggalkan Anda di pinggir jalan, kemungkinan besar Anda akan menghubungi AAA dan mereka akan menyediakan truk derek. Jika Anda memiliki kekhawatiran tentang Sumber Daya Volume DataKeeper yang terkelompok, hubungi Dukungan SIOS. Punya pertanyaan atau masalah non-prioritas, kirim email kepada kami disupport@us.sios.com. Jika masalah Anda mendesak, hubungi kami di 877-457-5113.

Direproduksi dengan izin dariSIOS