Hitachi Memindahkan Sistem Kritis Misi Perusahaan Asuransi Terkemuka ke Azure Memastikan Ketersediaan Tinggi

SIOS DataKeeper dipilih karena kemampuannya mengaktifkan replikasi data di Azure

Sebuah perusahaan asuransi besar ingin memigrasikan sistem mission-critical-nya yang disebut ‘channel system’ ke cloud. Sistem saluran mencakup sistem in-house, yang digunakan oleh karyawan dan pusat panggilannya, dan sistem pihak ketiga yang digunakan oleh agen penjualannya. Sistem diposisikan sebagai sistem inti dari bisnis perusahaan – bahkan kegagalan sistem dan downtime yang singkat akan berdampak besar pada bisnis.

Sistem saluran dioperasikan di platform virtual lokal yang disediakan oleh Hitachi. Namun, perangkat kerasnya menua dan dukungan untuk middleware telah berakhir. Hal ini menyebabkan perusahaan asuransi meluncurkan proyek untuk memperbarui infrastruktur dan memindahkan sistem ke cloud publik untuk memangkas biaya operasional. Hitachi mengambil tanggung jawab untuk mengonfigurasi sistem untuk proyek ini.

Lingkungan

Arsitektur sistem saluran sebagian besar terdiri dari perangkat lunak Windows. “Kami memutuskan untuk mengadopsi Azure sebagai platform cloud karena kami dapat memastikan bahwa ada kedekatan yang tinggi antara arsitektur sistem dan Microsoft Azure, dan ini akan menjadi opsi yang paling hemat biaya. Ada beberapa hal yang tidak dapat diubah, tetapi kami fokus untuk menempatkan prioritas pertama pada kebutuhan pelanggan,” ujar Takuro Nishino, System Engineer di Hitachi.

Tantangan

Salah satu persyaratan perusahaan untuk infrastruktur baru adalah membangun konfigurasi cluster. Selain itu, database, yang dibangun dengan konfigurasi cluster menggunakan DBMS, bersama dengan middleware manajemen pekerjaan ‘JP1’ harus dikonfigurasi dalam node cluster untuk mengamankan ketersediaan tinggi (HA) bahkan setelah migrasi cloud. Sistem yang ada menggunakan WSFC (Windows Server Failover Clustering) untuk mengonfigurasi cluster HA menggunakan fungsi Windows Server dengan penyimpanan bersama (SAN).

Namun, pada 2019, tidak mungkin memiliki konfigurasi berbasis SAN di Azure. Mengubah perangkat lunak HA dianggap sebagai opsi, tetapi, “Mengingat dampaknya pada sistem, prioritasnya adalah memindahkan sistem ke cloud sambil mempertahankan arsitektur aplikasi dan infrastruktur sebanyak mungkin.” kata Nishino. Hitachi memutuskan untuk mencari solusi yang akan mempertahankan konfigurasi klaster WSFC dan mereplikasi data tanpa SAN, sambil menggunakan perangkat lunak HA yang sama.

Evaluasi

Setelah beberapa penelitian, Hitachi menemukan SIOS DataKeeper, perangkat lunak replikasi data yang dapat membangun cluster dan berintegrasi dengan WSFC di Azure. DataKeeper adalah produk bersertifikasi Azure, yang memungkinkan Anda mereplikasi data secara sinkron dari node aktif ke node siaga. Dengan menggunakan DataKeeper dengan WSFC, perusahaan dapat membuat JP1 menjadi berlebihan. Hitachi juga secara resmi mendukung dan berpengalaman dengan konfigurasi ini. “DataKeeper adalah satu-satunya solusi yang membuat proyek kami layak – bermigrasi ke cloud sambil mempertahankan konfigurasi kluster, tanpa mengubah perangkat lunak HA,” kenang Nishino.

Bersama dengan Hitachi, Hitachi Solutions, yang memiliki rekam jejak penerapan DataKeeper, ikut serta dalam proyek ini dengan membuat dokumen desain terperinci dan manual prosedur konstruksi. Pekerjaan aktual penerapan DataKeeper dilakukan oleh anggota departemen TI perusahaan Asuransi.

Solusinya

Hitachi Solutions membuat desain dasar dan desain terperinci setelah menentukan persyaratan, dan juga menyediakan template untuk memudahkan perusahaan asuransi menerapkan sistem tersebut. Selama proses ini, berkat fitur DataKeeper yang mudah dipahami seperti pengaturan parameter. Hitachi Solutions dapat membuat manual prosedur tanpa kesulitan hanya dengan menyesuaikan nilai default agar sesuai dengan lingkungan pelanggan. Hitachi Solutions juga membuat lingkungan pengujian DataKeeper dalam lingkungan lokalnya sendiri untuk mengidentifikasi masalah apa pun sebelumnya – proses ini membantu mereka membuat manual prosedur yang akurat dan mengonfigurasi lingkungan produksi dengan lancar.

Hasil

Pada Oktober 2022, migrasi sistem perusahaan asuransi ke Azure telah selesai. Sejak migrasi, konfigurasi klaster HA – DataKeeper dan WSFC – telah beroperasi dengan mantap. Perusahaan setuju bahwa mencapai konfigurasi klaster HA dengan cara ini, tanpa mengubah arsitektur sistem atau perangkat lunak HA, adalah cara terbaik untuk memigrasikan sistem ke Azure.

Hitachi dan Hitachi Solutions berhasil dalam proyek migrasi cloud perusahaan asuransi dengan mengintegrasikan DataKeeper dalam konfigurasi cluster HA. “Fakta bahwa kami dapat memperkenalkan DataKeeper dalam proyek pelanggan kami merupakan pencapaian yang luar biasa. Kami juga ingin menerapkan pengetahuan dan pencapaian yang kami peroleh dari proyek ini di proyek Azure lainnya,” kata Kenta Otsuka, Penjualan di Hitachi. “Faktanya, kami telah mengusulkan DataKeeper ke klien lain yang juga sedang mempertimbangkan migrasi sistem mereka ke Azure. Pengalaman bekerja dengan SIOS Technology melalui Hitachi Solutions dan keterampilan serta pengetahuan yang kami peroleh pasti akan berkontribusi pada bisnis kami di masa depan.”

“Saat proyek dimulai, Azure tidak memiliki fungsi disk bersama, jadi DataKeeper adalah satu-satunya pilihan. Meskipun konfigurasi berbasis SAN saat ini tersedia di Azure, berdasarkan fakta bahwa kami dapat mencapai migrasi yang lancar dan operasi yang stabil dalam proyek ini dengan mengimplementasikan DataKeeper, DataKeeper akan terus menjadi solusi saat redundansi diperlukan dalam migrasi Azure dan proyek konfigurasi,” kata Satoshi Noguchi, Insinyur Sistem di Hitachi.

Unduh studi kasusDi Sini

Direproduksi dengan izin dariSIOS

Buku Putih: Ketersediaan Tinggi untuk Aplikasi Penting Bisnis

Sebagian besar organisasi saat ini mengandalkan database dan aplikasi bisnis penting, seperti perencanaan sumber daya perusahaan (ERP), gudang data, aplikasi e-niaga, manajemen hubungan pelanggan (CRM), sistem keuangan, manajemen rantai pasokan, dan sistem intelijen bisnis. Saat sistem, database, atau aplikasi gagal, organisasi ini memerlukan perlindungan ketersediaan tinggi untuk menjaga sistem tetap aktif dan berjalan serta meminimalkan risiko hilangnya pendapatan, karyawan yang tidak produktif, dan pelanggan yang tidak bahagia.

Panduan ini menjelaskan mengapa penting untuk memastikan aplikasi bisnis penting Anda sangat tersedia, mengeksplorasi tantangan teknis yang terkait dengan berbagai strategi ketersediaan tinggi, menjelaskan tantangan khusus industri, dan menjelaskan bagaimana lingkungan multi-cloud menambah tantangan dan peluang baru untuk ketersediaan tinggi.

UnduhDi Sini

Direproduksi dengan izin dariSIOS

Webinar: Sehari dalam Kehidupan Arsitek Teknis SAP dan masa depan Pusat Data

Mendaftar untuk Webinar Sesuai Permintaan

Sistem SAP ERP menjalankan beberapa operasi bisnis penting mulai dari lini produksi hingga penjualan, distribusi, keuangan, dan banyak lagi. Secara alami, ketergantungan pada uptime di dunia digital yang sedang berkembang saat ini menjadi lebih besar. Bagaimana sebuah organisasi mengembangkan, merancang, dan mengimplementasikan solusi SAP yang sangat tersedia? Bergabunglah dengan Bobby Jagdev, saat dia memandu peserta melalui hari-hari biasa dalam merancang solusi bersama pelanggan. Dari membentuk persyaratan hingga desain solusi, pemilihan produk, dan akhirnya membantu menyusun arsitektur end-to-end. Dalam sesi ini, Bobby juga akan membahas bagaimana masa depan pusat data akan berkembang, dan seberapa penting Ketersediaan Tinggi bagi solusi pusat data di masa depan.

Mendaftar untuk Webinar Sesuai Permintaan

Tahukah Anda bahwa ada beberapa faktor yang memengaruhi performa, biaya, dan ketersediaan beban kerja Anda? Tidak ada pendekatan satu ukuran untuk semua saat menjalankan beban kerja SQL Server Anda di cloud, dan Anda mungkin tidak perlu memutakhirkan. Bergabunglah dengan sesi ini untuk mempelajari tentang strategi meregangkan dana anggaran TI Anda sambil mengoptimalkan kinerja database Anda di AWS.

Direproduksi dengan izin dariSIOS

Sepuluh Pertanyaan untuk Dipertimbangkan untuk Pemeliharaan Klaster Ketersediaan Tinggi yang Lebih Baik

Pemeliharaan adalah bagian dari siklus hidup setiap perusahaan. Setiap infrastruktur terus bergerak dan berubah, bahkan yang bergerak menuju akhir kehidupan. Tim Anda kemungkinan besar telah berhasil melakukan apa yang telah Anda lakukan di masa lalu, tetapi karena sistem menjadi lebih rumit dan kompleks, apa yang Anda anggap sukses di masa lalu mungkin perlu disegarkan. Berikut adalah sepuluh pertanyaan untuk diperbaikipemeliharaan klaster, maksimalkanketersediaan tinggi, dan meminimalkan downtime.

Cara Memastikan Ketersediaan Tinggi Selama Pemeliharaan Sistem

1. Apa hari terbaik bagi pemangku kepentingan bisnis?

Berbeda dari downtime yang tidak direncanakan, ini adalah jendela di mana banyak tim, sistem, dan sumber daya yang saling terhubung tidak tersedia untuk aktivitas yang direncanakan. Misalnya, satu perusahaan diharuskan melakukan pemeriksaan kepatuhan sistem bulanan dan inspeksi keselamatan. Selama ini, operasi bisnis ditutup oleh inspektur, auditor, dan sejenisnya.

2. Apa tanggal terbaik bagi tim untuk menjadwalkan pemeliharaan?

Sebagai VP Pengalaman Pelanggan, kami telah bekerja sama dengan sejumlah tim yang memiliki tanggal pengecualian untuk acara dan aktivitas tertentu. Tim Anda mungkin bertanggung jawab atas lebih dari satu set sistem dan server, dan melapor ke beberapa tim dengan aplikasi dan infrastruktur penting. Memahami hari mana yang terbaik untuk tim membantu Anda menghindari gangguan, konflik, dan waktu yang hilang karena kendala sumber daya yang diketahui.

3. Tanggal dan waktu apa yang paling cocok dengan mitra, konsultan, dan kontraktor non-perusahaan?

Infrastruktur kritis biasanya mencakup banyak penyedia dan vendor lain yang tidak terkait langsung dengan staf perusahaan. Sumber daya ini mencakup vendor dan konsultan OS, keamanan dan HA, serta arsitek dari penyedia infrastruktur dan mitra lainnya. Memahami sebelumnya hari apa yang terbaik atau termasuk dalam tingkatan dukungan Anda sangat penting untuk penjadwalan dan penempatan staf yang tepat.

Dengan bertambahnya tim global, menemukan waktu yang tepat untuk semua sumber daya ini adalah pertanyaan lain yang penting untuk dijawab. Kapan waktu terbaik untuk sumber daya di EST, IST, EMEA, dan wilayah lainnya?

4. Apa ruang lingkup pemeliharaan yang dimaksud? Apa hasil yang diinginkan dari kegiatan pemeliharaan? Berpikir secara holistik.

Pikirkan di luar pemeliharaan sederhana aplikasi untuk menyertakan seluruh lingkungan tempatnya berjalan. Baru-baru ini, seorang pelanggan yang berencana untuk memutakhirkan aplikasi mereka memutuskan untuk memutakhirkan OS mereka pada saat yang bersamaan. Sayangnya, perubahan kecil dalam ruang lingkup ini membawa konsekuensi yang lebih besar dari yang diharapkan. Aplikasi mereka tidak mendukung OS yang baru ditingkatkan dan masalah pun terjadi. Pastikan bahwa cakupan periode pemeliharaan ditentukan dengan baik dan hasil untuk cakupan tersebut dirinci. Tidaklah cukup untuk mengatakan, lingkungan bekerja. Detailkan versi yang diharapkan, perilaku, dan hasil terukur jika memungkinkan. Lihat lebih lanjut tentangKetahanan TI.

5. Berapa lama waktu untuk jendela pemeliharaan (diantisipasi, diizinkan)?

Idealnya kita semua ingin memiliki semua waktu untuk melakukan pemeliharaan, tetapi memiliki pelanggan yang berlokasi di seluruh dunia berarti hanya ada sedikit toleransi untuk jendela waktu henti yang direncanakan – bahkan untuk tugas-tugas penting. Saat Anda merencanakan pemeliharaan, berapa lama waktu henti yang diantisipasi? Bisakah Anda secara realistis memenuhi jendela maksimum yang diizinkan? Jika tidak, maka Anda perlu merencanakan ulang acara pemeliharaan.

6. Apa rencana pengembaliannya?

Meskipun kami berharap tidak ada yang salah, kami harus menyadari bahwa kami berurusan dengan perangkat lunak, lingkungan dan konfigurasi yang rumit, dan banyak bagian bergerak yang ditangani oleh banyak tim. Rencana rollback – yaitu, cara mengembalikan sistem ke versi dan pengaturan pra-pemeliharaan – sangat penting. Pastikan jika terjadi kesalahan, Anda memiliki rencana pengembalian, misalnya pencadangan penuh atau citra mesin. Lihat lebih lanjut tentangpemulihan bencana.

7. Siapa anggota tim individu yang terlibat, apa peran dan tanggung jawab mereka? Apakah semua peran dan tanggung jawab yang diperlukan didefinisikan dengan jelas?

Sebagai VP Pengalaman Pelanggan, tim kami terlibat dalam aktivitas pemeliharaan yang mengalami penundaan tak terduga karena anggota tim utama tidak hadir. Saat Anda menyusun rencana dan arsitektur, pastikan untuk mengidentifikasi anggota tim serta peran dan tanggung jawab TI yang diperlukan. Seperti yang diingatkan oleh Sr. Support Engineer Greg Tucker kepada pelanggan, HA menyentuh setiap lapisan lingkungan Anda termasuk penyimpanan, jaringan, komputasi, OS, keamanan, kebijakan, dll.

8. Di mana rencana pemeliharaan didokumentasikan? Kapan terakhir kali rencana ditinjau, diperbarui, dan diuji?

Sukses itu luar biasa, tetapi juga bisa membuat Anda terlena atau nyaman. Setelah bertahun-tahun sukses, proses Anda mungkin tidak lagi didokumentasikan dengan baik atau diikuti secara aktif. Menjawab pertanyaan-pertanyaan ini dapat memastikan tim Anda terus sukses.

9. Masalah apa yang diselesaikan dalam pengujian/QA sebelum rencana produksi?

Kudos untuk terus menguji langkah-langkah pemeliharaan. Pastikan bahwa masalah yang diselesaikan di lingkungan pengujian ditambahkan dengan benar ke rencana pemeliharaan produksi. Tim Kesuksesan Pelanggan SIOS telah melihat pelanggan melakukan pengujian QA, mengungkap asumsi yang salah, dan melakukan koreksi yang diperlukan, tetapi gagal menempatkan koreksi tersebut dalam daftar periksa produksi mereka.

10. Siapa atau apa yang hilang dari rencana Anda?

Sekarang setelah Anda melihat rencana, waktu, tim, peran, dan arsitektur, satu pertanyaan terakhir tersisa: siapa atau apa yang hilang? Sebagai langkah terakhir, periksa rencana Anda dan ajukan pertanyaan: “Siapa yang hilang dari rencana kita?” Juga, pertimbangkan untuk menanyakan “Apa yang kurang dari rencana kita?” Sebagai Wakil Presiden Pengalaman Pelanggan, saya telah bekerja dengan tim kami untuk meninjau rencana aktivitas untuk banyak pelanggan. Salah satu tinjauan rencana pemeliharaan yang paling berkesan mengungkap serangkaian langkah dalam rencana rollback yang mencakup pemulihan server dari gambar yang dikloning dan data dari cadangan. Namun, langkah kloning gambar dan pencadangan data tidak disertakan dalam daftar tugas. Mereka telah diabaikan dan dianggap telah dilakukan lebih awal dalam proses.

Pemeliharaan Sistem adalah Elemen Penting untuk Mempertahankan Ketersediaan Tinggi

Pemeliharaan sistem adalah bagian penting dan perlu dari pemeliharaan sistem komputer. Pemeliharaan dapat dilakukan untuk memperbaiki kesalahan, memperkenalkan fungsionalitas perangkat lunak baru, atau mengadaptasi sistem ke kasus penggunaan baru. Ketika sistem yang dimaksud adalah sistem kritis bisnis yang penting bagi organisasi untuk mempertahankan kelangsungan bisnis, memiliki rencana yang dipikirkan matang-matang sangatlah penting. Pertimbangkan sepuluh pertanyaan ini dan pertanyaan Anda sendiri untuk memastikan bahwa pemeliharaan Anda memenuhi kebutuhan bisnis tanpa risiko atau penundaan yang tidak perlu.

Hubungi SIOShari ini untuk Solusi Ketersediaan Tinggi dan Pemulihan Bencana.

Direproduksi dengan izin dariSIOS