SIOS APAC Portal

Januari 16, 2021	Haruskah Saya Tetap Menggunakan Zabbix Di AWS? Haruskah Saya Tetap Menggunakan Zabbix Di AWS? Pemantauan Amazon EC2 Zabbix memiliki pangsa pasar yang tinggi sebagai alat pemantauan OSS terintegrasi.Meskipun telah digunakan secara luas di lingkungan di lokasi, ada banyak contoh Zabbix yang digunakan di lingkungan AWS.Terlepas dari kenyataan bahwa AWS juga memiliki layanan pemantauan seperti Amazon CloudWatch, mengapa Anda harus menggunakan Zabbix?Bagian ini menjelaskan manfaat pemantauan instans EC2 dan instans lainnya, serta proses konfigurasi. Mengapa menggunakan Zabbix daripada Amazon CloudWatch? Di lingkungan AWS, semua infrastruktur dioperasikan oleh AWS, tetapi Anda harus bertanggung jawab atas pengoperasian instans Amazon EC2 itu sendiri dan aplikasi yang dibangun di Amazon EC2. Dengan kata lain, Anda harus memantau aplikasi untuk memastikan bahwa aplikasi tersebut beroperasi dengan benar, dan Anda harus mengambil tindakan saat terjadi masalah.Zabbix adalah kandidat yang baik untuk alat pemantauan semacam ini. Zabbix memiliki keunggulan karena dapat memantau tidak hanya di tempat. Tetapi juga cloud dan lingkungan virtual secara terintegrasi. Sedangkan Amazon CloudWatch standar terbatas untuk memantau sumber daya AWS (CPU, memori, dll.), Zabbix memungkinkan Anda untuk memantau bahkan status aplikasi Anda secara detail. Berikut ini adalah daftar keunggulan lain dari Zabbix. Pemantauan lingkungan terintegrasi dengan beberapa akun AWS Amazon CloudWatch melakukan pemantauan per akun AWS.Zabbix dapat memantau lingkungan beberapa akun AWS, yang dapat memantau sistem bisnis yang terdiri dari beberapa akun.Itu juga dapat mendeteksi anomali tidak hanya dengan peringatan sederhana berdasarkan ambang batas, tetapi juga dengan beberapa ambang batas dan kondisi dalam kombinasi. Itu dapat dikonfigurasi dengan pemberitahuan rinci agar sesuai dengan kondisi operasi yang sebenarnya Amazon CloudWatch dapat memberi tahu Anda dengan pesan jika terjadi anomali.Misalnya, jika sistem Anda sedang dalam pemeliharaan, Anda tidak perlu diberi tahu melalui pesan.Di sinilah Zabbix memungkinkan Anda untuk mengkonfigurasi kasus ini dengan cara yang memungkinkan Anda untuk menyembunyikan pesan yang tidak diinginkan.Dengan cara ini Anda dapat memastikan bahwa Anda hanya diberi tahu ketika ada sesuatu yang benar-benar salah yang perlu ditangani. Tidak ada periode retensi untuk metrik (log pemantauan) Dengan Amazon CloudWatch, metrik dapat disimpan hingga 15 bulan.Selain itu, Anda hanya dapat menyimpan metrik setiap jam selama 15 bulan, dan jika interval pemantauan disetel ke kurang dari 60 detik, Anda hanya dapat menyimpannya selama maksimal 3 jam.Zabbix memungkinkan penyimpanan metrik jangka panjang tanpa mengubah perincian informasi. Cara memantau lingkungan AWS dengan Zabbix Jika Anda ingin menggunakan Zabbix di AWS, Anda perlu membuat instans Amazon EC2 dan DB dan menginstal Zabbix di dalamnya.Setelah instalasi, proses konfigurasi Zabbix pada dasarnya sama dengan proses on-premise, hanya saja Anda perlu mengatur yang berikut ini Akun pengguna (selain pengguna Admin Zabbix, Anda perlu membuat pengguna untuk penggunaan produksi) Agen host Zabbix (menentukan dari mana data dikumpulkan) Item (mengatur data apa yang akan dikumpulkan) Pemicu (menentukan keadaan data yang tidak normal) Tindakan (mendefinisikan tindakan yang akan diambil ketika terjadi kesalahan) Selain itu, Anda dapat mengonfigurasi pengaturan khusus AWS, seperti membuat pengguna di AWS IAM dengan izin yang diperlukan untuk Zabbix, yang akan memungkinkan Zabbix memantau aplikasi dan aspek lain dari lingkungan AWS Anda. Gunakan alat yang tepat untuk kebutuhan pemantauan Anda Tidak semua sistem perusahaan beroperasi secara terpisah, tetapi banyak sistem yang dihubungkan bersama untuk bertukar data dan memastikan konsistensi secara keseluruhan.Dalam lingkungan ini, Zabbix adalah alat yang hebat untuk memantau dan mendeteksi anomali di beberapa server dan sistem.Misalnya, jika aplikasi web berbasis DB memiliki anomali pada server aplikasi web, data dapat dinonaktifkan, misalnya. Di sisi lain, Zabbix memiliki banyak opsi konfigurasi, jadi Anda harus memutuskan apa yang akan dipantau dan bagaimana, dan kondisi apa yang tidak normal. Di sisi lain, Zabbix memiliki banyak pengaturan, jadi Anda harus mendesain operasi dengan tepat apa yang harus dipantau dan apa yang harus dilakukan, dan apa yang harus dilakukan. Tentu saja, untuk sistem kritis, desain seperti itu penting, namun, untuk sistem yang relatif sederhana, seperti "jika suatu proses berhenti, mulai ulang saja", tidak ada yang cocok untuk pemantauan Zabbix.SIOS AppKeeper adalah solusi yang baik untuk kasus seperti itu, karena ia memantau layanan (proses) dari aplikasi yang berjalan pada instans EC2, dan memulai ulang aplikasi jika mendeteksi masalah. Ini memungkinkan pemantauan dan pengoperasian yang sederhana. Tentu saja, tidak “wajib” menggunakan Zabbix di setiap sistem.Dengan menggunakan alat yang tepat untuk setiap jenis pemantauan, Anda akan dapat mengoperasikan sistem Anda dengan lebih efisien. Tambahkan SIOS AppKeeper ke operasi pemantauan dan pemulihan EC2 Anda. Direproduksi dari SIOS
Januari 8, 2021	Bagaimana Memilih Awan Saat Anda Membutuhkan Ketersediaan Tinggi Bagaimana Memilih Awan Saat Anda Membutuhkan Ketersediaan Tinggi Pahami pasar cloud Sejumlah firma analis memperkirakan jumlah penerapan aplikasi, database, dan solusi yang terus meningkat di cloud. Menurut Gartner, perusahaan "beralih ke cloud dengan kecepatan yang men^[1]ingkat". Faktanya, Gartner dan analis lainnya memperkirakan laju migrasi dan penerapan cloud akan terus meningkat, sebagian besar didorong oleh laju inovasi di cloud. Dalam artikel TechTarget oleh Kurt Marko, dari MarkoInsights, Marko mencatat bahwa laju inovasi yang "dilakukan di cloud kemungkinan tidak dapat direplikasi di tempat karena sifat cloud publik terkelola yang elastis, dapat diskalakan, dan sesuai permintaan. jasa." Kami melihat semakin banyak perusahaan yang selama ini menggunakan cloud hanya untuk aplikasi DevOps dan database yang tidak penting untuk bisnis mereka, kini memindahkan aplikasi, ERP, dan database misi penting yang memerlukan perlindungan ketersediaan tinggi ke cloud. Jika Anda sedang mempertimbangkan untuk pindah ke cloud – dan sepertinya memang demikian – ada beberapa kunci yang perlu dipahami saat Anda membutuhkan ketersediaan tinggi. Biasakan diri Anda dengan opsi ketersediaan tinggi cloud Untuk merencanakan solusi ketersediaan yang tepat untuk cloud atau penerapan cloud hybrid, pertimbangkan apa saja poin masalah terkait dengan ketersediaan (99,9% waktu aktif) dan ketersediaan tinggi (99,99% waktu aktif). Anda juga perlu memahami opsi yang tersedia untuk ketersediaan tinggi dengan memperhatikan rencana Anda untuk bermigrasi ke cloud. Analis dan pakar terkemuka menyarankan untuk mencari solusi yang tidak hanya akan mengurangi dan mengurangi rasa sakit saat memigrasi beban kerja Anda, tetapi juga akan memberikan pendekatan yang seimbang dan komprehensif untuk ketersediaan di seluruh masa pakai arsitektur cloud Anda. Perhatikan, sebaiknya pertimbangkan juga solusi yang dapat memberikan perlindungan dan ketersediaan tinggi untuk sebagian dari beban kerja Anda yang suatu hari dapat dikembalikan dari cloud ke lingkungan lokal Anda. Berikut sepuluh hal yang perlu dipertimbangkan saat membandingkan opsi ketersediaan Anda di cloud: 1. Metode penerapan. Apakah mungkin untuk menerapkan solusi ketersediaan yang Anda pertimbangkan menggunakan gambar, CLI, UI, atau solusi berulang lainnya seperti template pembentukan awan atau skrip paket. 2. Persyaratan sistem.Terutama, pertimbangkan persyaratan sistem operasi (OS), disk, CPU, dan memori. 3. Lingkungan penerapan.Apakah opsi ketersediaan Anda hanya mendukung lokal, satu atau beberapa cloud publik, atau dapatkah mereka mendukung campuran, dan / atau penyebaran cloud hybrid. Apakah ada penawaran SaaS juga tersedia? 4. Luas dan kedalaman perlindungan aplikasi. “Breadth” artinya jenis aplikasi, database, front-end, jaringan, dan komponen infrastruktur apa yang dapat dilindungi?Apakah ada kerangka kerja yang fleksibel untuk menambahkan aplikasi dan varian baru? Arti “Kedalaman” – apakah solusinya sadar aplikasi – dan mampu mempertahankan praktik terbaik khusus aplikasi selama proses failover / failback aplikasi? 5. Persyaratan kinerja. Kami sering memikirkan RTO dan RPO, tetapi bagaimana dengan kinerja lain yang membutuhkan solusi Anda. Akankah solusi ketersediaan Anda menyebabkan masalah kinerja saat failover? 6. Persyaratan ketahanan.Seberapa besar cluster yang dapat didukung oleh solusi ketersediaan ?, Berapa banyak kesalahan dan kegagalan yang dapat dideteksi dan dipulihkan. Bagaimana replikasi akan ditangani sambil menjaga metadata tetap sinkron? 7. Dukungan dan pemeliharaan.Apakah vendor ketersediaan memiliki pengalaman dengan berbagai macam kebutuhan dan konfigurasi ketersediaan? Apakah mereka memiliki umur panjang, dan sistem pendukung yang dirancang untuk mengatasi masalah yang mungkin melampaui solusi mereka? Dapatkah mereka membantu Anda meminimalkan gangguan dan waktu henti yang direncanakan selama pengelolaan dan pemeliharaan sistem Anda (tambalan, peningkatan versi, dan pemeliharaan umum). 8. Total biaya kepemilikan.Ada seluruh industri dan layanan yang didedikasikan untuk membantu Anda menghitung total biaya kepemilikan, jadi kami tidak akan membahasnya di sini. Singkatnya, perhitungan Anda akan unik untuk organisasi, penyedia cloud, aplikasi, dan tim TI Anda. Anda harus mempertimbangkan apakah vendor solusi ketersediaan Anda dapat membantu Anda mengidentifikasi strategi untuk menghemat penggunaan, lisensi, dan biaya lainnya? Apakah solusi mengotomatiskan tugas manual, mengurangi waktu kerja TI? 9. Perizinan dan model harga.Bagaimana Anda menggunakan biaya perangkat lunak? Apakah ada biaya langganan, model langganan, penawaran bayar sesuai pemakaian, bawa lisensi Anda sendiri (BYOL), atau kombinasi opsi fleksibel. Bagaimana Anda akan mengaktifkan lisensi produk?Apakah ada server lisensi, layanan lisensi, atau kunci terenkripsi berdasarkan detail penerapan mesin virtual, seperti alamat, nama host, alamat MAC. 10. Dampaknya pada staf TI.Berapa banyak pelatihan dengan solusinya yang dibutuhkan? Berapa banyak intervensi manual yang akan dibutuhkan jika terjadi peristiwa kegagalan aplikasi atau bencana? Apakah ini memerlukan skrip khusus yang perlu dipertahankan? Siapa yang akan bertanggung jawab atas pemeliharaan berkelanjutan? Pertimbangkan manfaat dan kompromi Seperti setiap keputusan penting, Anda perlu memahami pengorbanan Anda dan memilih keseimbangan terbaik untuk memenuhi kebutuhan Anda. Misalnya, baru-baru ini saya meminta seorang teman untuk merekomendasikan sepatu jalan yang bagus. Saya membeli sepasang yang dia ocehkan – memperhatikan betapa ringannya mereka, seberapa kuat dan tahan lama kainnya, dan betapa gayanya mereka.Saya pergi untuk lari jarak jauh pertama saya di dalamnya, dan saya segera menyumbangkan sepasang sepatu “satu lari” pertama saya setelah itu. Ketika saya pergi ke 'Fleet Feet' untuk mendapatkan pendapat ahli, saya mendapatkan sepatu yang lebih berat, dengan kain yang lebih bernapas (juga kurang tahan lama), dan tingkat keburukan yang tak tertandingi. Saya melakukan tradeoff antara penampilan dan fungsi yang sesuai dengan kebutuhan dan anggaran saya. Seperti sepatu lari, tidak ada solusi peluru perak yang sesuai untuk setiap perusahaan, setiap aplikasi, setiap database, dan setiap server dan arsitektur yang memungkinkan. Anda secara resmi bebas untuk berhenti mencarinya. Alih-alih, selesaikan aktivitas menimbang trade-off untuk menentukan apa yang tepat untuk kebutuhan perusahaan Anda. Pikirkan pengorbanan Anda. Misalnya, jika Anda yakin akan menjadi toko Microsoft sepenuhnya, pentingnya dukungan GCP dan AWS seharusnya sedikit lebih rendah dalam proses evaluasi Anda. Pertimbangkan dinamika infrastruktur TI Anda Pikirkan secara holistik tentang ketersediaan di seluruh infrastruktur TI Anda – baik di lokasi maupun di cloud. Alasan untuk melakukannya paling baik dijelaskan dengan analogi lain. Pada tahun 2018, saya menjadi koordinator untuk program penjangkauan memberi makan para tunawisma dan kelaparan di Columbia, Carolina Selatan. Kelompok kami bertemu sekali seminggu untuk menyajikan makanan dan pesan harapan kepada lebih dari 100 pria, wanita dan anak-anak. Saat kami mempertimbangkan untuk memperluas – menambahkan lebih banyak hari dalam seminggu, lebih banyak jam, atau layanan tambahan, kami harus memikirkan jauh di luar persyaratan penjadwalan sederhana. Mengetahui bahwa kami memberikan layanan penting kepada klien yang bergantung pada kami, kami harus mempertimbangkan semua faktor yang memengaruhi kemampuan kami untuk memberikan layanan tersebut secara konsisten untuk jangka panjang, seperti: biaya, usia anggota tim kami, kewajiban luar , metode alternatif untuk mencapai tujuan kami, faktor risiko, dan dinamika lain dalam organisasi induk kami. Saat Anda memilih solusi, setelah Anda memahami pasar, membiasakan diri dengan opsi, dan menimbang kompromi, langkah terakhir adalah memperhitungkan berbagai dinamika lain di lingkungan Anda secara keseluruhan. Akankah solusi tersebut memenuhi kebutuhan bisnis Anda secara keseluruhan? Akankah data penting Anda dilindungi dari kehilangan? Akankah produktivitas pengguna akhir Anda dilindungi dari waktu henti? Pelatihan apa yang akan diperlukan untuk pindah ke cloud dan bagaimana hal itu akan memengaruhi kemampuan Anda untuk mengelola atau mempertahankan solusi yang Anda pilih? Peran TI apa yang akan ditambahkan, dihapus, atau diubah dalam perjalanan cloud Anda?Akankah tanggung jawab untuk ketersediaan aplikasi berpindah ke pemilik lini bisnis mana pun? Dan bagaimana perubahan dalam tanggung jawab, atau pembentukan tim akan meningkatkan atau menurunkan potensi kesuksesan Anda secara keseluruhan. Pertimbangkan apakah tim Anda perlu mengambil pendekatan langkah demi langkah, memigrasi beban kerja yang lebih kecil terlebih dahulu. Sebagai Wakil Presiden Pengalaman Pelanggan, saya telah melihat berbagai macam perencanaan migrasi cloud – beberapa langsung yang lainnya sangat mengganggu. Dalam satu contoh, perpindahan pelanggan ke cloud sangat kontroversial karena manajemen melihatnya sebagai peluang untuk menghilangkan seluruh departemen TI. Saya tidak menyarankan Anda untuk bermain politik, tetapi Anda harus menyadari semua faktor yang berperan dalam proyek kompleks ini. Bermigrasi ke cloud diharapkan dapat menghemat uang, waktu, dan sumber daya sambil meningkatkan ketersediaan dan ketahanan. Apa pun cloud yang Anda pilih, pastikan Anda mempertimbangkan tip berikut dan memilih solusi ketersediaan terkait yang memberi Anda fleksibilitas untuk memberikan perlindungan yang Anda butuhkan dalam konfigurasi yang Anda inginkan. Pelajari lebih lanjut tentang opsi ketersediaan tinggi cloud dengan SIOS. – Cassius Rhue, Wakil Presiden Pengalaman Pelanggan, SIOS Direproduksi dengan izin dari SIOS
Desember 30, 2020	Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik Tips dari film – Multiplisitas Multiplicity adalah film komedi fiksi ilmiah Amerika tahun 1996 yang dibintangi Michael Keaton sebagai Doug Kinney, seorang pekerja konstruksi sibuk yang berjuang untuk menyediakan waktu bagi keluarganya dan pekerjaannya yang menuntut. Saat seorang ilmuwan menawarkan untuk mengkloningnya, Doug setuju untuk mempermudah pemenuhan jadwal dan komitmennya. Tapi kemudian salinan dirinya mulai membuat salinan dari dirinya sendiri. Pada saat salinan terakhir dibuat, intinya sudah jelas. Kloning mungkin tidak semudah yang diharapkan, atau setidaknya disertai dengan beberapa peringatan, tantangan, dan efek samping yang kuat. Episode orisinal Star Trek yang terkenal "Trouble with Tribbles" mengilustrasikan hal serupa. Seperti kloning di layar besar (atau kecil), kloning di cloud adalah alat yang hebat, tetapi bukannya tanpa tantangan. Tips tentang cara mendapatkan hasil yang lebih baik saat Anda mengkloning ketersediaan di cloud 1. Menggandakan sistem operasional Ini terdengar jelas, tetapi saya telah melihat itu terjadi lebih dari sekali di lingkungan perusahaan yang nyata. Jika Anda mengkloning sistem non-fungsional Anda, klon tersebut akan sama-sama tidak berfungsi dan bermasalah saat Anda memulihkannya. Pastikan bahwa klon yang Anda buat berasal dari sistem operasional dan fungsional. 2. Sinkronkan data ke disk dan sinkronkan ulang saat pemulihan Integritas sistem file sangat penting. Jika Anda tidak memastikan aplikasi dan / atau VM Anda dalam keadaan konsisten, sebagian besar vendor tidak akan menjamin gambar yang dibuat yang dihasilkan. Karena snapshot hanya menangkap data yang telah ditulis ke volume Anda pada saat perintah snapshot dikeluarkan, ini mungkin mengecualikan data apa pun yang telah di-cache oleh aplikasi atau sistem operasi apa pun. Memastikan data telah disinkronkan dengan benar ke sistem file merupakan langkah penting, dan sangat penting dalam lingkungan cluster. Integritas sistem file juga penting untuk diingat saat Anda memulihkan dari gambar. Jika Anda menggunakan replikasi data dan Anda memulihkan gambar sebagai sumber atau target di cluster, pastikan kedua node sinkron adalah yang terpenting. Kegagalan untuk melakukannya dapat menyebabkan kesalahan sistem file pada failover atau peralihan, atau bahkan potensi kehilangan data. Klon ketersediaan di cloud untuk mendapatkan hasil yang Anda inginkan. 3. Hentikan instance Anda Banyak lingkungan tidak mengharuskan Anda menghentikan instans untuk membuat gambar, dan beberapa, seperti AWS akan melakukan langkah mematikan node sebelum membuat salinan.Namun, banyak alat dan situs merekomendasikan untuk memastikan aplikasi dihentikan dan akses sistem file disinkronkan dengan benar untuk menghindari kerusakan, kehilangan integritas, atau membuat gambar yang mengalami masalah saat memulai, menghentikan, atau menjalankan aplikasi yang diinstal. 4. Beri label semua yang ada di cloud (node, disk, NIC, semuanya) Saat membuat klon adalah operasi gratis, disk dan komponen yang dihasilkan biasanya tidak.AWS menyatakan, misalnya, Anda "dikenai biaya untuk snapshot hingga Anda membatalkan pendaftaran gambar dan menghapus snapshot." Ketika sesuatu tidak diberi label, mengetahui apa yang digunakan atau tidak digunakan dan mengapa hal itu dibuat bisa menjadi masalah. Itu juga menjadi sasaran ingatan sekilas atau konsentrasi anggota tim yang ada.Beri label semuanya. 5. Sering-seringlah memangkas klon dan snapshot (penghematan biaya dan penghematan sakit kepala) Memangkas snapshot dan klon lama tidak hanya baik untuk penghematan biaya, tetapi juga baik untuk mengurangi sakit kepala.Snapshot yang lebih lama berisiko memunculkan kembali kerentanan yang telah diatasi atau diselesaikan di salinan yang lebih baru.Sebagai Wakil Presiden Pengalaman Pelanggan di SIOS Technology Corp., Saya melihat konsekuensinya secara langsung saat kami bekerja dengan pelanggan yang memulihkan dari snapshot. Mereka mengalami beberapa masalah saat memulai ulang aplikasi. Setelah pemecahan masalah, kami memutuskan bahwa klon menjalankan perangkat lunak keamanan versi lama. Kredensial dan metadata yang disimpan dalam profil pengguna tidak lagi disinkronkan dengan data aplikasi aktual yang disimpan di drive data yang dipasang secara eksternal. 6. Batasi atau batasi kloning kloning di cloud Terakhir, tidak semua yang Anda lakukan di cloud perlu di-clone. Pertimbangkan untuk membatasi jenis beban kerja yang akan Anda klon dan batasi jumlah atau peran yang dapat membuat klon di lingkungan Anda. Dalam film tersebut, ketika klon Doug memicu serangkaian duplikasi mereka sendiri, Doug (Michael Keaton) yang sudah kewalahan dipaksa untuk mengerahkan energi ekstra untuk mengelola banyak klonnya sambil mencoba menyembunyikan kekacauan yang ia buat dari istrinya. Mencapai ketersediaan klon di cloud dengan hasil yang lebih baik tidaklah sulit. Kloning dengan hati-hati untuk menghindari membuat lebih banyak pekerjaan dan menambah risiko dari alat yang seharusnya membuat pekerjaan Anda lebih mudah dan lingkungan Anda lebih aman. – Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan Direproduksi dari SIOS
Desember 26, 2020	Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1 Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1 SIOS terus memperbarui produk kami untuk memenuhi kebutuhan pelanggan yang terus berkembang akan ketersediaan tinggi untuk aplikasi penting. Kami sangat senang mengumumkan ketersediaan umum SIOS Protection Suite untuk Linux versi 9.5.1!Fitur rilis ini menambahkan dukungan untuk lebih banyak jenis platform dan penyempurnaan pada fitur antarmuka baris perintah kami. Pembaruan utama termasuk Dukungan untuk sistem operasi dan platform berikut: VMware Vsphere 7, Red Hat Enterprise Linux (RHEL) 8.2, Oracle Linux 8.2, CentOS 8.2, SUSE Linux Enterprise (SLES) 12 SP5, RHEL 7.8, CentOS 7.8, Oracle Linux 7.8, SLES 15 SP2 CLI Auto Install dengan skrip pengaturan yang ditingkatkan – untuk implementasi yang lebih cepat dan mudah Dukungan CLI yang diperluas untuk ARK dan Kloning – memungkinkan penerapan beberapa klaster yang sederhana dan konsisten Direproduksi dengan izin dari SIOS
Desember 22, 2020	Enam Alasan Migrasi Cloud Anda Terhenti Enam Alasan Migrasi Cloud Anda Terhenti Semakin banyak pelanggan yang mencari keuntungan dari fleksibilitas, skalabilitas, dan kinerja cloud. Karena jumlah aplikasi, solusi, pelanggan, dan mitra yang melakukan pergeseran meningkat, pastikan migrasi Anda tidak terhenti. Hindari Enam Alasan Berikut Berhenti Migrasi Cloud 1. Rencana proyek migrasi cloud yang tidak lengkap Perencanaan proyek secara luas dianggap sebagai kontributor utama keberhasilan proyek. Perencanaan memainkan peran penting dalam membantu memandu pemangku kepentingan, tim implementasi yang beragam, dan mitra melalui fase proyek. Perencanaan membantu mengidentifikasi tujuan yang diinginkan, menyelaraskan sumber daya dan tim dengan tujuan tersebut, mengurangi risiko, menghindari tenggat waktu yang terlewat, dan pada akhirnya memberikan solusi yang sangat tersedia di cloud.Rencana yang tidak lengkap dan perencanaan yang tidak lengkap sering menjadi penyebab utama proyek terhenti.Pada jam kesembilan ketergantungan kunci diidentifikasi. Selama reboot server yang tidak terduga, pemantauan aplikasi dan lubang HA teridentifikasi (lihat di bawah). Pastikan migrasi cloud Anda memiliki rencana, dan kerjakan rencana tersebut. 2. Rekayasa berlebihan di lokasi “Ini adalah cara kami melakukannya di node lokal kami,” adalah ungkapan yang memulai percakapan pelanggan baru-baru ini. Pelanggan terlibat dengan Edmond Melkomian, Manajer Proyek untuk Layanan Profesional SIOS, ketika upaya mereka untuk bermigrasi ke cloud terhenti.Selama sesi penemuan, Edmond dapat mengungkap sejumlah item yang direkayasa secara berlebihan terkait dengan arsitektur lokal versus cloud. Untuk beberapa proyek, mereproduksi apa yang telah dilakukan di tempat bisa menjadi resume untuk pembengkakan, kerumitan, dan penundaan. Analisis arsitektur dan rencana migrasi Anda dan hilangkan tanpa ampun komponen dan desain yang direkayasa secara berlebihan, terutama dengan jaringan dan penyimpanan. 3. Kurang penyediaan Mengontrol biaya dan mencegah penyebaran adalah aspek penting dan kritis dari migrasi cloud.Namun, beberapa pelanggan, yang cemas tentang biaya per jam dan biaya terkait untuk disk dan bandwidth jatuh ke dalam perangkap kekurangan penyediaan.Dalam perangkap ini, resource berukuran tidak tepat, baik disk yang memiliki karakteristik kecepatan yang salah, menghitung resource dengan CPU atau footprint memori yang salah, atau cluster dengan jumlah node yang salah.Dalam kasus yang tidak tersedia seperti itu, masalah muncul saat User Acceptance Test (UAT) dimulai dan beban kerja yang diharapkan / diantisipasi membuat log jam pada sumber daya yang terlalu kecil.Atau pengoptimalan biaya dari node target tidak dapat menangani sumber daya dengan benar dalam skenario failover. Meskipun mengubah ukuran mesin virtual di cloud adalah proses yang sederhana, masalah ukuran ini sering kali menimbulkan penundaan saat arsitek dan Kepala Petugas Keuangan mencoba memahami dampak penyediaan ulang sumber daya. 4. Proses TI internal Setiap perusahaan besar memiliki serangkaian proses internal, dan kemungkinan besar tim dan perusahaan Anda tidak terkecuali.Proses TI biasanya merupakan kunci di antara proses yang dapat berdampak besar pada keberhasilan strategi migrasi cloud Anda. Di masa lalu, banyak perusahaan memiliki proses permintaan dan akuisisi yang lama, termasuk penawaran, panduan ukuran, persetujuan pesanan, persiapan dan konfigurasi server, dan penerapan akhir.Proses cloud telah secara dramatis mengubah cara komputasi, penyimpanan, dan sumber daya jaringan, antara lain, diperoleh dan digunakan.Namun, jika proses Anda tidak mengikuti kecepatan cloud, migrasi Anda mungkin menemui hambatan saat rencana berubah. 5. Perencanaan Ketersediaan Tinggi yang Buruk Alasan lain mengapa migrasi cloud dapat terhenti melibatkan perencanaan ketersediaan tinggi. Ketersediaan tinggi membutuhkan lebih dari satu paket alat atau lisensi perusahaan.HA membutuhkan desain sistem yang cermat, teliti, dan bijaksana.Saat menerapkan solusi HA, rencana Anda perlu mempertimbangkan kapasitas, redundansi, dan persyaratan untuk pemulihan dan koreksi. Dengan rencana, persyaratan diidentifikasi dengan benar, solusi yang diusulkan, risiko dipikirkan, dan dependensi untuk penerapan dan validasi dikelola. Tanpa rencana, proyek dan penerapan rentan terhadap risiko, satu titik masalah kegagalan, kesesuaian yang buruk, dan lapisan yang hilang serta tingkat perlindungan aplikasi atau strategi pemulihan.Seringkali ketika ada kekurangan perencanaan HA, proyek terhenti sementara persyaratan diselesaikan. 6. Pengujian tidak lengkap atau tidak valid Ron, partner yang memigrasikan pelanggan akhirnya ke cloud, berencana untuk live-live selama tiga hari akhir pekan mendatang. Poin keputusan terakhir untuk 'go / no-go' adalah sekumpulan pengujian penerimaan pengguna di server penahapan.Tes pertama gagal.Untuk mengganti waktu yang hilang karena hambatan migrasi lainnya, Ron dan tim melewatkan sejumlah kasus uji yang terkait dengan pengintegrasian koleksi akhir perangkat lunak keamanan dan cadangan pada OS terbaru dengan tambalan pendukung. Beban simulasi, yang pertama pada server yang baru dibuat, membuat serangkaian masalah dalam arsitektur Ron termasuk bug kernel, masalah penyediaan CPU dan memori, serta masalah kapasitas dan tata letak penyimpanan. Proyek ini ditunda selama lebih dari empat minggu untuk mengatasi kepercayaan pelanggan, pengujian dan validasi yang tepat, pengubahan ukuran dan arsitektur, serta menerapkan perbaikan perangkat lunak dan OS. Janji-janji cloud sangat menarik, dan migrasi cloud yang terencana dengan baik akan menempatkan Anda dan tim Anda untuk memanfaatkan keuntungan ini. Baik Anda sedang memulai atau di tengah migrasi cloud, kami harap artikel ini membantu Anda lebih waspada terhadap masalah umum sehingga Anda dapat menghindarinya. – Cassius Rhue, Wakil Presiden, Pengalaman Pelanggan Direproduksi dari SIOS

Results 316-320 of 939
< Page 64 of 188 >

Bergabunglah dengan Milis Kami

First Name Last Name Email Address
Pencarian