Archives for Desember 2020

Cara Mengkloning Ketersediaan Di Cloud Dengan Hasil Lebih Baik

Desember 30, 2020 by Jason Aw Leave a Comment

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

Rilis Produk Baru: SIOS Protection Suite for Linux 9.5.1

Desember 26, 2020 by Jason Aw Leave a Comment

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

Enam Alasan Migrasi Cloud Anda Terhenti

Desember 22, 2020 by Jason Aw Leave a Comment

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

Menghitung Ketersediaan Aplikasi di Cloud

Desember 18, 2020 by Jason Aw Leave a Comment

Menghitung Ketersediaan Aplikasi di Cloud

Saat menerapkan aplikasi bisnis penting di cloud, Anda ingin memastikan ketersediaannya sangat tinggi. Kabar baiknya adalah jika Anda merencanakan dengan benar, Anda dapat mencapai 99,99% (4-sembilan) ketersediaan atau lebih. Namun, menghitung ketersediaan Anda yang sebenarnya mungkin tidak sesederhana kelihatannya.

Saat mempertimbangkan ketersediaan, Anda harus mempertimbangkan komponen utama yang memungkinkan akses ke aplikasi Anda, yang akan saya sebut rantai ketersediaan. Komponen rantai ketersediaan adalah:

Menghitung
Jaringan
Penyimpanan
Aplikasi
Layanan yang bergantung

Aplikasi Anda hanya tersedia sebagai tautan terlemah Anda, dan waktu henti Anda meningkat secara eksponensial dengan setiap tautan tambahan yang Anda tambahkan ke rantai.Mari kita periksa setiap tautan.

Hitung Ketersediaan

Masing-masing dari tiga penyedia layanan cloud utama memiliki beberapa kesamaan. Satu kesamaan di ketiga platform adalah perjanjian tingkat layanan (SLA) yang akan mereka janjikan untuk komputasi.

SLA untuk ketiga penyedia cloud publik untuk VM saat Anda memiliki dua atau lebih VM yang dikonfigurasi di berbagai zona ketersediaan adalah 99,99%.Perlu diingat, SLA ini hanya menjamin aksesibilitas jarak jauh dari salah satu VM pada waktu tertentu, SLA tidak menjanjikan ketersediaan layanan atau aplikasi yang berjalan di dalam VM.Jika Anda menerapkan satu VM dalam satu pusat data, SLA ini bervariasi dari "90% setiap jam" (AWS) hingga 99,5% (Azure dan GCP) atau 99,9% (VM tunggal Azure saat menggunakan SSD Premium).

Ketersediaan tinggi sebenarnya dimulai dari 99,99%, jadi langkah pertama adalah memastikan aplikasi Anda tersedia adalah memastikan aplikasi didistribusikan ke dua atau lebih VM yang menjangkau zona ketersediaan. Dengan dua VM yang tersebar di dua zona ketersediaan, yang memberi Anda 99,99% ketersediaan dari setidaknya satu VM tersebut, Anda dapat berteori bahwa jika Anda memiliki tiga VM yang tersebar di tiga zona ketersediaan, ketersediaan Anda akan lebih besar dari 99,99%. Meskipun SLA penyedia cloud tidak akan pernah menjamin melebihi ketersediaan 99,99% terlepas dari jumlah zona ketersediaan yang digunakan, jika Anda menggunakan statistik murni, Anda mungkin sampai pada kesimpulan bahwa ketersediaan Anda dapat melonjak hingga 99,9999999% atau 8-sembilan dari ketersediaan, waktu henti 26,30 milidetik per bulan.

1 – (. 0001 * .0001) = .99999999

99,999999% ketersediaan dengan tiga zona ketersediaan?

Jangan seenaknya mengutip angka itu. Namun perlu diingat bahwa masuk akal jika dua zona ketersediaan dapat memberi Anda ketersediaan 99,99%. Masuk akal bahwa tiga zona ketersediaan akan memberi Anda sesuatu yang secara signifikan lebih dari 99,99% ketersediaan.

Hitung hanyalah salah satu tautan dalam rantai ketersediaan. Kami masih harus menangani jaringan, penyimpanan, dan layanan lain yang bergantung, yang semuanya mewakili kemungkinan titik kegagalan.

Ketersediaan Jaringan

Agar aplikasi Anda tersedia, setiap hop jaringan antara klien dan aplikasi dan semua sumber daya yang bergantung pada aplikasi, harus tersedia dan bekerja dalam rentang latensi yang dapat ditoleransi. Anda perlu memahami tautan jaringan antara server basis data, server aplikasi, server web, dan klien untuk mengetahui dengan tepat di mana jaringan mungkin gagal. Ingat, semakin banyak tautan dalam rantai ketersediaan Anda, semakin rendah ketersediaan Anda secara keseluruhan.

Meskipun ketersediaan jaringan antara VM dalam vNet yang sama tercakup dalam SLA komputasi standar, ada layanan jaringan lain yang mungkin Anda gunakan. Berikut adalah beberapa contoh layanan jaringan yang dapat Anda manfaatkan yang akan memengaruhi ketersediaan aplikasi secara keseluruhan.

Rute Ekspres – 99,95%
Gerbang VPN – 99,9% hingga 99,95%
Load Balancer – 99,99%
Manajer Lalu Lintas – 99,99%
Penyeimbang Beban Elastis – 99,99%
Sambungan Langsung – 99,9% – 99,99%

Berdasarkan apa yang telah kita pelajari sejauh ini, mari kita lihat ketersediaan aplikasi yang diterapkan di dua zona ketersediaan.

Ketersediaan komputasi 99,99%

Ketersediaan penyeimbang beban 99,99%

.9999 * .9999 = .9998

Ketersediaan 99,98% = ~ 9 menit waktu henti per bulan

Sekarang setelah kita membahas ketersediaan komputasi dan jaringan, mari beralih ke penyimpanan.

Ketersediaan Penyimpanan

Sekarang di sinilah ceritanya menjadi sedikit berbulu. Lihat SLA penyimpanan berikut

https://azure.microsoft.com/en-us/support/legal/sla/storage/v1_5/

https://cloud.google.com/storage/sla

https://aws.amazon.com/compute/sla/

Tampaknya cukup jelas bahwa Azure dan Google memberi Anda SLA 99,9% pada solusi penyimpanan blok. AWS tidak menyebutkan EBS secara khusus di sini. Mereka hanya berbicara tentang VM dan mengukur ketersediaan VM instance tunggal mereka menurut jam, bukan menurut bulan seperti yang dilakukan penyedia cloud lainnya. Demi diskusi, mari gunakan jaminan ketersediaan 99,9% yang telah dipublikasikan oleh Azure dan GCP.

Membangun dari contoh kita sebelumnya, mari tambahkan beberapa penyimpanan ke persamaan.

Ketersediaan komputasi 99,99%

Ketersediaan penyeimbang beban 99,99%

99,9% disk yang dikelola

.9999 * .9999 * .999 = .9988

Ketersediaan 99,88% = ~ 53 menit waktu henti per bulan.

Waktu henti 53 menit jauh lebih banyak daripada waktu henti 9 menit yang kami hitung di contoh sebelumnya. Apa yang dapat kita lakukan untuk meminimalkan dampak dari ketersediaan penyimpanan 99,9%? Kami harus membangun lebih banyak redundansi dalam penyimpanan!

Untungnya, kami biasanya menyertakan redundansi penyimpanan saat merencanakan ketersediaan aplikasi. Misalnya, saat kami menyiapkan server web, setiap server web biasanya akan menyimpan data pada disk yang terpasang secara lokal. Saat menyebarkan pengontrol domain, Microsoft Active Directory menangani penggandaan informasi AD di semua pengontrol domain. Dalam kasus seperti SQL Server, kami memanfaatkan Grup Ketersediaan Selalu Aktif atau SIOS DataKeeper untuk menjaga data tetap sinkron di seluruh disk yang terpasang secara lokal.

Semakin banyak salinan data yang telah kami distribusikan ke berbagai zona ketersediaan, semakin besar kemungkinan kami dapat bertahan dari kegagalan.

Misalnya, aplikasi yang menyimpan datanya di dua disk yang berbeda di zona ketersediaan yang berbeda akan mendapatkan keuntungan dari redundansi dan daripada ketersediaan 99,9%, aplikasi tersebut lebih cenderung mencapai ketersediaan penyimpanan sebesar 99,9999%.

1 – (.001 * .001) = .999999

Jika kita memasukkannya ke persamaan sebelumnya, gambar mulai terlihat sedikit lebih cerah.

.9999 * .9999 * .999999 = .9998

Ketersediaan 99,98% = ~ 9 menit waktu henti

Dengan menduplikasi data di beberapa AZ, dan oleh karena itu, beberapa disk, kami telah secara efektif mengurangi waktu henti yang terkait dengan penyimpanan cloud.

Ketersediaan Aplikasi Dan Layanan Bergantung

Anda telah melakukan semua yang dapat Anda lakukan untuk memastikan ketersediaan komputasi, jaringan, dan penyimpanan. Tapi bagaimana dengan aplikasinya sendiri? Beberapa aplikasi dapat menskalakan dan menyediakan redundansi dengan load balancing antara beberapa contoh aplikasi yang sama. Pikirkan pertanian server web tipikal Anda di mana Anda biasanya dapat memuat permintaan web keseimbangan antara lima server. Jika Anda kehilangan satu server, penyeimbang beban hanya menghapusnya dari rotasinya hingga kembali responsif.

Aplikasi lain membutuhkan lebih banyak perawatan dan pemantauan. Ambil contoh SQL Server. Biasanya Grup Ketersediaan Selalu Aktif atau Mesin Virtual Failover Cluster digunakan untuk memantau ketersediaan database dan melakukan tindakan pemulihan jika database menjadi tidak responsif karena kegagalan tingkat aplikasi atau sistem. Meskipun tidak ada SLA yang diterbitkan untuk solusi ketersediaan SQL Server, secara umum diterima bahwa ketika dikonfigurasi dengan benar untuk ketersediaan tinggi, SQL Server dapat menyediakan ketersediaan 99,99%.

Anda dapat mengandalkan layanan berbasis cloud lainnya, seperti Active Directory yang dihosting, DNS yang dihosting, layanan mikro, atau bahkan ketersediaan portal cloud itu sendiri, semuanya harus diperhitungkan dalam persamaan ketersediaan Anda secara keseluruhan.

Ringkasan

Ketersediaan aplikasi adalah jumlah dari semua bagian yang bergerak. Menghemat hanya di satu area dapat secara eksponensial memengaruhi ketersediaan aplikasi Anda secara keseluruhan. Luangkan waktu Anda dan selidiki semua tautan dalam rantai ketersediaan Anda untuk menemukan kelemahan termasuk komputasi, jaringan, penyimpanan, aplikasi, dan layanan yang bergantung.

Secara umum, angka yang disajikan di sini mudah-mudahan merupakan skenario kasus terburuk dan ketersediaan Anda yang sebenarnya harus melebihi SLA yang dipublikasikan. Kerjakan pekerjaan rumah Anda dan waspadalah terhadap layanan apa pun yang tidak dapat menjamin ketersediaan 99,99%, ambang umum dari apa yang dianggap sangat tersedia.

Kesalahan manusia dan keamanan tidak dibahas dalam artikel ini. Anda dapat membuat aplikasi Anda tersedia semaksimal mungkin. Namun, jika Anda belum mengambil langkah untuk mengamankan aplikasi Anda dari ancaman eksternal dan kesalahan manusia yang bodoh, maka semua taruhan dibatalkan dalam hal ketersediaan.

Menggunakan Datadog untuk Amazon EC2 Monitoring? Sandingkan dengan SIOS AppKeeper untuk Remediasi Otomatis

Desember 11, 2020 by Jason Aw Leave a Comment

Menggunakan Datadog untuk Amazon EC2 Monitoring? Sandingkan dengan SIOS AppKeeper untuk Remediasi Otomatis

Pernahkah Anda berpikir, “Alangkah baiknya jika Datadog dapat memantau layanan Amazon EC2 kami dan secara otomatis memulai ulang ketika mendeteksi kegagalan?” Saya memikirkan hal yang sama, dan memutuskan untuk mencobanya sendiri.

SIOS AppKeeper secara otomatis memantau instans Amazon EC2 untuk kegagalan dan secara otomatis memulai ulang instans atau bahkan melakukan boot ulang layanan ketika kegagalan terdeteksi.Saya berpikir, "Bagaimana jika kita menggabungkan kemampuan pemantauan Datadog dengan kemampuan remediasi otomatis AppKeeper?"

Itu berhasil, dan inilah cara saya melakukannya.

Jika Anda sudah menggunakan Datadog dan tertarik untuk mencobanya sendiri, silakan daftar di bagian akhir artikel ini untuk mengakses API kami.

Berikut adalah langkah-langkah yang saya ambil untuk menyiapkan AppKeeper agar menerima peringatan dari Datadog dan memulai ulang server web di Amazon EC2 saat waktu henti terdeteksi.

Untuk menjalankan eksperimen ini dengan sukses, kami sudah memiliki akun Datadog, akun AppKeeper, dan server web NGINX yang berjalan di Amazon EC2 (menggunakan Linux 2).

Bagaimana mengintegrasikan Datadog dengan AppKeeper untuk menyediakan remediasi otomatis

Langkah Satu: Dapatkan Restart API Token dari AppKeeper

Minta Token API untuk integrasi Datadog dari formulir ini:

https://mk.sios.jp/BC_AppKeeper_Datadog_api_application

Jika Anda memintanya dari formulir, token akan dikirim ke alamat email yang Anda berikan.

Langkah Kedua: Buat penyewa di AppKeeper

Langkah selanjutnya adalah mendaftarkan akun AWS tempat instans yang dipantau berada di AppKeeper. (AppKeeper menyebut akun AWS terdaftar sebagai "penyewa".)

https://sioscoati.zendesk.com/hc/en-us/articles/900000123406-Quick-Start-Guide#h_39404cfb-4a76-450f-99c2-e197cc63e50d

Langkah Tiga: Buat Peran IAM di AWS

Saya kemudian membuat Peran IAM di AWS (Anda memerlukan ini untuk menyiapkan akun AppKeeper Anda).Berikut adalah petunjuk jika Anda tidak terbiasa dengan proses ini.

Langkah Empat: Tambahkan penyewa di AppKeeper

Langkah selanjutnya adalah menambahkan "penyewa" di AppKeeper (AppKeeper menganggap akun AWS sebagai "penyewa").Berikut ini tautan ke petunjuk mendetail untuk melakukan ini.

Langkah Lima: Siapkan Pengujian Sintetis di Datadog

Saya kemudian perlu mengonfigurasi pemantauan garis besar Datadog untuk server Nginx (contoh EC2) yang ingin kami pantau.Berikut cara melakukannya:

Buka dasbor Datadog dan pilih UX Monitoring> Synthetic Tests dari menu.

Klik tomb[New Test]ol di sudut kanan atas dan pilih untuk me[New API Test]mbuat kasus pemantauan garis besar.

Masukkan informasi berikut dalam formulir untuk membuat kasus pemantauan garis besar.

Pilih Jenis Permintaan
Pilih "HTTP".
Tentukan Permintaan:
Atur nilai-nilai berikut.
URL: DAPATKAN http: // {{{EC2 IP address}}
Nama: AppKeeper Datadog Integration Test (nama apa saja)
Lokasi: Tokyo

3. Tentukan frekuensi pengujian
Tidak ada perubahan

4. Tentukan pernyataan
Klik "New Assertion" dan atur nilai berikut

Kapan[status code] [is]:[200]

5. Tentukan Kondisi Peringatan
Tidak ada perubahan

6.Beri tahu Tim Anda
Tidak ada perubahan

Langkah Enam: Jalankan uji Sintetis di Datadog

Setelah input di atas selesai, tekan "Buat Tes" untuk membuat kasus uji untuk pemantauan eksternal.

Hasilnya terlihat dan kita dapat melihat bahwa webserver bekerja dengan baik di bagian "Hasil Tes".

Hanya itu yang harus dilakukan untuk mengonfigurasi pemantauan Synthetics menggunakan Datadog.

Langkah Tujuh: Atur AppKeeper untuk menerima peringatan Synthetics

Selanjutnya saya harus mengatur AppKeeper sebagai tujuan notifikasi.Dari menu Datadog, buka Integrasi dan pilih tab Integrasi.

Di kotak telusur, masukkan "Webhook" untuk menemukan integrasi Webhooks.

Klik "Tersedia" untuk mengaktifkan integrasi Webhooks di akun Datadog Anda. (Setelah diaktifkan, ini akan muncul di kolom "Terpasang".)

Klik "Configure" untuk membuka halaman konfigurasi integrasi Webhooks.

Di kolom "Webhook" di bagian bawah halaman, klik "Baru +" untuk membuat tujuan notifikasi Webhooks baru. Untuk parameternya, masukkan berikut ini

Nama: Nama integrasi (nama apa saja)

URL: https://api.appkeeper.sios.com/v2/integration/ {{AWS account ID}} / actions / recover

Muatan:

{

“InstanceId”: “{{EC2 Instance ID}}”,

“Nama”: “nginx”

}

Header Khusus: Centang kotak dan masukkan yang berikut ini

{
“Jenis konten”: “application / json”,
“Accept”: “application / json”,
"Appkeeper-integration-token": "{{Dapatkan AppKeeper token integrasi eksternal Token yang diperoleh di}}"
}

Setelah selesai, tekan "Simpan".

Langkah Delapan: Menghubungkan AppKeeper ke tes Synthetics

Selanjutnya, saya harus mengonfigurasi AppKeeper (integrasi Webhooks terdaftar) untuk dipanggil ketika peringatan pemantauan Synthetics terjadi.

Buka kasus pengujian yang Anda siapkan di "Mengonfigurasi Pemantauan Sintetis dengan Datadog" dari Pemantauan UX> Pengujian Sintetis di menu.

Pilih "Edit detail pengujian" dari kotak roda gigi kanan atas dan masukkan nilai berikut di "5. Beri tahu Tim Anda ”untuk menyimpan perubahan.

@webhook – {{Nama integrasi Webhook di Datadog}}

※ Anda dapat mengatur "renotify jika monitor belum diselesaikan".Anda dapat mencoba lagi jika AppKeeper gagal memulihkan untuk pertama kalinya.Ini tidak diperlukan untuk tujuan pengujian, tetapi kami menyarankan Anda untuk mengaturny[10 minutes]a ke (interval minimum).

Penyiapan sekarang selesai.

Langkah Sembilan: Konfirmasikan integrasi dengan menjalankan tes lagi

Saya kemudian mengonfirmasi bahwa AppKeeper akan memulihkan server web jika Datadog mendeteksinya tidak aktif.

Buka kasus uji pemantauan Synthetics yang baru saja Anda siapkan dari UX Monitoring> Synthetic Tests di Datadog.

Klik "Lanjutkan Tes" di pojok kanan atas dan aktifkan pemantauan Synthetics.

Sekarang Datadog akan melakukan pemantauan Synthetics secara berkala.

Hasil Tes menunjukkan bahwa server berhasil diakses.

Selanjutnya, saya membuat server web pseudo-failure untuk menguji remediasi otomatis AppKeeper.

Karena sulit untuk menyebabkan kegagalan yang nyata, saya menghentikan layanan dan membuat situasi di mana Anda tidak dapat melihat halaman web.Untuk melakukan ini, saya terhubung ke instance EC2 di mana server Nginx diinstal menggunakan SSH dan menghentikan Nginx.

sudo systemctl menghentikan nginx

Setelah menunggu sebentar, Datadog mendeteksi bahwa server web tidak dapat diakses lagi.

Halaman Tes Sintetis di Datadog juga menunjukkan bahwa kasus pengujian telah gagal.

Jika kasus uji gagal, Datadog akan memberi tahu AppKeeper bahwa pemantauan Synthetics telah gagal.

Ketika AppKeeper menerima notifikasi, secara otomatis akan mencoba untuk memulai ulang Nginx.

Jadi, jika Anda menunggu sebentar, Anda akan melihat bahwa pemeriksaan pemantauan Sintetik Datadog akan lulus lagi.

Selain itu, jika Anda masuk ke dasbor AppKeeper, Anda akan melihat bahwa pemulihan telah dilakukan.

–

Dalam latihan ini saya menggunakan server web (Nginx) sebagai contoh untuk mengotomatiskan proses mendeteksi kegagalan dengan Datadog dan memulihkan layanan dengan AppKeeper.

Otomatisasi serupa dapat dicapai dengan mengintegrasikan Datadog dengan EventBridge dan Lambda atau dengan membuat skrip khusus.

Namun, jika Anda sering menambahkan instans target atau memulai ulang berbagai layanan, biaya dan kerumitan pemeliharaan EventBridge dan Lambda atau skrip akan meningkat.

Integrasi AppKeeper yang telah terbukti dengan Datadog dan kemudahan untuk menambahkan instance target ke aplikasi Anda membuatnya mudah untuk menambahkan otomatisasi ke lingkungan DevOps Anda untuk mengurangi waktu henti.

Jika saat ini Anda menggunakan Datadog dan ingin mencoba AppKeeper's Restart API, harap daftar dulu untuk uji coba gratis 14 hari kami di sini (Anda dapat membeli langganan setelah menginstal uji coba gratis).Kemudian klik di sini untuk meminta uji coba gratis. Kami akan memandu Anda melalui proses dan memberi Anda token evaluasi gratis untuk membantu Anda memulai.

Ajukan permohonan token evaluasi

Terima kasih.Saya harap Anda akan mengambil kesempatan ini untuk mempelajari lebih lanjut tentang SIOS AppKeeper, yang menyediakan pemantauan otomatis dan pemulihan aplikasi yang berjalan di EC2.

– Tatsuya Hirao di tim teknis Teknologi SIOS.

Direproduksi dengan izin dari SIOS