SIOS APAC Portal

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
Juli 17, 2020	6 Tantangan Migrasi Awan Umum 6 Tantangan Migrasi Awan Umum Sebagai seorang insinyur perangkat lunak untuk pengalaman pelanggan dengan SIOS, saya sering membantu perusahaan yang memigrasi lingkungan pengelompokan ketersediaan tinggi mereka ke cloud. Migrasi cloud adalah proses, bukan tujuan. Saat kami melibatkan pelanggan yang beralih ke cloud, sering kali terlambat dalam proses perencanaan, yang tidak ideal, tetapi tidak biasa dalam migrasi cloud. Di bawah ini adalah enam tantangan migrasi awan yang sering kita lihat. Waktu – Memahami berapa lama waktu yang dibutuhkan untuk transfer data ke cloud Berapa lama untuk mendapatkan data Anda dari lokasi ke cloud? Ini dapat bervariasi secara drastis tergantung pada aplikasi Anda, jenis data, dan penyedia cloud. Salah satu detail yang sering diabaikan adalah waktu yang diperlukan untuk menyinkronkan data dari node primer ke node sekunder, dan dalam beberapa kasus ke situs pemulihan bencana (DR). Pelanggan yang tidak memperhitungkan waktu sinkronisasi ulang dibiarkan memutar-mutar ibu jari mereka saat data direplikasi. Biaya – Memahami implikasi biaya dari transfer data di dalam cloud Transfer data dalam wilayah cloud tidak dikenai biaya. Transfer data antar wilayah akan dikenakan biaya. Biasanya, kita melihat arsitektur di mana node primer dan sekunder terletak di zona ketersediaan cloud yang terpisah dalam suatu wilayah. Biaya dapat meningkat secara signifikan ketika situs DR diperkenalkan karena situs DR akan selalu berada di wilayah lain. Pemulihan bencana untuk aplikasi kaya data seperti SAP NetWeaver mungkin berbiaya rendah untuk ditiru di seluruh wilayah. Replikasi Antar Wilayah Replikasi antar wilayah memperkenalkan tantangan lain: tipe replikasi. Replikasi asinkron atau sinkron dalam AZ ditentukan oleh persyaratan RTO dan RPO pelanggan. Terlepas dari ukuran instance, replikasi data akan mengalami beberapa latensi saat melintasi antar wilayah. SIOS merekomendasikan replikasi asinkron antara wilayah untuk mengurangi dampak latensi itu. Concurrency Labs memberikan beberapa informasi mendalam tentang latensi antara wilayah EC2. Keanehan Konfigurasi Cloud Gambar OS siap pakai dapat digunakan dari cloud. Kenyamanan ini datang dengan biaya, memperkenalkan faktor lain untuk manajemen konfigurasi. Layanan cloud-init yang disertakan pada gambar SuSE Enterprise Linux yang dioptimalkan untuk cloud dapat menghapus alamat IP virtual yang ditentukan pengguna. Tidak ada yang menghentikan PoC seperti alamat IP virtual menghilang setiap dua menit! Keamanan Cloud Skala komputasi awan memberikan keamanan yang lebih besar daripada yang mampu dimiliki bisnis di pusat data di lokasi. Beban kerja cloud memanfaatkan keamanan mutakhir tanpa menyadarinya. Misalnya, secara default instance AWS EC2 memblokir lalu lintas apa pun yang tidak dikirim oleh atau dikirim ke instance itu sendiri. Ini adalah fitur hebat untuk mengamankan jaringan di cloud. Jika suatu sistem membutuhkan Terjemahan Alamat Jaringan (NAT), langkah-langkah keamanan standar EC2 akan menyebabkan alamat IP gagal. Menonaktifkan pemeriksaan sumber / tujuan dari konsol akan menyelesaikan masalah. Bergantung pada keakraban pengguna dengan AWS, ini dapat mengambil antara beberapa klik hingga beberapa panggilan dukungan. Memahami secara spesifik bagaimana suatu sistem berinteraksi dalam suatu lingkungan adalah kunci keberhasilan migrasi cloud. Pengujian Penerimaan Pengguna Cloud (UAT) Pelanggan yang berasal dari sistem di-prem perlu diingatkan 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. Melaksanakan migrasi cloud yang sukses membutuhkan masukan dari semua pemangku kepentingan. Ketersediaan tinggi dan pemulihan bencana adalah aspek inti dari setiap beban kerja perusahaan. Apakah SIOS sudah menjadi bagian dari sistem Anda saat ini atau akan menjadi bagian dari migrasi cloud masa depan Anda, libatkan kami! -Harrison Howell, Insinyur Perangkat Lunak untuk Pengalaman Pelanggan Direproduksi dengan izin dari SIOS
Juli 15, 2020	SIOS Protection Suite untuk Linux Versi 9.5 Ada di Sini! SIOS Protection Suite untuk Linux Versi 9.5 Ada di Sini! Kami dengan bangga mengumumkan ketersediaan SIOS Protection Suite untuk Linux versi 9.5. Produk ini memperkenalkan otomatisasi canggih dan pemantauan sadar aplikasi sehingga menjadikannya perangkat lunak pengelompokan SAP S / 4HANA yang paling komprehensif di industri. Kami tahu betapa repotnya mencoba secara manual membangun SAP S / 4HANA cluster, memastikan bahwa semua layanan HANA akan gagal ke lokasi yang tepat dan memulai dalam urutan yang benar. Jam penulisan, pengujian, dan kejengkelan. Dan taruhannya tinggi. Melakukan kesalahan dapat berarti kegagalan tidak terjadi atau lebih buruk – downtime, kehilangan data, banyak pengguna yang diperburuk menelepon. Itu sebabnya kami menambahkan ketersediaan aplikasi cerdas untuk konfigurasi basis data SAP S / 4HANA dua simpul yang menggunakan replikasi Sistem HANA (HSR). Kami telah membuat rilis ini untuk menghilangkan kerumitan dan risiko membangun dan mengelola sebuah cluster. SIOS Protection Suite v9.5 Otomatis dan Monitor Mulai dari konfigurasi yang mudah dan digerakkan oleh wizard yang benar-benar memvalidasi input Anda. Tidak ada jam penulisan skrip manual … atau mencari keystroke yang salah ketika semuanya tidak berjalan dengan baik. Ini memantau semua proses dalam tumpukan HANA dari aplikasi ke perangkat keras, server, dan jaringan – tidak hanya memeriksa bahwa server operasional seperti perangkat lunak pengelompokan lainnya. Dan tidak seperti solusi pengelompokan lain yang memicu failover untuk semuanya, jika SIOS Protection Suite mendeteksi masalah, secara otomatis mengambil tindakan pemulihan yang sesuai – apakah itu hanya me-restart layanan, memulihkan pada node yang berada dalam layanan atau mengatur failover ke sekunder simpul Berbicara tentang orkestrasi failover, itu akan secara otomatis memastikan bahwa praktik terbaik spesifik SAP dipertahankan sepanjang. Misalnya, memastikan bahwa pada failover atau switchover, ASCS tidak pernah berada di server dengan aplikasi utama atau pada server yang sama dengan ERS. Jika konfigurasi yang digerakkan oleh wizard tidak cukup mudah, kami juga menambahkan fitur kloning antarmuka baris perintah (CLI) baru yang memungkinkan Anda menggunakan cluster SIOS hanya dengan mengimpor instruksi CLI untuk konfigurasi. Anda juga dapat mengekspor instruksi CLI dari kluster yang ada untuk membuat klonnya. Sekarang dengan SIOS Protection Suite untuk Linux, Anda dapat membuat cluster ketersediaan tinggi dengan cepat dan mudah untuk melindungi aplikasi apa pun. Ini termasuk SQL Server, Oracle, SAP dan S / 4HANA, dari downtime dan bencana. Minta Uji Coba Gratis Direproduksi dengan izin dari SIOS
Juli 14, 2020	EC2 Memantau Praktik Terbaik: Menggunakan SIOS AppKeeper untuk Melindungi NGINX Webservers di Amazon EC2 EC2 Memantau Praktik Terbaik: Menggunakan SIOS AppKeeper untuk Melindungi NGINX Webservers di Amazon EC2 NGINX adalah server web yang juga dapat bertindak sebagai penyeimbang beban, proxy terbalik, dll. Bersama-sama di antara mereka, NGINX dan Apache melayani lebih dari 50% lalu lintas di web. Saat ini banyak perusahaan yang menjalankan NGINX Open Source atau NGINX Plus webservers mereka di lingkungan Amazon EC2 menggunakan Amazon Linux, Red Hat Linux, dan Ubuntu. Semua orang setuju bahwa ini adalah praktik terbaik untuk memantau aplikasi seperti NGINX di EC2 dan merespons setiap penyimpangan sistem dengan cepat. Pengguna mengharapkan akses cepat dan waktu aktif konstan untuk aplikasi mereka. Pilihan saat ini untuk memantau webservers NGINX di Amazon EC2 Banyak perusahaan mengerahkan Amazon CloudWatch untuk memantau aplikasi mereka, dan bahkan menciptakan beberapa tingkat otomatisasi dengan mengembangkan skrip atau dengan menggunakan AWS Lambda. Tetapi mengonfigurasi Amazon CloudWatch dengan benar dengan metrik khusus dan mengatur Amazon Lambda membutuhkan sejumlah keahlian teknis yang mungkin melebihi kemampuan banyak perusahaan. Dan kemudian ada biaya dan upaya yang diperlukan untuk memelihara skrip apa pun saat aplikasi berkembang. Pilihan lain adalah menggunakan solusi pemantauan kinerja aplikasi (APM), seperti solusi dari New Relic, Dynatrace, Datadog, atau LogicMonitor. Solusi APM sangat bagus. Mereka melakukan pekerjaan yang sangat baik untuk mengawasi semua sistem Anda dan menunjukkan dengan tepat apa yang terjadi dan mengapa. Mereka membuat log yang dapat dibagikan dengan dan ditafsirkan oleh tim pengembangan Anda untuk menciptakan kembali masalah dan memastikan bahwa itu tidak terjadi lagi. Tapi inilah masalahnya: solusi APM menyediakan banyak data yang harus Anda pilah (memisahkan "sinyal dari kebisingan") dan mereka tidak melakukan apa pun untuk memulihkan dari kegagalan ketika terjadi. Alat APM hanya bagian dari solusi untuk mengurangi waktu henti untuk webservers NGINX Anda. Tetapi beberapa perusahaan tidak memiliki staf internal atau alat untuk memantau lingkungan EC2 mereka sendiri. Ini adalah alasan mengapa mereka memilih untuk melakukan outsourcing tugas ke penyedia layanan yang dikelola. Ada beberapa manfaat nyata untuk bekerja dengan MSP untuk mengelola lingkungan Anda, seperti tidak harus mempekerjakan lebih banyak staf saat lingkungan Anda berkembang, atau tidak harus melatih tim Anda tentang teknologi baru. Dan MSP menikmati efisiensi karena mereka dapat menyebar investasi mereka ke banyak klien. Tetapi ada kelemahannya. Dalam beberapa kasus, Anda dapat dikunci ke dalam kontrak berbiaya tinggi, biaya tetap, dan biaya dapat meningkat jika masalah dialami dan harus ditingkatkan untuk mengatasinya. Dan Anda kehilangan kesinambungan antara tim yang memantau lingkungan dan mereka yang bertanggung jawab untuk membangun dan menggunakan aplikasi. Apakah Anda memilih untuk berinvestasi dalam solusi APM atau untuk melakukan outsourcing ke MSP, Anda masih perlu memikirkan seberapa cepat Anda dapat memulihkan server web NGINX Anda dari downtime jika dan ketika itu terjadi. Kami ingin mengusulkan alternatif lain: remediasi otomatis dengan SOIS AppKeeper. SIOS AppKeeper: Remediasi otomatis untuk server web NGINX di EC2 Banyak pelanggan kami telah memilih untuk menggunakan SIOS AppKeeper untuk melindungi server web NGINX mereka. Meskipun mereka dapat memilih solusi pemantauan kinerja aplikasi standar (APM) atau solusi pemantauan pihak ketiga, mereka memilih untuk mengandalkan AppKeeper untuk secara otomatis memulihkan layanan atau seluruh instance EC2 jika terjadi kegagalan. Kami akan melihat beberapa alasan mengapa dan membagikan kepada Anda sebuah video pendek yang menunjukkan bagaimana AppKeeper bekerja dengan NGINX. SIOS AppKeeper adalah layanan SaaS yang mudah dipasang dan dikonfigurasikan dan memonitor semua aplikasi yang berjalan di Amazon EC2, seperti webservers NGINX Anda dan layanan "nginx", "cache manager", dan "pekerja" mereka. Ketika anomali terdeteksi, AppKeeper secara otomatis me-restart layanan, dan jika itu tidak berhasil, reboot seluruh contoh. Tidak ada lagi membaca log yang menyakitkan untuk menunjukkan alasan kegagalan, atau eskalasi kepada pengembang untuk memulai kembali layanan Anda atau biaya outsourcing yang mahal. AppKeeper menyediakan fungsionalitas "set-it-and-forget-it" sehingga Anda dapat yakin mengetahui bahwa NGINX webservers Anda mengikuti praktik terbaik pemantauan EC2 dan berjalan dengan baik, atau akan segera dimulai kembali jika mereka mengalami masalah. Saat ini ratusan perusahaan mengandalkan AppKeeper untuk menjaga lingkungan cloud mereka tetap berjalan. Kami mengundang Anda untuk melihat video cepat ini untuk demonstrasi tentang bagaimana AppKeeper melindungi server web NGINX. Jika Anda ingin mencoba SIOS AppKeeper untuk Anda sendiri, kami menawarkan uji coba gratis selama 14 hari. Cukup klik di sini untuk mendaftar.
Juli 12, 2020	Apa itu Amazon CloudWatch? Apa itu Amazon CloudWatch? Apa yang dapat Anda lakukan dengan CloudWatch dan beberapa rintangan untuk dipertimbangkan Dengan AWS yang memiliki pangsa pasar cloud yang dominan, banyak perusahaan yang memigrasi sistem lokal mereka ke cloud dengan Amazon AWS. Jadi, bagaimana seharusnya sistem yang berjalan di lingkungan AWS dikelola? Dalam posting blog ini, kami akan memperkenalkan fitur Amazon CloudWatch, layanan pemantauan yang disediakan oleh AWS, serta tantangan untuk mengimplementasikannya dan bagaimana menyelesaikannya. Menggunakan Amazon CloudWatch untuk memonitor lingkungan AWS Anda Untuk memastikan bahwa Anda memiliki lingkungan cloud yang stabil, penting untuk mendeteksi anomali ("gangguan sistem") dengan cepat dan merespons secara tepat waktu. Pemantauan menjadi tugas penting dan perlu bagi organisasi mana pun yang pindah ke cloud. Ini tidak berbeda dengan jika Anda mengelola aplikasi dan infrastruktur di tempat. Jadi, bagaimana seharusnya Anda memonitor di lingkungan AWS? Satu pilihan adalah menggunakan Amazon CloudWatch, yang memonitor penggunaan CPU, memori, dan disk dan memberi tahu Anda ketika ambang yang telah ditentukan terlampaui. Plus, Anda dapat mengatur metrik Anda sendiri untuk memantau berbagai item seperti log aplikasi. Bagian terbaik tentang Amazon CloudWatch adalah layanan yang disediakan oleh AWS sendiri. Ini memiliki afinitas tinggi dengan Amazon EC2 dan layanan AWS lainnya, sehingga dapat dengan cepat menanggapi ekstensi fungsional yang sering dan perubahan spesifikasi, dan dapat dengan mudah mendukung AWS Auto Scaling, yang secara otomatis menambah atau mengurangi sumber daya sesuai dengan beban. Amazon CloudWatch menyediakan pemantauan akurat yang disesuaikan dengan keadaan unik setiap lingkungan. Tantangan implementasi Amazon CloudWatch Sementara Amazon CloudWatch sangat cocok untuk organisasi dengan insinyur cloud dan tim DevOps yang berpengalaman, ada beberapa hal yang harus diperhatikan oleh rata-rata pengguna. Amazon CloudWatch efektif untuk memantau lingkungan AWS organisasi, tetapi memerlukan tingkat keterampilan dan pengetahuan tertentu untuk mengonfigurasi dan menggunakan. Terutama ketika Anda mengatur metrik Anda sendiri, menyiapkan lansiran, atau mempertimbangkan Penskalaan Otomatis akun, kompleksitasnya meningkat. Misalnya, Jika Anda mengatur pemantauan, itu mudah, tetapi jika Anda mengatur email, me-reboot, AutoScaling, dll., Tergantung pada situasi sumber daya, itu bisa sulit. Jika Anda ingin mengotomatiskan proses pemulihan dengan instruksi seperti "restart server ketika kesalahan terjadi", Anda harus terlebih dahulu membuat skenario pemulihan dengan skrip AWS Lambda yang menyediakan deskripsi terperinci tentang kondisi dan tindakan yang harus diambil. Seberapa familiar tim Anda dengan AWS Lambda? Keuntungan utama dari Amazon CloudWatch adalah Anda dapat memonitor lingkungan Anda dengan seksama, tetapi untuk melakukan itu, Anda harus mendesain terlebih dahulu dengan tepat untuk setiap sistem item yang akan dipantau dan kapan, nilai ambang, dll. Tugas desain ini bisa memakan banyak waktu. Tentu saja, sistem kritis-misi Anda perlu diawasi dengan ketat dengan cara ini, tetapi tingkat detail dan kecanggihan ini tidak sesuai untuk semua sistem. Untuk beberapa, seperti situs web internal atau server WordPress, Anda harus meminimalkan biaya operasi dan tenaga kerja Anda. Dalam kasus seperti itu, kami ingin menyarankan Anda mempertimbangkan alat yang dapat lebih mudah dioperasikan dan dikelola. SIOS AppKeeper untuk memonitor sistem operasi dan layanan aplikasi yang berjalan pada AWS Untuk aplikasi kritis non-misi, kami ingin merekomendasikan SIOS AppKeeper dari SIOS Technology. AppKeeper mudah untuk menginstal dan mengkonfigurasi serta memantau layanan (proses) aplikasi yang berjalan pada instance EC2. AppKeeper secara otomatis me-restart layanan ketika kesalahan terdeteksi dan reboot instance jika perlu. Bahkan pengguna yang pindah ke cloud untuk pertama kalinya dapat mengatur AppKeeper untuk memonitor instance EC2 mereka dan pulih secara otomatis, tanpa perlu memiliki keterampilan scripting yang canggih. Dengan AppKeeper, tidak perlu memilih layanan individual untuk dipantau. Anda cukup memulai dengan memilih instance EC2 yang akan dipantau dan tindakan apa yang ingin Anda ambil secara otomatis. Anda selalu bisa lebih spesifik tentang layanan mana yang harus dipantau dan bagaimana caranya, tetapi AppKeeper dirancang agar mudah dikonfigurasikan di luar kotak. Ketika kesalahan terdeteksi atau secara otomatis dipulihkan dari, log kegagalan dicatat dan disimpan sehingga penyebab kegagalan dapat diselidiki kemudian. Daripada menggunakan Amazon CloudWatch untuk memonitor segala sesuatu di lingkungan AWS Anda, kami menyarankan Anda mengambil inventaris lingkungan Anda berdasarkan SLA Anda dan persyaratan pemulihan, dan menggunakan SIOS AppKeeper untuk memantau sistem dan aplikasi di mana Anda ingin mengurangi overhead operasional Anda. Nantikan posting blog di masa depan di mana kita akan pergi ke detail yang lebih besar membandingkan cara mengatur CloudWatch dan AppKeeper untuk melakukan fungsi yang sama. Pelajari lebih lanjut tentang SIOS AppKeeper Mendaftar untuk Uji Coba Gratis SIOS AppKeeper

Results 341-345 of 939
< Page 69 of 188 >

Bergabunglah dengan Milis Kami

First Name Last Name Email Address
Pencarian