SIOS SANless clusters

Agustus 11, 2020	Pelajaran di Cloud High Availability dari Film Pelajaran di Cloud High Availability dari Film Joseph Lalonde dari jmlalonde.com memiliki blog yang menyoroti pelajaran kepemimpinan dari film-film populer seperti Hancock, The Greatest Showman, dan Frozen II. Sebagai penghargaan atas pelajaran kepemimpinan Joseph yang menginspirasi, berikut adalah empat pelajaran ketersediaan tinggi tentang migrasi cloud dari Disney's Frozen II. Disney's Frozen II dan Cloud Migration Lessons Dalam petualangan animasi Disney Frozen II, karakter Anna, Elsa, Kristoff, Olaf, dan Sven meninggalkan Arendelle untuk melakukan perjalanan ke hutan kuno yang terikat musim gugur di sebuah negeri yang mempesona. Dalam petualangan tersebut, mereka berangkat untuk menemukan asal muasal kekuatan Elsa untuk menyelamatkan kerajaan mereka. Selain menyenangkan bagi ayah dari enam anak perempuan, film ini juga sarat dengan pelajaran kepemimpinan, kehidupan, dan ketersediaan tinggi. 1. Anda tidak dapat melakukan migrasi cloud tanpa bantuan yang tepat. Ketika Elsa, Anna, Kristoff, Olaf dan Sven tiba di tempat di mana suara misterius itu memanggil mereka, mereka berdiri di luar awan yang sangat besar. Ketika Olaf dan Kristoff mencoba masuk, mereka terpental kembali dan ditolak. Hanya ketika Elsa mendekati awan dengan sihirnya, portal terbuka dan mereka masuk. Saat bermigrasi ke cloud, akan ada banyak suara yang menelepon Anda. Beberapa akan mengundang Anda ke AWS, atau Azure atau GCP, atau banyak lagi lainnya. Tapi, apa pun yang Anda inginkan, ketahuilah bahwa Anda akan membutuhkan bantuan yang tepat untuk entri yang sukses. Bantuan ini harus mencakup: Arsitek memiliki pengetahuan tentang platform, terutama aspek jaringan Administrator aplikasi yang memahami karakteristik instalasi, konfigurasi, operasi dan pemeliharaan aplikasi Administrator keamanan dan OS Perwakilan mitra cloud Ahli ketersediaan yang berpengetahuan luas untuk menerapkan aplikasi penting dalam arsitektur yang sangat tersedia 2. Hal-hal tidak akan masuk akal ketika Anda lebih tua, jadi dokumentasikan dan ulangi. Saat berjalan melewati hutan ajaib, Olaf mulai mengalami fenomena aneh dan keajaiban hutan. Saat dia melakukannya, dia mulai bernyanyi: Ini semua akan masuk akal ketika saya lebih tua Suatu hari nanti saya akan melihat bahwa ini masuk akal Suatu hari, ketika saya sudah tua dan bijak Saya akan berpikir kembali dan menyadari Bahwa ini semua adalah peristiwa yang sepenuhnya normal Saya akan memiliki semua jawaban ketika saya sudah dewasa Lagu ini diakhiri dengan akhir yang meriah dari: Karena saat kamu lebih tua Benar-benar semuanya masuk akal Ini bagus Berhenti. Jika hal-hal tidak masuk akal bagi Anda saat Anda memulai perjalanan cloud, luangkan waktu untuk membuatnya masuk akal. Jika Anda menggunakan pola pikir tangkas, luncurkan lonjakan investigasi pada topik tunggal atau topik yang membingungkan. Misalnya, jika Anda tidak memahami keajaiban konsep VPC, Grup Keamanan, Availability Zone atau Set, Region, atau Region ke Region saat ini, konsep-konsep itu akan semakin tidak masuk akal di kemudian hari ketika Anda kembali ke konfigurasi ini beberapa bulan kemudian. . Jika hasil tes tidak masuk akal, jangan lanjutkan, jalankan lagi. Juga, ingatlah untuk mendokumentasikan arsitekturnya, tidak hanya detail yang menurut Anda penting, tetapi detail yang ingin diketahui oleh Anda yang lebih tua yang telah melewati enam proyek lain dan menghadapi tenggat waktu agar semuanya masuk akal. 3. Jangan lari ke dalam api. Pilih solusi cloud ketersediaan tinggi yang tepat. Setelah bersentuhan dengan roh angin, hutan ajaib dibakar oleh roh api. Saat roh api menyebarkan kekacauan, dan api, Elsa menyerang dengan ledakan es untuk mendinginkan api dan menenangkan roh ini. Dalam semangatnya, Anna berlari ke dalam api di belakang saudara perempuannya dan harus diselamatkan. Ketika akhirnya keduanya bersatu kembali, Elsa menegur adiknya- "Kamu tidak bisa begitu saja mengikutiku ke dalam api". Anna yang bersemangat menjawab, "Kamu tidak ingin aku mengikutimu ke dalam api? Kalau begitu jangan sampai terbakar! " Bermigrasi ke cloud dan memilih solusi ketersediaan yang tepat untuk Anda dapat membuat Anda stres tanpa memperumitnya dengan membuat jadwal yang tidak realistis dengan teori dan skenario yang belum teruji. Tidak ada pemimpin tim penerapan yang menginginkan timnya melakukan latihan kebakaran, jadi jangan sengaja bertemu. Buat rencana. Tetapkan pos pemeriksaan dan pencapaian. Sertakan strategi manajemen risiko dan risiko yang realistis. Berkomunikasi secara sering dengan vendor dan mitra, dan terutama dengan tim Anda. Uji dengan baik, dan pahami rencana pencadangan dan pencadangan. 4. Jangan terjebak di masa lalu: apa yang Anda bawa dalam migrasi cloud. Ada sebuah lagu yang dijalin di sepanjang film, "All is Found" dengan chorus yang dingin – "Selami suaranya / Tapi jangan terlalu jauh atau Anda akan tenggelam". Elsa menyelam ke kedalaman saat puncak film dan pencarian serta penjelajahannya di masa lalu meninggalkannya Beku, napas terakhirnya meledak untuk memperingatkan dan memberi tahu saudara perempuannya. Sebagai salah satu kepala Tim Pengalaman Pelanggan kami di SIOS Technology Corp., saya telah menyaksikan terlalu banyak penerapan dan migrasi terjebak dalam perangkap perbandingan. Kalimatnya seperti ini, "Di pusat data lama kami, kami" atau "Sistem lama dapat melakukannya." Mungkin benar bahwa sistem lama Anda yang terdiri dari sistem tetap, sumber daya khusus, tim besar, jaringan khusus, dan penyimpanan SAN berfitur tinggi dan berbiaya tinggi dapat melakukannya. (Meskipun, sejujurnya, kadang-kadang saya telah melihat tirai terkelupas dan di tempat tidak benar-benar melakukannya). Saat Anda bermigrasi ke cloud, pahami apa yang masuk akal untuk ditiru di cloud dan apa yang tidak. Pahami mengapa sistem dirancang seperti itu di tempat dan menggunakan bantuan, "pelajaran 1, dan pembelajaran pelajaran 2, buat keputusan yang masuk akal. Yang membawa saya ke pelajaran terakhir. 5. Akan selalu ada dua kerajaan: di lokasi dan di cloud. Di akhir film, Anna menjadi ratu Arendelle yang diperintah oleh saudara perempuannya Elsa, sedangkan Elsa tetap tinggal dan memimpin masyarakat di Northuldra. Ada satu yang tinggal di dalam atau dekat hutan yang pernah dikelilingi oleh misteri dan awan, sementara yang lain kembali ke tanah yang sudah dikenal. Saat Anda mempertimbangkan migrasi ke cloud dan strategi Ketersediaan Tinggi Anda, ingatlah akan selalu ada dua kerajaan. Strategi migrasi Anda sebaiknya mengingat bahwa Anda akan selalu membutuhkan pusat data di lokasi untuk bermitra dengan penerapan cloud Anda. Mungkin tidak seluas dulu, tetapi tidak setiap beban kerja atau infrastruktur penting dapat digunakan ulang dan dikemas untuk cloud. Memiliki solusi dan strategi HA yang dapat melengkapi dan memungkinkan kedua "kerajaan" itu penting. Menggunakan cloud membutuhkan tim yang tepat, alat yang tepat dan solusi yang tepat, serta strategi dan rencana untuk mencapainya, tanpa mengalami kesulitan. Saat Anda bermigrasi ke cloud, bersiaplah untuk menghadapi masa lalu, pahami, dan ingat untuk tidak terjebak di sana. Dan, seperti dua saudara perempuan dari Disney's Frozen II, Anda sebaiknya mengingat setiap kisah perusahaan yang indah memiliki dua sisi, di lokasi dan cloud mungkin menjadi milik Anda. – Cassius Rhue, VP, Pengalaman Pelanggan Direproduksi dengan izin dari SIOS
Agustus 2, 2020	Mengapa Pemantauan Aplikasi AWS EC2 Begitu Sulit? Mengapa Pemantauan Aplikasi AWS EC2 Begitu Sulit? Selamat! Anda telah memigrasikan aplikasi inti Anda ke cloud AWS. Atau, Anda sedang mengembangkan aplikasi "cloud-asli" baru dan hosting di cloud. Mungkin Anda memanfaatkan skalabilitas Amazon EC2 dan arsitekturnya yang elastis. Apa pun itu, Anda sekarang ingin memastikan aplikasi itu tetap aktif dan berjalan, atau bahwa Anda diperingatkan dengan cepat jika dan ketika sesuatu terjadi. Karena sesuatu akan terjadi. Data pelanggan kami menunjukkan bahwa perusahaan yang hanya menggunakan tiga instance EC2 mengalami downtime setidaknya sebulan sekali. Itu berarti pengguna yang tidak bahagia tidak dapat mengakses aplikasi mereka. Anda memerlukan solusi pemantauan untuk memberi tahu Anda apa yang sedang terjadi. Cara mempersempit solusi pemantauan aplikasi EC2 Langkah pertama dalam pencarian Anda untuk solusi pemantauan EC2 yang sempurna harus memahami kebutuhan Anda dan kemampuan teknis Anda sendiri. Solusi pemantauan tidak semuanya sama. Apakah Anda tertarik dengan solusi kaya fitur yang memantau beragam sistem? Atau yang berfokus pada serangkaian inti sistem, seperti lingkungan EC2 Anda? Apa yang ingin Anda lakukan dengan output dari solusi pemantauan aplikasi Anda? Apakah Anda ingin sebanyak mungkin informasi membantu pengembang Anda memecahkan masalah? Atau apakah Anda mencari peringatan cepat dan bantuan dalam memulihkan dari kegagalan? Dan apa selera teknis Anda untuk menginstal dan mengelola aplikasi lain? Apakah Anda suka menulis? Atau apakah Anda menginginkan sesuatu yang "set-it-and-forget-it"? Pencarian untuk "solusi pemantauan kinerja aplikasi" di Google menghasilkan 1.170.000.000 hasil! Lompat ke Amazon AWS Marketplace dan Anda akan menemukan 453 produk yang terdaftar di kategori DevOps – Monitoring. Memiliki pemahaman yang jelas tentang persyaratan Anda dan kemampuan teknis Anda sendiri akan membantu Anda mempersempit pencarian Anda. Memantau aplikasi yang berjalan di Amazon EC2 dengan Amazon CloudWatch atau solusi APM lainnya Jika Anda meng-hosting aplikasi Anda di Amazon EC2, maka Anda dapat mempertimbangkan untuk menggunakan Amazon CloudWatch. Seberapa familiar Anda dengan metrik standar dan kustom? Anda harus tahu bahwa Anda memerlukan cukup banyak keahlian teknis untuk menjalankan Amazon CloudWatch dengan benar. Amazon CloudWatch adalah solusi hebat bagi pengguna yang membutuhkan data dan wawasan yang dapat ditindaklanjuti untuk merespons perubahan kinerja di seluruh sistem, mengoptimalkan sumber daya, dan pandangan terpadu tentang kesehatan operasional mereka. Tetapi ini semua datang pada harga dalam hal pengetahuan dan pengalaman yang dibutuhkan untuk mengkonfigurasi dan mengelola Amazon CloudWatch dengan benar. Pilihan lain adalah Anda mengevaluasi dan memperoleh salah satu dari banyak solusi pemantauan kinerja aplikasi ("APM") yang tersedia secara komersial di pasar, seperti dari AppDynamics, Datadog, Dynatrace, atau New Relic. Tetapi perlu diingat kebutuhan Anda. Seberapa luas Anda perlu memonitor? Dan apa yang ingin Anda lakukan dengan informasi itu? Apakah Anda siap kewalahan dengan peringatan? Dan ketahuilah bahwa banyak solusi APM tidak melakukan apa pun untuk membantu Anda pulih tanpa menunjukkan masalah. Anda masih harus meninggalkan semuanya untuk memulai kembali layanan secara manual atau mem-boot ulang instans Anda. Monitor aplikasi yang berjalan di Amazon EC2 menggunakan SIOS AppKeeper Tetapi ada cara lain. SIOS AppKeeper adalah layanan SaaS yang dapat dikonfigurasi untuk secara otomatis menemukan mesin virtual EC2 dan layanan mereka. Kemudian secara otomatis mengambil sejumlah tindakan jika dan ketika downtime dialami. Jadi alih-alih mendapat peringatan bahwa ada sesuatu yang salah, Anda mendapatkan pemberitahuan bahwa sesuatu terjadi dan secara otomatis ditangani. SIOS AppKeeper mulai hanya US $ 40 per instance per bulan. Kami mengundang Anda untuk melihat video singkat ini untuk melihat betapa mudahnya menginstal dan menggunakan AppKeeper. Mengapa Pemantauan Aplikasi AWS EC2 Begitu Sulit? Salah satu pelanggan kami, Hobby Jepang, sebuah perusahaan penerbitan di Tokyo, pada awalnya menggunakan Amazon CloudWatch tetapi tim IT mereka yang kekurangan staf tidak dapat menanggapi dengan cepat peringatan. Mereka ingin meningkatkan otomatisasi dan pindah ke SIOS AppKeeper. Sejak pindah ke AppKeeper mereka tidak mengalami masalah atau downtime yang tidak terduga dengan instance EC2 mereka. Berikut tautan ke studi kasus tentang Hobby Jepang. Memantau aplikasi cloud Anda seharusnya bukan pekerjaan penuh waktu. Anda menginginkan solusi pemantauan yang mudah dipasang dan digunakan, tidak membanjiri Anda dengan peringatan, dan mudah-mudahan menangani gangguan sistem secara otomatis. Kami mendorong Anda untuk mencoba uji coba SIOS AppKeeper gratis selama 14 hari dengan mendaftar di sini.
Juli 30, 2020	Perencanaan adalah Kunci Ketersediaan Perusahaan (dan Menikah dengan Bahagia) Perencanaan adalah Kunci Ketersediaan Perusahaan (dan Menikah dengan Bahagia) Merencanakan tanggal dan liburan, makan malam romantis yang luar biasa adalah bagian yang hebat dari mencintai pasangan Anda dengan baik. Seminar dan lokakarya dipenuhi dengan tips untuk meningkatkan hubungan Anda yang berlimpah di hampir setiap wilayah dunia. Tapi, dengarkan sesi pelatihan yang disediakan oleh SIOS Technology Corp. Manajer Proyek untuk Layanan Profesional, Edmond Melkomian, dan Anda akan segera mengetahui bahwa merencanakan makan malam dan retret ulang tahun bukan satu-satunya cara untuk mencintai pasangan Anda dengan baik. Di kelas baru-baru ini di SIOS Protection Suite untuk Linux, Edmond membagikan tiga tips yang membantu Anda mencintai pasangan Anda dengan baik di dunia perusahaan: paket, paket, paket. 1. “Rencanakan untuk merencanakan” solusi ketersediaan perusahaan Anda Dalam kursusnya, Edmond Melkomian meminta siswa untuk menyebutkan hal pertama yang harus Anda lakukan ketika menggunakan solusi perusahaan. Jawabannya, "Rencanakan, rencanakan, rencanakan." Tampaknya sudah jelas, tetapi langkah pertama adalah mulai membuat rencana. Sebuah permulaan yang lumayan layak untuk sebuah rencana meliputi pengembangan rincian untuk setiap fase proyek, seperti tonggak sejarah, pos pemeriksaan, risiko, mitigasi risiko dan strategi, pemangku kepentingan, jadwal, rencana komunikasi pemangku kepentingan. Rencana yang layak juga akan mencakup perincian tentang kickoff, sign-off dan penutupan, dan sumber daya (kepegawaian, manajemen, hukum / kontrak). Rencanakan untuk membuat, meninjau, memodifikasi, dan memperbarui rencana Anda sepanjang siklus hidup solusi. 2. Rencanakan apa yang akan digunakan untuk ketersediaan perusahaan Rencanakan apa yang akan digunakan. Sangat mungkin bahwa sebagian besar infrastruktur perusahaan Anda ada di luar ranah masa hidup tim saat ini dengan perusahaan Anda. Ketika Anda bermigrasi ke cloud, atau memperbarui strategi ketersediaan Anda, perlu waktu dan upaya untuk membuat rencana mengenai apa yang akan digunakan. Fokuskan rencana Anda untuk memastikan bahwa Anda menggunakan redundansi di semua komponen penting, jaringan, komputasi, penyimpanan, daya, pendinginan, dan aplikasi. Semua pusat data dan penyedia cloud biasanya memastikan pendinginan, daya, dan redundansi jaringan untuk memulai. Sejumlah perusahaan menawarkan tim arsitektur, penyedia solusi cloud, pakar ketersediaan, arsitek aplikasi, dan spesialis migrasi yang membantu tim menemukan ketergantungan kritis dan terkadang tersembunyi serta area berisiko tinggi yang rentan terhadap Single Points of Failure (SPOF's). Pekerjaan investigasi ini akan menjadi masukan bagi rencana Anda tentang apa yang akan digunakan dan / atau diperbarui dalam strategi ketersediaan Anda. Berencana meninjau apa yang perlu Anda gunakan. 3. Berencana untuk menjaga QA / klaster pra-produksi untuk ketersediaan yang andal Ketika saya berada di tim pengembangan SIOS Technology Corp., saya tidak akan pernah melupakan panggilan Jumat malam dengan waktu yang lama, tetapi pelanggan yang panik. Awal bulan ini, seorang pelanggan yang sering tidak berhasil menyebarkan solusi perangkat lunak baru ke dalam lingkungan produksi. Hasilnya adalah kegagalan besar. Dia menelepon nomor 800 kami pada jam 4:30 sore (EST) pada hari Jumat. Mengapa saya mengingat waktu yang tepat itu? Jumat adalah malam kencan. Saya dan istri saya punya rencana makan malam, pengasuh untuk enam gadis yang siaga (setiap jam), dan berharap untuk malam yang romantis dan santai. Saya baru saja akan keluar untuk hari ketika telepon berdering. Setelah jam pertama yang menegangkan, kami kembali berdiri dan berlari. Episode malang ini bisa dihindari atau dikurangi dengan menjaga sistem UAT atau QA. Sebagai Harrison Howell, Insinyur Perangkat Lunak untuk Pengalaman Pelanggan di SIOS Technology Corp mencatat dalam blog-nya-6-common-cloud-migrasi-tantangan batas on-prem tidak lagi batas yang sama. Pelanggan yang datang dari sistem on-prem perlu mengingat bahwa sumber daya tidak lagi menjadi faktor pembatas. Di cloud, sistem dapat dengan mudah disalin dan dijalankan dalam isolasi produksi, sesuatu yang tidak sepele di tempat. Akses on-demand ke sumber daya TI memungkinkan UAT HA dan DR berkembang melampaui “shutdown the primary node”. Jaringan dapat disabotase, kernel bisa panik, bahkan basis data pun bisa rusak dan semua ini tidak akan memengaruhi produksi! Identifikasi dan pengujian skenario ini meningkatkan postur HA dan DR. Berencana untuk menggunakan dan menyimpan sistem UAT untuk pengujian HA dan DR. Seperti yang disebutkan Harrison, "mengidentifikasi dan[issues] menguji" "men[your overall]ingkatkan postur HA dan DR," dan itu meningkatkan peluang Anda untuk kencan malam yang sukses. 4. Rencanakan pemeliharaan dan pembaruan rutin (termasuk dokumentasi) Terakhir, rencanakan waktu untuk pemeliharaan rutin dan pembaruan untuk mempertahankan Ketersediaan Perusahaan. Perusahaan Anda harus tetap tersedia agar tetap sangat menguntungkan dan sukses. Lingkungan tidak tetap stagnan, dan tambalan, pembaruan keamanan, ekspansi, dan pemeliharaan umum adalah kejadian biasa dari awal hingga pensiun. Membuat rencana untuk bagaimana dan kapan Anda akan memasukkan pembaruan dan pemeliharaan ke perusahaan Anda akan memastikan bahwa Anda tidak hanya terus mendapatkan informasi terkini, tetapi Anda meminimalkan risiko dan downtime saat melakukannya. Pastikan untuk memasukkan dalam rencana Anda penggunaan sistem uji. Kembangkan rutinitas dan proses terencana untuk memvalidasi tambalan, pembaruan kernel dan OS, dan perangkat lunak keamanan, dan jangan lupa untuk memperbarui dokumentasi proyek dan rencana masa depan saat Anda tumbuh dan berkembang. Jika Anda ingat untuk merencanakan dimuka sistem yang sangat redundan, sangat andal, dan sangat tersedia, rencanakan untuk menjaga QA / pra-produksi cluster setelah Go-Live, dan rencanakan untuk pemeliharaan dan pembaruan rutin Anda juga akan dapat menjaga rencana Anda dengan pasangan Anda untuk kencan malam. Dan tidak hanya berkencan malam, tetapi Anda juga dapat menjaga malam Anda bebas dari panggilan bangun jam 3 pagi karena sistem produksi yang buruk. Ini tip saya untuk mencintai pasangan Anda dengan baik. Saya mencintai istri saya dan karenanya saya membantu pelanggan menyebarkan DataKeeper Cluster Edition SIOS Technology Corp. dan SIOS Protection Suite untuk produk Windows dan Linux sebagai bagian dari solusi perlindungan perusahaan yang sangat tersedia. Hubungi SIOS. – Cassius Rhue, VP, Pengalaman Pelanggan Artikel direproduksi dengan izin dari SIOS
Juli 22, 2020	Cara Menggabungkan Pencadangan, Replikasi, dan Clustering Ketersediaan Tinggi Cara Menggabungkan Pencadangan, Replikasi, dan Clustering Ketersediaan Tinggi Pencadangan, replikasi, dan ketersediaan tinggi (HA) adalah bagian mendasar dari manajemen risiko TI, dan mereka sangat diperlukan seperti roda pada mobil. Replikasi juga penting untuk perlindungan data TI. Lingkungan Cadangan dan HA Cluster Tidak Saling Eksklusif Sementara cadangan, replikasi, dan failover semuanya penting, ada perbedaan utama di antara mereka yang perlu dipahami untuk memastikan mereka diterapkan dengan benar. Misalnya, saat Anda dapat menggunakan replikasi untuk mempertahankan salinan data yang terus-menerus diperbarui, tanpa mempertimbangkannya di lingkungan perlindungan data yang lebih besar, Anda juga akan menyalin data masalah (seperti data yang terinfeksi virus). Dalam kasus seperti itu, cadangan sangat penting untuk mengembalikan data ke poin baik terakhir yang diketahui. Dengan melakukan replikasi, Anda dapat mengakses gambar yang direplikasi segera sebelum kegagalan sistem (= RTO / RTO lebih unggul) dengan cara yang hanya menyimpan data berdasarkan generasi dan mendukungnya dalam model tipe eDiscovery tidak bisa. Oleh karena itu, SIOS Protection Suite mencakup perangkat lunak pengelompokan SIOS LifeKeeper dan perangkat lunak replikasi DataKeeper. SIOS LifeKeeper adalah produk cluster failover HA yang memantau kesehatan aplikasi dan mengatur failover aplikasi dan DataKeeper adalah perangkat lunak replikasi penyimpanan berbasis blok. Namun, hanya karena itu adalah cluster HA tidak berarti cadangan tidak diperlukan. Pertimbangkan tindakan pencegahan dan poin yang perlu diperhatikan saat mencadangkan di lingkungan HA cluster menggunakan SIOS Protection Suite. Lima Poin Cadangan di Lingkungan Clustering Ketersediaan Tinggi Pertimbangkan lima poin berikut sebagai target perolehan cadangan: Sistem Operasi (OS) SIOS Protection Suite – Program Clustering Software LifeKeeper / DataKeeper SIOS Protection Suite – informasi konfigurasi LifeKeeper / DataKeeper Program aplikasi (mis., SQL Server, SAP S / 4 HANA, Oracle, PostgreSQL, dll.) Data aplikasi Cadangkan OS Untuk mencadangkan OS, biasanya digunakan utilitas OS standar atau perangkat lunak cadangan pihak ketiga. Namun, karena tidak ada pertimbangan khusus untuk lingkungan ketersediaan tinggi, kami tidak akan membahasnya di sini. Cadangkan Perangkat Lunak Clustering SIOS Protection Suite SIOS Protection Suite termasuk program SIOS LifeKeeper / DataKeeper juga dapat diperoleh dengan utilitas standar OS atau perangkat lunak cadangan pihak ketiga, tetapi jika program menghilang karena kegagalan disk, dll. tanpa sengaja mencadangkannya, Anda perlu menginstalnya kembali. Mungkin akan ada beberapa orang yang berpikir tentang dikotomi melakukannya. Cadangkan Informasi Konfigurasi SIOS Protection Suite SIOS LifeKeeper hadir dengan perintah sederhana bernama lkbackup yang memungkinkan Anda membuat cadangan informasi konfigurasi. lkbackup dapat dijalankan pada SIOS LifeKeeper dan sumber daya terkait dan tidak akan memengaruhi layanan yang berjalan. Perintah ini dapat dieksekusi dalam tiga kasus utama berikut. Segera setelah menginstal sumber daya SIOS LifeKeeper yang baru dibuat Sebelum dan sesudah mengubah konfigurasi SIOS LifeKeeper (menambah / mengubah dependensi, menambah / menghapus sumber daya) Sebelum dan sesudah pemutakhiran versi SIOS LifeKeeper Jika Anda mencadangkan informasi konfigurasi dengan lkbackup, bahkan jika informasi konfigurasi hilang karena kegagalan disk atau jika informasi konfigurasi rusak karena kesalahan operasi, dll.) Anda dapat dengan cepat kembali ke keadaan operasional semula. Program Operasional Cadangan Meskipun mencadangkan program operasi mengacu pada mencadangkan aplikasi bisnis yang dilindungi di HA cluster Anda, dimungkinkan untuk membuat dan memulihkan gambar cadangan menggunakan utilitas standar OS atau perangkat lunak cadangan pihak ketiga seperti pada 1. dan 2 di atas. Cadangkan Data Aplikasi Bisnis Di lingkungan HA cluster, penyimpanan bersama yang dapat diakses oleh server aktif dan siaga disediakan. Selama operasi normal, penyimpanan bersama digunakan oleh node cluster aktif. Data aplikasi (misalnya, data basis data) biasanya penyimpanan dalam penyimpanan bersama ini, tetapi poin-poin berikut harus diingat ketika membuat cadangan penyimpanan ini. Untuk konfigurasi penyimpanan bersama Saat memperoleh cadangan data yang terletak di konfigurasi kluster SANless dengan penyimpanan yang dibagikan oleh node kluster aktif dan sistem siaga, data hanya dapat diakses dari sistem aktif (sistem siaga tidak dapat mengakses data). Akibatnya, cadangannya juga aktif. Dalam hal ini, pastikan bahwa ada kekuatan pemrosesan yang cukup untuk menangani skenario failover dan cadangan pemulihan. Untuk konfigurasi replikasi data Dalam hal konfigurasi replikasi data, cadangan dari sistem operasi adalah dasar, tetapi dengan menghentikan sementara mirroring dan melepaskan kunci, cadangan juga dapat dieksekusi di sisi sistem siaga. Namun, dalam hal ini, data sementara tidak sinkron. Mencadangkan simpul cluster dari server cadangan eksternal Untuk melakukan cadangan node cluster dari server backup eksternal, gunakan alamat IP virtual atau nyata dari node cluster. Poin yang perlu diperhatikan dalam setiap kasus adalah sebagai berikut. Mencadangkan menggunakan alamat IP virtual node cluster Dari perspektif server cadangan, cadangan dieksekusi ke node yang ditunjukkan oleh alamat IP virtual LifeKeeper. Dalam hal ini, server cadangan tidak perlu mengetahui simpul mana yang merupakan simpul aktif. Mencadangkan menggunakan alamat IP asli dari node cluster Dari perspektif server cadangan, cadangan dilakukan ke alamat IP asli tanpa menggunakan alamat IP virtual LifeKeeper. Karena penyimpanan bersama tidak dapat diakses dari node cluster siaga, server cadangan dan klien harus memeriksa node mana yang merupakan node aktif. Menggabungkan cadangan, replikasi, dan failover clustering dalam cadangan konfigurasi yang teruji dan diverifikasi sangat diperlukan. Menggunakan melakukan verifikasi operasi yang memadai terlebih dahulu di sisi pengguna. Direproduksi dengan izin dari SIOS
Juli 18, 2020	Perangkat Lunak Ketersediaan Tinggi adalah Asuransi Terhadap Downtime SAP Perangkat Lunak Ketersediaan Tinggi adalah Asuransi Terhadap Downtime SAP Kita semua perlu membeli asuransi – untuk mobil kita, rumah kita, hidup kita. Tidak ada yang suka membayar uang untuk layanan yang kami harap tidak perlu digunakan. Tetapi kita semua tahu bahwa kita harus memilikinya untuk berjaga-jaga. Kebanyakan orang menunda asuransi sampai sesuatu yang buruk terjadi, membeli yang termurah, atau benar-benar melakukan pekerjaan rumah mereka dan membelinya dari seseorang yang mereka percayai. Grup terakhir ini biasanya memberikan harga terbaik. Perangkat Lunak Ketersediaan Tinggi adalah Asuransi Terhadap Downtime Asuransi sering kali untuk konsumen, tetapi juga penting untuk bisnis. Anda memiliki sistem komputer dan aplikasi yang menjalankan bisnis Anda. Jika mereka gagal karena suatu alasan, Anda ingin bisnis Anda terus berjalan atau bisa menghabiskan jutaan dolar dalam bisnis yang hilang melalui transaksi dan data pelanggan yang hilang, dan kerusakan yang tidak dapat diperbaiki terhadap reputasi Anda dengan pelanggan Anda. Perangkat lunak ketersediaan tinggi adalah "asuransi" Anda terhadap gangguan sistem. Ini bukan sesuatu yang bisa Anda abaikan. Ini bukan sesuatu yang dapat Anda percayai yang akan datang bersama dengan infrastruktur perangkat keras atau perangkat lunak Anda. Anda ingin menggunakan solusi ketersediaan tinggi dari perusahaan yang memiliki keahlian puluhan tahun dalam ketersediaan tinggi dan tahu bagaimana menjaga sistem Anda tetap berjalan dan berjalan. Perusahaan perangkat lunak ketersediaan tinggi tepercaya harus: Memberikan solusi tunggal yaitu platform agnostik – dapat digunakan di tempat, di cloud, dan di semua platform perangkat keras dan lunak Anda Memiliki produk yang mudah dikonfigurasikan dan dipasang tanpa memiliki keahlian aplikasi yang cukup Ketahui aplikasi Anda dan kapan aplikasi Anda mengalami masalah Ambil tindakan yang tepat untuk mencoba me-restart atau gagal aplikasi Gagal aplikasi ke server sekunder, mempertahankan praktik terbaik aplikasi, dan membawa aplikasi kembali dalam urutan yang tepat Salah satu aplikasi utama yang digunakan dalam perusahaan saat ini adalah SAP S / 4HANA, berdasarkan pada basis data dalam memori HANA. Sebagian besar pelanggan SAP akan diminta untuk menjalankan database HANA dengan SAP pada tahun 2025. Anda ingin menemukan solusi ketersediaan HANA cerdas dari perusahaan yang mengetahui ketersediaan tinggi, yang tahu SAP, tahu HANA, dan tahu apa yang harus dilakukan untuk memastikan bahwa aplikasi SAP penting Anda, dan bisnis Anda, terus berjalan dengan lancar. SIOS Technology adalah perusahaan yang dapat Anda percayai untuk Perangkat Lunak Ketersediaan Tinggi yang andal. Rilis produk LifeKeeper untuk Linux 9,5 berisi Kit Pemulihan Aplikasi HANA yang baru. Ini akan memberi Anda semua yang Anda butuhkan untuk menjaga lingkungan SAP dan HANA Anda berjalan. Ingin informasi lebih lanjut tentang rilis ini? Tonton wawancara ini. Direproduksi dengan izin dari SIOS