SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

November 20, 2022

Hari-hari sederhana HA & DR telah berlalu

Hari-hari sederhana HA & DR telah berlalu

Membolak-balik saluran TV, saya tersandung pada adegan dalam film "He's Just Not That Into You" dengan Drew Barrymore, mengatakan apa yang sebagian besar dari kita rasakan di tahun 2022 tentang Teknologi dan terutama ketersediaan tinggi dan pemulihan bencana: "Saya merindukan hari-hari ketika Anda memiliki satu nomor telepon dan satu mesin penjawab dan satu mesin penjawab itu memiliki satu kaset dan satu kaset itu memiliki pesan dari seorang pria atau tidak. Dan sekarang Anda hanya perlu berkeliling memeriksa semua portal berbeda ini hanya untuk ditolak oleh tujuh teknologi berbeda. Ini melelahkan.” Terkadang, tidakkah Anda berharap hanya ada satu cloud atau bahkan mungkin tidak ada platform cloud; satu DB berjalan di satu OS; dan hanya aplikasi ujung depan yang perlu dikhawatirkan. Tapi, dunia telah berubah dan bergerak lebih cepat, dan menjadi lebih rumit.Kemajuan teknologi, dampak dari merger dan akuisisi, serta meningkatnya selera dan kecepatan masyarakat kita selama 24/7, dengan miliaran konsumen yang mencari kesepakatan terbaru dan pengalaman terbaik, berarti hari-hari sederhana telah berlalu.

4 kebenaran keras tentang ketersediaan Anda

  1. Solusi Anda tidak sesederhana yang Anda pikirkan

Tentu saja lingkungan perusahaan Anda tidak sederhana.Anda memiliki sistem dan aplikasi lawas, jenis yang sudah ada hampir sejak kartu berlubang.Anda memiliki sistem baru, dibuat untuk aplikasi dan database generasi baru.Selain itu, Anda memiliki solusi yang dibuat satu dekade lalu untuk menjembatani kesenjangan atau rentang waktu antara bermigrasi dari satu platform ke platform lainnya, tetapi terlepas dari upaya terbaik Anda, sistem ini tetap ada. Ditambah dengan tantangan ini adalah kumpulan sistem dan sumber daya TI yang berkembang dari merger dan akuisisi Perusahaan U. Menyampaikan HA tidak sesederhana yang Anda pikirkan di era baru.

  1. Arsitektur yang buruk adalah masalah yang lebih besar dari yang Anda sadari

Sebagai Wakil Presiden Pengalaman Pelanggan, kami telah melihat kerusakan yang disebabkan oleh arsitektur yang buruk.Meskipun penerapan perangkat lunak HA pasti dapat membantu meningkatkan ketersediaan aplikasi dan database, perangkat lunak HA tidak akan pernah sepenuhnya mengatasi persyaratan yang tidak lengkap, jaringan yang buruk, kurangnya perangkat keras yang berlebihan, atau komponen arsitektur lainnya yang hilang.Tim kami pernah bekerja dengan pelanggan untuk memperbaiki lingkungan berukuran kecil yang membuat sistem mereka tidak stabil selama waktu pengoperasian puncak.Karena arsitektur mereka yang buruk, yang mencakup ketidakstabilan jaringan dan perangkat keras, tim mereka sering kesulitan untuk memulihkan diri dari masalah downtime yang dapat dihindari.Untuk mendapatkan solusi yang lengkap dan sehat, sangat tersedia, dan tangguh, Anda perlu menerapkan perangkat lunak yang hebat sebagai bagian dari arsitektur yang baik.

  1. Admin Anda membutuhkan lebih banyak bantuan daripada yang mereka akui

Mengembangkan solusi HA tangguh tingkat perusahaan dengan ketersediaan tinggi, dibangun di atas arsitektur yang solid dengan kemampuan untuk berkembang bukanlah proses yang sederhana.Merancang dan merancang ketahanan, aplikasi, dan ketersediaan data tidak semudah mengambil sekotak campuran kue dari rak.Lemparkan berbagai alat, proses dari tim yang berbeda, campuran SLA, dan jenis OS, aplikasi, database, dan platform dan Anda memiliki resep untuk membutuhkan bantuan. Baru-baru ini, saya mewawancarai seorang veteran 20 tahun yang bekerja di lingkungan dukungan perusahaan.Dia menggambarkan berapa banyak dari rekan-rekannya, dan bahkan dirinya sendiri, belum mampu menangani beban mempertahankan ketersediaan perusahaan kritis.Admin Anda, tidak hanya membutuhkan bantuan ketika mereka sudah bangun sejak jam 2 pagi berurusan dengan bencana, multi-sistem, multi-aplikasi, runtuhnya pusat data yang hampir selesai, tetapi juga dalam kerja keras sehari-hari ketersediaan perusahaan di salah satu yang paling era teknologi yang kompleks yang pernah ada.

  1. Solusi Anda mungkin tidak tersedia sebanyak yang Anda pikirkan

“Sementara penyedia cloud publik biasanya menjamin beberapa tingkat ketersediaan dalam perjanjian tingkat layanan mereka, SLA tersebut hanya berlaku untuk perangkat keras cloud.” Ada banyak alasan lain untuk downtime aplikasi yang tidak dicakup oleh SLA penyedia cloud, termasuk:

  • Masalah perangkat lunak dan bug
  • Kesalahan manusia
  • Kegagalan perangkat lunak
  • Sistem atau aplikasi hang

Sebagai VP Pengalaman Pelanggan, kami telah melihat satu atau dua hal, termasuk serangan denial of service yang disebabkan oleh gagal keluar dalam rutinitas rekursi, kelelahan sistem, karantina perangkat lunak keamanan aplikasi yang sehat, kritis, kepanikan kernel, dan mesin virtual yang secara acak menyalakan ulang.Jika strategi HA Anda hanya mengandalkan SLA hypervisor Anda, solusi Anda mungkin tidak tersedia sebanyak yang Anda kira. Anda perlu melindungi aplikasi penting dengan perangkat lunak pengelompokan yang dapat memantau dan mendeteksi masalah, merespons masalah dengan andal, dan jika perlu memindahkan operasi ke server siaga untuk memastikan bahwa produk dan layanan Anda tetap andal dan tersedia saat dan di mana pun dibutuhkan.

Pusat data tunggal kami telah menjadi serangkaian platform cloud, yang mencakup lusinan pusat data.Aplikasi kerja sigung kami telah menjadi bagian dari perkumpulan solusi front end, middleware, dan backend kritis yang harus kami kelola di Windows, Linux, dan beberapa varietas * Nix yang berbeda.Pawai teknologi berarti bahwa kita ketersediaan tinggi telah menjadi lebih kompleks dan membutuhkan arsitektur yang lebih baik.Ini juga berarti bahwa tim kita membutuhkan lebih banyak bantuan untuk mengelola semuanya, dan jika kita tidak berhati-hati, itu bisa berarti kita tetap rentan dan terekspos.Manakah dari empat kebenaran yang paling banyak dihadapi tim Anda?

Cassius Rhue, Pengalaman Pelanggan VP Direproduksi dengan izin dari SIOS
November 15, 2022

Apa yang Dilakukan Driver Baru di SIOS LifeKeeper untuk Windows Untuk Anda?

Apa yang Dilakukan Driver Baru di SIOS LifeKeeper untuk Windows Untuk Anda?

Membuat perlindungan data di lingkungan bersama dan tanpa SAN menjadi lebih kuat di tahun-tahun mendatang.

Apa Coca-Cola, KitKat, SalesForce, dan SIOS LifeKeeper untuk Windows memiliki kesamaan?Berikut adalah beberapa petunjuk:

  • Coca-Cola meluncurkan kembali kampanye menggunakan desain ulang produk dari merek ikoniknya untuk beradaptasi dengan masa depan, khususnya untuk fokus pada tema sosial.
  • Kit-Kat mengganti nama candy bar-nya di Inggris untuk memperingati dan merayakan booming media sosial, YouTube, dan gelombang teknologi umum, serta memanfaatkan kekuatan merek OS Android (KitKat).
  • Salesforce mengubah produk dasarnya untuk menciptakan antarmuka yang lebih ramping, lebih modern, dan lebih cepat untuk melayani kebutuhan pelanggannya.

Perusahaan-perusahaan ini membuat peningkatan signifikan pada produk, layanan, dan solusi ikonik mereka untuk melayani pelanggan mereka dengan lebih baik, beradaptasi dan mempersiapkan masa depan, dan memanfaatkan kekuatan mereka.Dengan cara yang sama, SIOS telah membuat peningkatan dramatis pada produk SIOS LifeKeeper untuk Windows kami.

Sebelum LifeKeeper untuk Windows versi 8.9.0, fungsi penyimpanan bersama, termasuk pagar I/O serta identifikasi dan manajemen drive ditangani oleh driver NCR_LKF.Dimulai dengan rilis SIOS LifeKeeper untuk Windows versi 8.9.0, SIOS Technology Corp. mendesain ulang arsitektur driver penyimpanan bersama. Dimulai dengan rilis saat ini, driver NCR_LKF telah dihapus dan diganti dengan driver SIOS ExtMirr, mesin di belakang replikasi penyimpanan tanpa SAN dari SIOS DataKeeper / SIOS DataKeeper Cluster Edition.

Lima manfaat signifikan dari perubahan arsitektur NCR_LKF di SIOS LifeKeeper untuk Windows:

  1. Pengemudi yang lebih modern

Driver ExtMirr menyediakan driver filter yang lebih modern untuk mengelola fungsionalitas penyimpanan bersama.Sementara driver NCR_LKF berfokus pada "menyalakan lampu" dan "keamanan data", arsitektur driver tertinggal dari driver yang lebih modern.Driver ExtMirr mempertahankan perlindungan data tersebut, sekaligus lebih kompatibel, lebih modern, dan lebih mudah didukung di versi OS Windows yang lebih baru.

  1. Pagar I/O yang lebih kuat

Pengemudi yang digunakan dalam SIOS DataKeeper dan SIOS DataKeeper Cluster Edition menyertakan arsitektur pagar yang kuat. Sementara driver NCR_LKF mampu menahan I/O, driver baru ini lebih tangguh dan telah diuji di lingkungan SAN dan tanpa SAN. Pagar I/O yang ditingkatkan memanfaatkan kunci volume dan informasi kepemilikan node dalam volume yang dilindungi.

  1. Integrasi dan kompatibilitas yang lebih ketat.

Memanfaatkan pagar I/O untuk driver ExtMirr yang digunakan dalam produk DataKeeper berarti solusi LifeKeeper untuk Windows meningkat dalam integrasi dengan lini produk DataKeeper.Driver ExtMirr juga termasuk yang terbaru Penandatanganan driver Microsoft dan bekerja mulus dengan Sistem Operasi yang menerapkan penandatanganan driver dan Boot Aman.

  1. Administrasi lebih mudah

Driver ExtMirr memberi pelanggan dan administrator sekumpulan besar utilitas baris perintah untuk mendapatkan dan mengelola status volume.Perintah emcmd asli untuk kedua produk SIOS DataKeeper. Mereka sekarang dapat digunakan untuk administrasi yang lebih mudah dengan konfigurasi volume bersama SIOS LifeKeeper. Pelanggan dan mitra yang memanfaatkan penyimpanan bersama dan konfigurasi yang direplikasi dengan LifeKeeper untuk produk Windows kini memiliki seperangkat alat baris perintah untuk diketahui dan digunakan. Alat emcmd menggantikan volume.exe, volsvc, dan alat driver filter NCR_LKF serupa sebelumnya untuk administrasi (mengunci, membuka kunci, dll).

  1. Pembaruan dan perbaikan yang lebih sering

Dengan penambahan driver ExtMirr ke dalam SIOS LifeKeeper untuk Windows, konfigurasi penyimpanan bersama, serta konfigurasi replikasi, kini akan mengalami peningkatan dalam pembaruan, fitur baru, dan perbaikan. Sementara driver NCR_LKF menyediakan fondasi yang kokoh dan basis yang stabil untuk pagar I/O, beralih ke driver ExtMirr berarti pelanggan akan melihat kekuatan dan stabilitas yang sama, dengan pembaruan yang lebih cepat untuk dukungan produk baru Menyelaraskan dua produk ke satu driver mungkin tidak sama mencoloknya dengan pembaruan SalesForce Classic ke Lightning, tetapi menambahkan fungsionalitas yang signifikan, meningkatkan kekuatan dan umur panjang solusi SIOS DataKeeper dan SIOS LifeKeeper, dan akan membuat perlindungan data di lingkungan bersama dan tanpa SAN menjadi lebih kuat untuk tahun-tahun mendatang.

Cassius Rhue, Pengalaman Pelanggan VP Direproduksi dengan izin dari SIOS
November 11, 2022

Cara membuat ulang sistem file dan sumber daya mirror untuk memastikan informasi ukuran sudah benar

Cara membuat ulang sistem file dan sumber daya mirror untuk memastikan informasi ukuran sudah benar

Saat bekerja dengan clustering ketersediaan tinggi (HA), penting untuk memastikan bahwa konfigurasi semua node dalam cluster sejajar satu sama lain. Konfigurasi 'cermin' ini membantu meminimalkan titik kegagalan pada kluster, memberikan standar perlindungan HA yang lebih tinggi. Sebagai contoh, kami telah melihat situasi di mana mirror-size diperbarui pada node sumber tetapi informasi yang sama tidak diperbarui pada node target. Ketidakcocokan ukuran mirror mencegah LifeKeeper memulai node target dalam failover. Di bawah ini adalah langkah-langkah yang disarankan untuk membuat ulang sumber cermin pada node target dengan informasi ukuran yang sama dengan sumber:

Langkah:

  1. Verifikasi – dari perspektif aplikasi – bahwa data pada node sumber valid dan konsisten
  2. Cadangkan sistem file pada sumbernya (yang merupakan sumber cermin)
  3. Jalankan /opt/LifeKeeper/bin/lkbackup -c untuk mencadangkan konfigurasi LifeKeeper di kedua node
  4. Keluarkan semua sumber daya dari layanan.Dalam contoh kita, sumber daya dalam layanan pada node sc05 dan sc05 adalah sumber dari mirror (dan sc06 adalah sistem target/target dari mirror).
    1. Di panel kanan LifeKeeper GUI, klik kanan pada sumber daya DataKeeper yang sedang dalam pelayanan.
    2. Klik Sedang dalam perbaikan dari menu munculan sumber daya.
    3. Kotak dialog akan mengonfirmasi bahwa sumber daya yang dipilih akan dihentikan layanannya. Ketergantungan sumber daya apa pun yang terkait dengan tindakan dicatat dalam dialog. Klik Lanjut.
    4. Sebuah kotak informasi muncul menunjukkan hasil sumber daya yang diambil dari layanan. Klik Selesai.
  1. Verifikasi bahwa semua sumber daya tidak berfungsi dan sistem file tidak terpasang
    1. Gunakan perintah cat /proc/mdstat pada sumber untuk memverifikasi bahwa tidak ada cermin yang dikonfigurasi
  1. Gunakan perintah mount pada sumber untuk memastikan sistem file tidak lagi terpasang
  2. Gunakan /opt/LifeKeeper/bin/lcdstatus -q pada sumber untuk memastikan semua sumber daya OSU.
  1. Di GUI LifeKeeper hancurkan ketergantungan antara sumber daya IP (VIP) dan sumber daya sistem file (/mnt/sps).Klik kanan pada sumber daya VIP dan pilih Hapus Ketergantungan.

Kemudian, pilih sumber daya Sistem File (/mnt/sps) untuk Tag Sumber Daya Anak.

Ini akan menghasilkan dua hierarki, satu dengan sumber daya IP (VIP) dan satu lagi dengan sumber daya sistem file (/mnt/fs) dan sumber daya cermin (datarep-sps).

  1. Hapus hierarki dengan sistem file dan sumber cermin. Klik kanan pada /mnt/sps dan pilih Delete Resource Hierarchy.
  1. Pada sumbernya, lakukan 'mount <device> <directory>' pada sistem file.

Contoh: mount /dev/sdb1 /mnt/sps

  1. Melalui GUI buat ulang cermin dan sistem file melalui yang berikut ini:
    1. Kit Pemulihan: Replikasi Data
  1. Jenis Switchback: Cerdas
  2. Server: Node sumber
  3. Jenis Hierarki: Replikasi Sistem File yang Ada
  4. Mount Point yang ada: <pilih titik mount Anda>. Ini adalah /mnt/sps untuk contoh ini.
  5. Tag Sumber Daya Replikasi Data: <Ambil default>
  6. Tag Sumber Daya Sistem File: <Ambil default>
  7. File Bitmap: <Ambil default>
  8. Aktifkan Replikasi Asinkron: Ya
  1. Setelah dibuat, Anda dapat Memperluas cermin dan hierarki sistem file:
    1. Server target: Node target
    2. Jenis Switchback: Cerdas
    3. Prioritas Templat: 1
    4. Prioritas Target: 10
  1. Setelah pemeriksaan pra-perpanjangan selesai, pilih berikutnya diikuti dengan nilai-nilai ini:
    1. Disk target: <Pilih disk target untuk mirror>.Ini adalah /dev/sdb1 dalam contoh kita.
    2. Tag Sumber Daya Replikasi Data: <Ambil default>
    3. File Bitmap: <Ambil default>
    4. Jalur Replikasi: <Pilih jalur replikasi di lingkungan Anda>
    5. Mount Point: <Pilih titik mount di lingkungan Anda>.Ini adalah /mnt/sps dalam contoh kita.
    6. Tag Akar: <Ambil default>

Ketika resource "extend" selesai pilih "Finish" dan kemudian "Done".

  1. Di GUI LifeKeeper, buat ulang ketergantungan antara sumber daya IP (VIP) dan sumber daya sistem file (/mnt/sps). Klik kanan pada sumber daya VIP dan pilih Buat Ketergantungan.Pilih /mnt/sps untuk Tag Sumber Daya Anak.
  1. Pada titik ini mirror harus melakukan sinkronisasi ulang penuh dari ukuran sistem file. Di GUI LifeKeeper di panel kanan GUI LifeKeeper, klik kanan pada sumber daya VIP. Pilih "Dalam Layanan" untuk memulihkan sumber daya IP (VIP), pilih sistem sumber tempat cermin dalam layanan (sc05 dalam contoh kami) dan verifikasi bahwa aplikasi dimulai ulang dan IP dapat diakses.

Direproduksi dengan izin dari SIOS
November 9, 2022

Menjelaskan Perbedaan Halus tapi Penting Antara Switchover, Failover, dan Recovery

Menjelaskan Perbedaan Halus tapi Penting Antara Switchover, Failover, dan Recovery

Ketersediaan tinggi adalah spesialisasi dan seperti kebanyakan spesialisasi, ia memiliki kosakata dan terminologinya sendiri. Pelanggan kami biasanya sangat berpengetahuan tentang TI tetapi jika mereka belum pernah bekerja di lingkungan HA, beberapa terminologi HA umum kami dapat menyebabkan cukup banyak kebingungan – bagi mereka dan bagi kami. Mereka terdengar sederhana tetapi dengan makna yang sangat spesifik dalam konteks HA. Tiga istilah ini dibahas di sini – swithover, failover, dan recovery.

Apa itu Peralihan? ?

Peralihan adalah dimulai oleh pengguna tindakan melalui ketersediaan tinggi (HA) solusi pengelompokan antarmuka pengguna atau CLI. Dalam peralihan, pengguna secara manual memulai tindakan untuk mengubah sumber atau server utama untuk aplikasi yang dilindungi. Dalam skenario peralihan yang khas, semua aplikasi dan dependensi yang berjalan dihentikan secara berurutan, dimulai dengan aplikasi induk dan diakhiri ketika semua turunan/dependensi dihentikan. Setelah aplikasi dan dependensinya dihentikan, mereka kemudian dimulai ulang secara teratur di server utama atau sumber yang baru ditunjuk.

Misalnya, jika Anda memiliki sumber daya Alpha, Beta, dan Gamma. Resource Alpha bergantung pada resource Beta dan Gamma. Sumber Daya Beta tergantung pada sumber daya Gamma.Dalam peristiwa peralihan, sumber daya Alpha dihentikan terlebih dahulu, diikuti oleh Beta, dan akhirnya Gamma.Setelah ketiganya dihentikan, peralihan terus membawa sumber daya ke status operasional di server yang dimaksud.Proses dimulai dengan sumber daya Gamma, diikuti oleh Beta, dan akhirnya operasi start up selesai untuk sumber daya Alpha.Secara tradisional, operasi peralihan membutuhkan lebih banyak waktu karena sumber daya harus dihentikan dengan cara yang anggun dan teratur. Peralihan sering dilakukan ketika ada kebutuhan untuk memperbarui versi perangkat lunak sambil mempertahankan waktu aktif, melakukan pekerjaan pemeliharaan (melalui peningkatan berkelanjutan) pada node produksi utama, atau melakukan pengujian DR.

Takeaway kunci: Jika tidak ada kegagalan untuk menyebabkan tindakan, maka itu adalah peralihan

Apa itu Failover?

Operasi failover biasanya merupakan tindakan yang dimulai oleh non-pengguna sebagai respons terhadap kerusakan server atau reboot yang tidak terduga/tidak direncanakan. Pertimbangkan skenario cluster HA dengan dua node, Node A dan Node B.Dalam skenario ini, semua aplikasi penting Alpha, Beta, dan Gamma dimulai dan beroperasi di Node A. Dalam skenario ini, failover adalah apa yang terjadi ketika Node A mengalami reboot yang tidak terduga/tidak direncanakan, matikan, hentikan, atau panik. Setelah perangkat lunak HA mendeteksi bahwa Node A tidak lagi berfungsi dan tersedia secara operasional dalam cluster (seperti yang ditentukan oleh solusi), itu akan memicu operasi failover untuk memulihkan akses aplikasi kritis, sumber daya, layanan, dan dependensi pada node cluster yang tersedia , Node B dalam hal ini.Dalam skenario failover, karena Node A telah mengalami crash (atau kegagalan langsung simulasi lainnya) tidak ada proses untuk berhenti pada Node A, dan akibatnya setelah tindakan deteksi dan pagar yang tepat telah diproses, Node B akan segera memulai proses pemulihan sumber daya. Seperti dalam kasus peralihan, proses dimulai dengan sumber daya Gamma, diikuti oleh Beta, dan akhirnya operasi pengaktifan selesai untuk sumber daya Alpha. Secara tradisional, operasi failover membutuhkan waktu lebih sedikit daripada switchover. Hal ini karena pengolahan kegagalan tidak memerlukan sumber daya apa pun untuk dihentikan (atau dihentikan) pada node primer (dalam-layanan atau aktif) sebelumnya.

Takeaway Kunci: Kegagalan terjadi sebagai respons terhadap kegagalan sistem.

Apa Pemulihan ?

Peristiwa pemulihan mudah dikacaukan dengan failover. Peristiwa pemulihan terjadi ketika proses, server, jalur komunikasi, disk, atau bahkan sumber daya cluster gagal dan perangkat lunak ketersediaan tinggi beroperasi sebagai respons terhadap kegagalan yang diidentifikasi. Sebagian besar solusi perangkat lunak HA mampu melakukan berbagai cara untuk menangani peristiwa pemulihan. Metode yang paling menonjol meliputi:

  1. Restart dengan anggun secara lokal, lalu restart dengan anggun pada remote
    1. Restart selalu dicoba secara lokal, jika pemulihan berhasil tidak ada tindakan lebih lanjut yang terjadi. Jika restart lokal gagal, operasi berikutnya terjadi
    2. Jika restart lokal gagal, sumber daya dipindahkan dengan anggun ke node jarak jauh
  2. Restart dengan anggun secara lokal, lalu restart paksa pada remote
    1. Restart selalu dicoba secara lokal, jika pemulihan berhasil tidak ada tindakan lebih lanjut yang terjadi.Jika restart lokal gagal operasi berikutnya terjadi.
    2. Sumber daya dipindahkan ke simpul jarak jauh dengan memagari simpul utama
  3. Restart paksa pada remote
    1. Restart tidak pernah dicoba secara lokal
    2. Sumber daya selalu dipaksa ke node cluster berikutnya yang tersedia seperti yang dijelaskan dalam metode 2b.
  4. Restart server paksa, tidak ada failover jarak jauh
    1. Restart selalu dicoba secara lokal
    2. Jika restart lokal gagal, node utama dimulai ulang untuk mencoba memulihkan layanan.
    3. Sumber daya tidak akan gagal ke sistem jarak jauh
  5. Restart lokal berbasis kebijakan, lalu jarak jauh
    1. Kebijakan dapat mengatur jumlah percobaan ulang sebelum upaya pemulihan jarak jauh terjadi

Karena banyaknya variasi dalam kebijakan pemulihan, mudah untuk melihat peristiwa pemulihan yang menyerupai perilaku peralihan. Hal ini sering terjadi pada metode 1 dan 5. Dalam skenario ini, aplikasi dan layanan dihentikan secara tertib sebelum dimulai pada node jarak jauh. Metode 2 dan 3, pelanggan akan sering melihat perilaku yang mirip dengan failover. Dalam metode 2 dan 3, server utama dimulai ulang atau dipagari oleh perangkat lunak HA yang menciptakan perilaku yang dapat diamati mirip dengan failover.Metode 4 biasanya merupakan opsi yang jarang digunakan, tetapi merupakan gabungan dari peralihan dan kegagalan.Metode 4 dimulai dengan penghentian aplikasi dan layanan dengan anggun, diikuti dengan memulai ulang aplikasi dan layanan (seperti peralihan). Namun, jika restart lokal aplikasi dan layanan gagal, sistem akan dimulai ulang (seperti failover), tetapi tanpa benar-benar gagal ke node cluster jarak jauh. Meskipun jarang, Metode 4 sering digunakan dalam kasus di mana terdapat klaster yang tidak seimbang, atau digunakan dengan metodologi berbasis kebijakan.

Takeaway kunci: Peristiwa pemulihan tergantung pada metode yang dipilih. Terminologi HA antara vendor adalah area di mana istilah umum dapat memiliki arti yang berbeda. Saat Anda menerapkan dan memelihara solusi klaster Anda dengan aplikasi perusahaan, pastikan Anda memahami persyaratan penyedia solusi untuk failover, switchover, dan pemulihan.Dan, saat Anda melakukannya, pastikan Anda tahu apakah restoran akan meletakkan saus di samping (dalam piring), atau di samping (kentang tumbuk Anda) Diperbanyak dengan izin dari SIOS
November 3, 2022

Praktik Terbaik untuk Mengunduh Produk SAP

Praktik Terbaik untuk Mengunduh Produk SAP

Blog ini adalah upaya untuk mengungkap beberapa langkah yang diperlukan untuk mengunduh SAP dan aplikasi serta tambalan terkait, karena dapat menjadi rumit bagi pengguna yang tidak berpengalaman. Login Dukungan SAP akan diperlukan sebelum Anda dapat melanjutkan dengan langkah-langkah yang diuraikan di bawah ini..

Sebaiknya unduh dan instal " Manajer Unduhan SAP ” yang terdapat di bagian bawah halaman di bawah ini. Pengelola Unduhan memungkinkan Anda memilih beberapa paket untuk diunduh pada saat yang bersamaan. Ini memungkinkan pengunduhan beberapa paket tanpa pengawasan.

Ikuti ini tautan untuk instruksi SAP tentang cara menginstal dan mengonfigurasi pengelola unduhan perangkat lunak.

Setelah Anda mengunduh dan menjalankan DLManager.jar, Anda akan diminta dengan asisten konfigurasi:

Klik Berikutnya

Masukkan kredensial login SAP Anda, jika Anda memerlukan proxy maka Anda dapat mengonfigurasinya.

Masukkan lokasi di mana unduhan akan disimpan. Klik Selesai.

Sekarang Download Manager sedang berjalan dan Anda akan menambahkan file ke dalam keranjang untuk mengunduhnya, lihat di bawah.

Klik hijau Ganda >> panah untuk mengunduh semua item di pengelola unduhan.

Instalasi & Peningkatan

Gulir ke atas unduhan perangkat lunak:

Yang kami minati di sini terutama adalah "Pemasangan dan Peningkatan". Di sinilah gambar versi SAP lengkap tersedia.

Untuk HANA scroll ke H Untuk Hana saya pilih “H” lalu cari “SAP HANA Platform Edition 2.0”.

Banyak HANA, Cari dan pilih “SAP HANA PLATFORM EDITION”

Mengklik ini memberi saya opsi untuk memilih "Instalasi".

Sekarang kami disajikan dengan daftar rilis perangkat lunak saat ini yang tersedia, untuk HANA saat ini versi 2.0 SP5 atau SP6. Anda harus memilih platform perangkat keras yang Anda inginkan, dalam kasus kami Linux x86_64. Jika kita ingin menggunakan download manager kita cukup mengklik shopping cart (yang dilingkari merah), atau kita bisa mendownload langsung melalui browser kita dengan mengklik link (yang dilingkari hijau).

HANA datang dalam bentuk ZIP yang perlu diunggah ke VM Linux Anda dan kemudian dibongkar menggunakan unzip. Sebagian besar paket SAP datang dalam format .SAR dan ini membutuhkan SAPCAR untuk mengekstrak, SAPCAR adalah utilitas SAP yang digunakan untuk mengompres atau membuka kompres file.

Anda dapat mencari SAPCAR dan mengunduh versi yang sesuai untuk platform Anda, SAPCAR biasanya digunakan dengan opsi -xvf misalnya ./SAPCAR -xvf SAP.SAR

Paket & Tambalan Dukungan

“Paket dan Tambalan Dukungan” akan memberi Anda tingkat tambalan tertentu yang dapat diterapkan ke tingkat produk dasar. “Database” digunakan untuk mendukung database pihak ketiga untuk digunakan dengan SAP (selain HANA).

Setelah kami memilih "Paket Dukungan dan Tambalan" kami disajikan dengan beberapa opsi tentang bagaimana kami ingin menemukan perangkat lunak. Saya biasanya menggunakan "By Alphabetical Index (AZ)".

H untuk SAP HANA

Kemudian komponen software yang ingin di patch, misal SAP HANA PLATFORM EDITION

Sekali lagi, pilih subkomponen mana yang ingin Anda tambal, misalnya SAP HANA PLATFORM EDITION 2.0

Terakhir, pilih level patch yang Anda inginkan untuk subkomponen yang dipilih.

Akhirnya, Anda siap untuk bagian yang menyenangkan…menginstal SAP! Jika Anda memerlukan bantuan untuk memastikan Infrastruktur SAP sangat tersedia , silakan hubungi SIOS. Kami akan senang untuk berbicara dengan Anda.

Direproduksi dengan izin dari SIOS
  • Results 151-155 of 928
  • < Page 31 of 186 >

  • Bergabunglah dengan Milis Kami