Di Mana Seharusnya HA “Berada”? Mencocokkan Penempatan dengan Target Ketersediaan Anda

Di Mana Seharusnya HA “Berada”? Mencocokkan Penempatan dengan Target Ketersediaan Anda

Pada pameran dagang baru-baru ini, satu pertanyaan muncul berulang kali: Di ​​mana sebenarnya SIOS LifeKeeper dijalankan?

Jawaban ini penting. LifeKeeper diinstal langsung pada sistem operasi setiap server yang dilindungi. Penempatan ini memberikan visibilitas ke dalam aplikasi, sumber daya pendukungnya, dan dependensi yang diperlukan untuk menjaga agar beban kerja tetap tersedia.

Hal ini berbeda dengan hanya mengandalkan HA (High Availability) pada lapisan infrastruktur atau kontainer.

Lapisan yang Berbeda Melihat Kegagalan yang Berbeda

HA (High Availability) tingkat hypervisor dapat mendeteksi kegagalan host fisik dan memulai ulang mesin virtualnya di tempat lain. Platform orkestrasi kontainer dapat mengganti kontainer yang gagal atau memindahkan beban kerja antar node.

Kemampuan ini memberikan perlindungan yang berharga, tetapi beroperasi dari luar aplikasi. Mesin virtual masih dapat berjalan sementara basis data di dalamnya mengalami hang atau layanan web mengalami crash. Demikian pula, sebuah container dapat dihidupkan ulang tanpa sepenuhnya mengatasi masalah yang melibatkan data, penyimpanan, jaringan, atau layanan yang bergantung padanya.

Lapisan yang menyediakan HA menentukan kegagalan apa yang dapat dideteksi dan seberapa tepat respons yang dapat diberikannya.

Mengapa HA On-System Memberikan Perlindungan yang Lebih Mendalam?

Karena LifeKeeper berjalan di dalam sistem operasi, ia dapat memantau kesehatan lingkungan aplikasi yang sebenarnya, bukan hanya server, mesin virtual, atau kontainer yang menampungnya.

Hal ini memungkinkan LifeKeeper untuk:

• Memantau proses aplikasi dan sumber daya pendukung
• Memahami hubungan antara aplikasi, penyimpanan, jaringan, dan ketergantungan lainnya
• Mendeteksi kegagalan tingkat aplikasi yang mungkin terlewatkan oleh pemantauan infrastruktur.
• Mengkoordinasikan pemulihan dan pengalihan kegagalan dalam urutan yang benar untuk memastikan integritas data.
• Pindahkan seluruh lingkungan aplikasi ke sistem yang sehat.

Pendekatan yang peka terhadap aplikasi ini membantu mengurangi kesenjangan antara “server sedang berjalan” dan “aplikasi tersedia.”

Penempatan Harus Sesuai dengan Target Ketersediaan

Lokasi keberadaan HA harus ditentukan oleh apa yang harus tetap tersedia.

Jika tujuan utamanya adalah untuk memulihkan diri dari kegagalan perangkat keras atau host, HA tingkat infrastruktur mungkin sudah cukup. Namun, jika target ketersediaan berlaku untuk aplikasi penting bisnis dan datanya, perlindungan yang lebih dekat ke aplikasi memberikan visibilitas yang lebih besar dan pemulihan yang lebih tepat sasaran.

Pendekatan-pendekatan ini tidak harus saling eksklusif. Infrastruktur, kontainer, dan HA (High Availability) tingkat aplikasi dapat bekerja sama sebagai lapisan perlindungan. Kuncinya adalah memahami apa yang dipantau oleh setiap lapisan dan di mana tanggung jawab untuk pemulihan dimulai dan berakhir.

Semakin dekat solusi HA dengan aplikasi, semakin banyak konteks yang dimilikinya ketika terjadi kesalahan. Bagi organisasi dengan SLA yang ketat dan target RTO/RPO yang tegas, konteks tersebut dapat menjadi pembeda antara memulai ulang infrastruktur dan memulihkan layanan yang benar-benar diandalkan pengguna.

Siap menutup kesenjangan ketersediaan di lingkungan Anda?Hubungi tim kami untuk mempelajari bagaimana SIOS LifeKeeper dapat membantu Anda memenuhi target waktu operasional terpenting Anda.

PengarangBen Roy, Spesialis Program Pemasaran di SIOS

Direproduksi dengan izin dariSIOS

Mengapa Uptime 99,99% Tidak Berarti Uptime 100%?

Mengapa Uptime 99,99% Tidak Berarti Uptime 100%?

Pernahkah Anda melihat lebih dekat wadah pembersih tangan? “Membunuh 99,99% kuman” biasanya tertera dengan jelas di kemasannya. Jika Anda seperti saya, hal itu mungkin membuat Anda bertanya-tanya: “Bagaimana dengan 0,01% sisanya?” Apa yang membuat bagian kecil terakhir itu begitu sulit? Kita menghadapi pertanyaan yang sama dengan perangkat lunak HA. Anda mungkin pernah menemukan angka 99,99% saat membahas waktu aktif HA. Pertanyaannya tetap sama: mengapa kita tidak dapat mencapai waktu aktif 100%?

Pertama, mari kita bahas apa arti sebenarnya dari uptime 99,99%. Uptime mengacu pada jumlah waktu aplikasi Anda berjalan dan tersedia untuk pengguna akhir. Biasanya, ini diukur selama setahun. Untuk mencapai uptime 99,99%, Anda tidak boleh mengalami downtime lebih dari 52,60 menit. Secara rata-rata, itu terbagi menjadi:

52 menit, 36 detik setahun

4 menit 23 detik sebulan

1 menit 0 detik seminggu

0 menit 8 detik sehari

Itu waktu yang sangat singkat, tetapi bukan apa-apa, jadi dari mana sebenarnya asalnya?

Sumber Waktu Henti yang Disengaja

Mari kita mulai dengan beberapa sumber utama terjadinya downtime. Faktanya, seberapa pun bagusnya perangkat lunak HA Anda, akan selalu dibutuhkan waktu untuk melakukan operasi umum seperti switchover. Setiap kali Anda sengaja memulai switchover, akan terjadi downtime yang sangat minimal. Tergantung pada ukuran hierarki Anda, ini dapat memakan waktu mulai dari beberapa detik hingga beberapa menit. Untuk memahami mengapa demikian, kita perlu memahami apa yang terjadi ketika switchover terjadi. Pada tingkat sumber daya, kita harus terlebih dahulu menonaktifkan sumber daya sepenuhnya pada node aktif saat ini, kemudian mengaktifkan kembali sumber daya sepenuhnya pada node aktif yang baru. Tergantung pada aplikasinya, ini bisa berarti menjalankan beberapa perintah cepat, atau bisa juga berarti menjalankan operasi pematian bertahap yang panjang dan kompleks, diikuti dengan startup dingin yang lambat pada server lain. Pada tingkat hierarki, kita harus melakukan operasi ini satu per satu dalam banyak kasus. Jika suatu sumber daya memiliki anak, maka anak-anak tersebut harus dinonaktifkan sepenuhnya sebelum kita dapat mulai menonaktifkan sumber daya awal; Kemudian di server lain, kita harus mengaktifkan sepenuhnya server anak sebelum kita dapat mulai mengaktifkan server utama. Untuk hierarki multi-level, dengan proses peralihan yang kompleks, ini dapat sangat memakan waktu. Ini adalah jenis waktu henti yang inheren dan tak terhindarkan, tetapi untungnya dalam kebanyakan kasus pengguna akhir Anda seharusnya tidak menyadarinya selain sebagai waktu pemuatan yang sedikit lebih lama, atau koneksi ulang singkat. Namun, hal ini memang menambah perhitungan waktu henti.

Bentuk lain dari waktu henti yang melekat adalah pemeliharaan. Untungnya, sebagian besar pemeliharaan dapat dilakukan dengan cara yang sangat tersedia. Ini berarti melakukan pemeliharaan pada node cadangan terlebih dahulu, melakukan peralihan, kemudian melakukan pemeliharaan pada sistem yang sebelumnya aktif. Hal ini akan menimbulkan sejumlah waktu henti seperti yang dijelaskan di atas, tetapi seharusnya minimal. Namun, ada beberapa bentuk pemeliharaan yang tidak dapat dilakukan dengan cara yang sangat tersedia. Dalam kasus ini, sejumlah besar waktu henti dapat terjadi, dan meningkatkan total waktu henti untuk tahun tersebut.

Sumber-Sumber Waktu Henti yang Tidak Disengaja

Angka-angka tersebut benar-benar mulai bertambah begitu kita mulai melihat tujuan utama perangkat lunak ketersediaan tinggi: pemulihan bencana. Bahkan ketika semuanya berjalan sempurna sesuai rencana, setiap kegagalan akan menghasilkan sejumlah waktu henti. Mari kita lihat terlebih dahulu bagaimana waktu henti terjadi selama failover yang berhasil. Untuk memulihkan diri dengan benar dari suatu kegagalan, kita harus terlebih dahulu mendeteksi dan memverifikasi kegagalan tersebut. Ini adalah tindakan penyeimbangan yang sulit. Jika Anda terlalu agresif dalam mendeteksi kegagalan, Anda mungkin mendeteksi kegagalan yang sebenarnya belum terjadi (kegagalan palsu). Jika Anda tidak cukup agresif, Anda mungkin lebih lambat dari yang seharusnya dalam mendeteksi kegagalan. Sebagian besar kegagalan pertama kali akan dideteksi oleh proses yang berjalan secara berkala. Dalam kasus kegagalan sumber daya individual, ini biasanya berupa skrip pemeriksaan yang gagal. Dalam kasus seluruh server, ini biasanya akan dideteksi oleh detak jantung yang terlewat. Dalam kedua kasus tersebut, kita tidak hanya mengambil satu kegagalan dan langsung memulai pemulihan. Sebaliknya, kita mencoba lagi dan menunggu beberapa kegagalan untuk memverifikasi kegagalan yang sebenarnya. Sebagai contoh, skrip pemeriksaan mendalam, yang melakukan pengujian status sumber daya yang lebih rumit, secara default dijalankan setiap lima menit. Ini berarti bahwa mungkin dibutuhkan waktu hingga lima menit untuk mendeteksi kegagalan tertentu, dan tergantung pada jenis kegagalannya, mungkin dibutuhkan waktu lebih lama untuk memverifikasinya. Setelah kami mendeteksi dan memverifikasi kegagalan, tergantung pada jenis kegagalannya, kami kemudian dapat melakukan beberapa upaya pemulihan lokal. Jika berhasil, hal itu dapat menghemat waktu henti, tetapi jika tidak, hal itu akan menambah sedikit waktu pada perhitungan waktu henti failover. Setelah mendeteksi kegagalan, memverifikasinya, dan mencoba pemulihan lokal, kami kemudian akan melakukan failover. Tergantung pada jenis kegagalannya, hal itu dapat memakan waktu yang hampir sama dengan waktu henti switchover yang dijelaskan sebelumnya. Menambahkan semua potensi sumber penundaan ini, berpotensi untuk benar-benar meningkatkan waktu henti. Untungnya, sebagian besar kegagalan dapat dideteksi dengan cepat, dan sama seperti switchover yang dijelaskan di atas, hampir tidak akan disadari oleh pengguna akhir.

Sumber kedua dari waktu henti yang tidak disengaja adalah kegagalan failover. Ketika ini terjadi, hal ini dapat benar-benar meningkatkan waktu henti, karena bergantung pada teknisi yang berkualifikasi untuk campur tangan dan menstabilkan sistem dengan benar. Hal ini agak jarang terjadi, tetapi memang bisa terjadi. Untungnya, hal ini hampir selalu dapat dicegah. Cara terbaik untuk memastikan bahwa failover akan berjalan sesuai rencana adalah dengan mengujinya terlebih dahulu. Sangat mudah untuk salah mengkonfigurasi sesuatu, tetapi hanya dengan menjalankan uji failover akan mengungkapkan masalah tersebut. Cara lain untuk memastikan bahwa failover akan berhasil adalah dengan memastikan bahwa cluster Anda siap untuk melakukan failover sesering mungkin. Ini berarti memastikan bahwa sistem cadangan aktif dan berjalan, dan bahwa sumber daya berada dalam keadaan ISP (In Service Protected). Misalnya, mirror DataKeeper, yang tidak dalam keadaan mirroring, tidak akan berada dalam keadaan ISP, dan ketika terjadi kegagalan, tidak akan dapat melakukan failover. Untuk memastikan bahwa sumber daya dapat dialihkan, Anda harus mengambil langkah-langkah untuk memastikan bahwa DataKeeper melakukan mirroring sesering mungkin, dan sumber daya lainnya juga selalu diperbarui dan siap untuk failover.

Sumber terakhir dari waktu henti yang tidak disengaja adalah masalah di luar kendali LifeKeeper. Masalah jaringan dapat menyebabkan failover yang berhasil maupun tidak berhasil, tetapi juga dapat membuat cluster yang tampaknya sehat menjadi tidak dapat diakses tergantung pada bagaimana sistem diatur. Demikian pula, masalah dengan perangkat lunak cloud atau virtualisasi yang mendasarinya dapat menyebabkan masalah di luar cakupan LifeKeeper. Untuk mencegah hal ini, menjaga sistem sebisa mungkin terpisah memungkinkan LifeKeeper untuk mengatasi masalah ini. Cluster yang berisi sistem yang semuanya berada di AZ yang sama atau di jaringan yang sama jauh lebih rentan terhadap masalah daripada cluster yang berisi sistem yang beragam. Area masalah lain di luar kendali LifeKeeper adalah masalah aplikasi internal dan kesalahan manusia. Misalnya, penghapusan data penting secara tidak sengaja dapat menyebabkan masalah bagi pengguna akhir yang kemungkinan besar tidak akan terdeteksi dan tidak dapat diperbaiki oleh LifeKeeper. Menggunakan perangkat lunak pencadangan dapat membantu memulihkan dari jenis masalah ini, tetapi tidak dapat mengembalikan waktu aktif yang hilang. Terakhir, ketersediaan tinggi tidak selalu melindungi dari pelaku jahat dan ancaman keamanan siber. Serangan tertentu dapat mengakibatkan hilangnya waktu aktif. Untuk mencegah hal tersebut, disarankan untuk menggunakan perangkat lunak antivirus/antimalware yang terpercaya.

Sumber-Sumber Downtime yang Dapat Dihindari

Seperti yang telah disinggung di beberapa bagian di atas, ada banyak sumber waktu henti yang sepenuhnya dapat dicegah. Saya tidak akan membahas setiap jenis waktu henti yang dapat dicegah di sini, tetapi saya akan menyoroti beberapa yang paling umum.

Saat merancang topologi dan desain klaster Anda, ada beberapa hal yang perlu dipertimbangkan. Split brain, yang terjadi ketika kedua node percaya bahwa mereka adalah node utama, dapat dicegah dengan menggunakan beberapa bentuk kuorum. Jika Anda membuat aplikasi gen, pastikan untuk menulis dan menggunakan skrip pemeriksaan cepat dan pemeriksaan mendalam, sehingga kegagalan benar-benar terdeteksi. Terakhir, pastikan untuk menyiapkan lebih dari satu jalur komunikasi yang berjalan di lebih dari satu NIC dan jaringan.

Sistem yang tidak diatur dengan benar juga dapat menyebabkan waktu henti (downtime). Beberapa di antaranya telah dijelaskan. Pertama, pastikan bahwa aplikasi yang dilindungi, sistem operasi yang mendasarinya, dan perangkat lunak ketersediaan tinggi semuanya sepenuhnya diperbarui menggunakan versi terbaru. Banyak waktu henti terjadi karena bug yang sudah diperbaiki, yang sebenarnya dapat dihindari sepenuhnya. Kedua, pastikan untuk melakukan pengujian peralihan (switchover) dan failover pada klaster setelah pengaturan dan secara berkala. Banyak masalah yang dapat mencegah failover yang berhasil dapat dideteksi dan dicegah sebelumnya dengan melakukan pengujian ini. Ketiga, pastikan Anda selalu beroperasi dengan node cadangan yang aktif dan siap untuk mengambil alih.

Sistem yang dikonfigurasi secara tidak benar dapat menyebabkan waktu henti (downtime). Untuk mencegah hal ini, LifeKeeper dan DataKeeper menawarkan parameter yang dapat disesuaikan untuk mengoptimalkan kinerja, interval heartbeat, pemeriksaan sumber daya, dan pengaturan percobaan ulang. Meskipun pengaturan default biasanya sudah cukup, setiap perubahan harus dilakukan dengan pemahaman yang jelas tentang dampak dan kebutuhannya. Selalu prioritaskan panduan dari Dukungan SIOS, karena rekomendasi mereka didasarkan pada keahlian yang luas dan harus diikuti untuk memastikan keandalan sistem.

Penulis: Carter Chandler, Associate Software Engineer di SIOS

Direproduksi dengan izin dariSIOS

Webinar: Ketahanan Melalui Desain – Menjaga Beban Kerja Penting Tetap Berjalan di AWS

Webinar: Ketahanan Melalui Desain – Menjaga Beban Kerja Penting Tetap Berjalan di AWS

Membangun beban kerja yang tangguh dan memiliki ketersediaan tinggi di AWS EC2 sangat penting bagi organisasi yang menjalankan aplikasi penting. Webinar ini membahas cara mendesain dan mengoperasikan beban kerja tersebut.arsitektur ketersediaan tinggi di AWSsambil mengelola kompleksitas, kepatuhan, dan biaya.

Pelajari cara mengatasi tantangan umum seperti titik kegagalan tunggal, kesenjangan pemulihan, dan kompleksitas operasional, dengan contoh-contoh nyata dari dunia nyata.layanan keuangan,perawatan kesehatan, Dansistem pemeliharaan bangunanDapatkan panduan praktis untuk memperkuat ketahanan, mengurangi risiko, dan mengoptimalkan lingkungan AWS Anda.

Direproduksi dengan izin dariSIOS

Memahami Peran CLI dalam Lingkungan Ketersediaan Tinggi

Memahami Peran CLI dalam Lingkungan Ketersediaan Tinggi

Ketika orang berpikir tentang ketersediaan tinggi (HA), hal pertama yang terlintas adalah teknologi seperti clustering, failover otomatis, replikasi, dan pemulihan bencana. Kemampuan ini sangat penting untuk menjaga agar aplikasi dan layanan tetap tersedia. Aspek yang berpotensi terabaikan dari solusi HA adalah bagaimana administrator berinteraksi dengan dan mengelola lingkungan tersebut.

Saat ini, banyak solusi menawarkan antarmuka pengguna grafis (GUI) dan antarmuka baris perintah (CLI). Masing-masing memiliki tujuan yang berharga, dan pilihan terbaik seringkali bergantung pada tugas yang sedang dikerjakan, ukuran lingkungan, dan praktik operasional organisasi.

Meskipun GUI menyediakan cara intuitif untuk memvisualisasikan kesehatan klaster dan melakukan tugas administratif, CLI menawarkan serangkaian keunggulan berbeda yang dapat sangat berguna di lingkungan dengan ketersediaan tinggi. Memahami manfaat ini dapat membantu organisasi menentukan bagaimana antarmuka baris perintah sesuai dengan strategi manajemen keseluruhan mereka.

Mendukung Otomatisasi dan Pengulangan

Salah satu keunggulan CLI yang paling umum dikenal adalah kemampuannya untuk berintegrasi dengan alat dan skrip otomatisasi. Tugas administratif seperti memeriksa status klaster, memodifikasi konfigurasi, atau melakukan pemeliharaan rutin seringkali dapat diintegrasikan ke dalam skrip shell, platform orkestrasi, atau alat manajemen konfigurasi. Hal ini memungkinkan organisasi untuk mengotomatiskan proses berulang, yang mendorong konsistensi di seluruh lingkungan dan meminimalkan peluang kesalahan manual. Seiring pertumbuhan infrastruktur, kemampuan untuk mengotomatiskan operasi rutin seringkali menjadi semakin berharga untuk menyederhanakan tugas pemeliharaan.

Meningkatkan Skala dengan Lingkungan yang Berkembang

Persyaratan manajemen untuk satu klaster berbeda dengan persyaratan untuk puluhan atau bahkan ratusan klaster. Seiring dengan perluasan lingkungan, administrator sering mencari cara untuk melakukan tugas-tugas umum secara efisien di berbagai sistem. CLI (Command Line Interface) dapat mempermudah pembuatan skrip untuk operasi berulang, pengumpulan informasi kesehatan, pembuatan laporan, atau melakukan pemeliharaan terkoordinasi di lingkungan yang besar. Alih-alih menggantikan manajemen grafis, alat baris perintah dapat melengkapinya dengan menyediakan antarmuka yang efisien untuk operasi administratif skala besar.

Mendorong Operasi yang Konsisten

Konsistensi merupakan pertimbangan penting dalam lingkungan produksi apa pun, terutama yang dirancang untuk ketersediaan tinggi. CLI memungkinkan administrator untuk menjalankan perintah yang sama di seluruh lingkungan pengembangan dan produksi. Prosedur yang terstandarisasi dapat didokumentasikan, ditinjau, dan digunakan kembali, membantu tim melakukan tugas administratif umum secara konsisten. Konsistensi ini membantu mengurangi penyimpangan konfigurasi dari waktu ke waktu dan membuat proses operasional lebih mudah direproduksi selama jendela pemeliharaan.

Fleksibilitas untuk Administrasi Jarak Jauh

Lingkungan dengan ketersediaan tinggi seringkali didistribusikan di beberapa pusat data, wilayah cloud, atau lokasi geografis. Administrator mungkin perlu mengelola klaster dari jarak jauh, terkadang dalam kondisi jaringan yang kurang ideal. CLI dapat menyediakan metode ringan untuk berinteraksi dengan klaster melalui koneksi yang aman. Ini dapat sangat berguna ketika bandwidth terbatas atau ketika alat manajemen grafis tidak tersedia. Meskipun GUI seringkali memberikan pengalaman visual yang lebih kaya, CLI menawarkan opsi manajemen alternatif yang tetap efektif dalam berbagai skenario operasional.Pelajari lebih lanjut tentang memilih cloud untuk ketersediaan tinggi..

Memilih Antarmuka yang Tepat

Bagi banyak organisasi, pertanyaan tentang memilih antara GUI dan CLI bukanlah apakah akan menggunakan salah satunya atau yang lain; melainkan bagaimana menggunakan masing-masing secara efektif. GUI unggul dalam menyajikan kesehatan klaster, memvisualisasikan hubungan sumber daya, dan membuat fungsi administratif dapat diakses oleh berbagai pengguna. Di sisi lain, CLI seringkali cocok untuk otomatisasi, pembuatan skrip, operasi yang berulang, dan pengelolaan lingkungan yang lebih besar. Menggunakan kedua antarmuka secara bersamaan memungkinkan administrator untuk memanfaatkan kekuatan yang ditawarkan masing-masing sambil memilih alat yang paling tepat untuk tugas tertentu.

Kesimpulan

Mengelola lingkungan dengan ketersediaan tinggi melibatkan lebih dari sekadar menjaga waktu aktif; hal ini juga membutuhkan alat yang mendukung operasi yang efisien, konsisten, dan andal selama pemeliharaan atau respons insiden. Antarmuka baris perintah dapat menawarkan keuntungan di bidang seperti otomatisasi, pengulangan, dan konsistensi. Pada saat yang sama, antarmuka grafis terus memainkan peran penting dengan menyederhanakan visualisasi dan manajemen sehari-hari.

Alih-alih memandang satu antarmuka sebagai pengganti antarmuka lainnya, organisasi mungkin akan lebih diuntungkan dengan memahami bagaimana masing-masing berkontribusi pada manajemen klaster yang efektif. Dengan memanfaatkan keduanya di tempat yang paling tepat,Administrator dapat membangun alur kerja operasional yang dapat diskalakan seiring dengan infrastruktur mereka yang memiliki ketersediaan tinggi..

PengarangTristan Allen, Associate Software Engineer di SIOS Technology Corp.

Direproduksi dengan izin dariSIOS

Webinar: Dari Panik Menuju Proaktif: Panduan Pemula untuk Ketersediaan Tinggi

Webinar: Dari Panik Menuju Proaktif: Panduan Pemula untuk Ketersediaan Tinggi

Kegagalan server kritis seharusnya tidak berarti pemadaman yang panik dan berlangsung berjam-jam. Jika Anda seorang administrator sistem, DBA baru, atau DBA “tidak sengaja” yang bertugas menjaga agar sistem tetap berjalan, Anda tidak boleh menyerahkan waktu operasional sistem kepada keberuntungan.

Dalam sesi sesuai permintaan yang ramah bagi pemula ini, kami akan menguraikan dasar-dasar ketersediaan tinggi. Anda akan menemukan secara tepat apa yang menyebabkan pemadaman tak terduga, bagaimana failover otomatis bekerja, dan bagaimana teknologi modern seperti clustering dan infrastruktur cloud menjaga sistem penting Anda tetap berjalan 24/7.

Direproduksi dengan izin dariSIOS