SIOS APAC Portal

September 10, 2021	12 Pertanyaan untuk Mempermudah Migrasi Cloud Anda 12 Pertanyaan untuk Mempermudah Migrasi Cloud Anda Praktik terbaik migrasi cloud “Cloud menjadi lebih rumit,” itu adalah pernyataan pertama dalam webinar berdurasi satu jam yang merinci perubahan dan peluang dengan ledakan komputasi awan dan migrasi cloud.Presenter melanjutkan dengan garis besar hal-hal terkait cloud yang dihadapi TI tradisional dalam perjalanan mereka ke AWS , Biru langit , GCP atau penyedia lainnya. Ada sembilan area yang muncul sebagai komplikasi dalam transisi tradisional ke cloud: definisi Harga Jaringan Keamanan Pengguna, Peran, dan Profil Aplikasi dan Lisensi Layanan dan Dukungan Ketersediaan Cadangan Sebagai Wakil Presiden Pengalaman Pelanggan untuk SIOS Technology Corp, saya telah melihat bagaimana area berikut dapat memengaruhi transisi ke cloud. Untuk mengurangi komplikasi ini, konsumen beralih ke penyedia layanan terkelola, arsitek solusi cloud, kontraktor dan konsultan, dan sekumpulan layanan terkait, panduan, posting blog, dan artikel terkait. Seringkali dalam proses beralih ke sumber daya luar atau outsourcing, komplikasi ke cloud tidak sepenuhnya dihilangkan.Sebaliknya, perusahaan dan tim yang mereka pekerjakan untuk membantu atau mentransisikannya ke cloud masih menghadapi hambatan, hambatan, hambatan, dan kemunduran. Paling sering komplikasi dan kelambatan dalam migrasi ke cloud ini berasal dari dua belas pertanyaan yang tidak terjawab: Apa tujuan kami pindah ke cloud? Apa arsitektur lokal Anda saat ini?Apakah Anda memiliki dokumen, daftar, diagram alur, atau buku masak? Apakah semua aplikasi, database, ketersediaan, dan vendor terkait Anda didukung pada platform penyedia cloud target Anda? Apa risiko dan batasan lokal Anda saat ini?Aplikasi apa yang tidak terlindungi, apa masalah paling umum yang dihadapi di tempat? Siapa yang bertanggung jawab atas arsitektur dan desain cloud?Bagaimana arsitektur dan desain ini menjelaskan definisi Anda saat ini dan definisi penyedia cloud? Siapa pemangku kepentingan utama, dan apa pencapaian mereka, penggerak bisnis, dan tenggat waktu untuk proyek bisnis? Sudahkah Anda membagikan rencana dan pencapaian proyek Anda dengan vendor Anda? Apa proses, tata kelola, dan persyaratan bisnis saat ini? Berapa anggaran migrasi dan apakah itu termasuk penambahan staf, pelatihan, dan layanan? Berapa perkiraan Anda untuk biaya pemeliharaan, lisensi, dan operasional yang sedang berlangsung? Apa keterampilan dan tanggung jawab tim Anda saat ini? Siapa yang akan bertanggung jawab untuk memperbarui tata kelola, proses, model cloud baru, dan berbagai peran dan tanggung jawab tradisional? Apa saja aplikasi, layanan, atau fungsi yang akan berpindah dari model IaaS ke SaaS? Ketahui Tujuan Anda untuk Cloud Jadi, bagaimana menjawab dua belas pertanyaan ini akan meningkatkan migrasi cloud Anda. Seperti yang Anda lihat dari pertanyaan, memahami tujuan Anda untuk cloud adalah langkah pertama dan terpenting.Hampir diterima secara universal bahwa “penyedia layanan cloud seperti AWS, Azure, atau Google dapat menyediakan server, penyimpanan, dan sumber daya komunikasi yang dibutuhkan aplikasi tertentu,” tetapi bagi banyak pelanggan, ini hanya menghilangkan “dia membutuhkan komputer. perangkat keras dan personel untuk mengelola perangkat keras itu.” Karena fakta ini, seringkali pelanggan berfokus pada konsolidasi atau pengurangan peralatan atau pusat data, tanpa mempertimbangkan bahwa ada peluang dan celah cloud tambahan yang masih perlu mereka pertimbangkan. Misal seperti awan melakukan menghilangkan manajemen perangkat keras, tetapi “ tidak menghilangkan semua kebutuhan yang dimiliki aplikasi dan dependensinya untuk pemantauan dan pemulihan,” jadi jika tujuan Anda adalah mendapatkan semua ketersediaan Anda dari cloud, Anda mungkin tidak mencapai tujuan itu, atau mungkin memerlukan lebih dari sekadar pindah di tempat untuk model IaaS.Mengetahui tujuan Anda akan sangat membantu Anda memetakan perjalanan cloud Anda. Ketahui Arsitektur Lokal Anda Saat Ini Kategori pertanyaan penting kedua yang diperlukan untuk migrasi yang tepat ke cloud, (atau platform baru apa pun) adalah memahami arsitektur lokal saat ini. Langkah ini tidak hanya membantu mengidentifikasi aplikasi penting Anda yang membutuhkan ketersediaan, tetapi juga dependensi yang mendasarinya, dan setiap perubahan yang diperlukan untuk aplikasi, database, dan solusi pencadangan tersebut berdasarkan penyimpanan, jaringan, dan perubahan komputasi awan.Menjawab pertanyaan ini juga merupakan langkah kunci dalam menilai kesiapan aplikasi dan solusi Anda untuk cloud dan mengukur risiko Anda saat ini. Area ketiga yang akan sangat diuntungkan dari mengerjakan pertanyaan-pertanyaan ini terjadi ketika Anda mendiskusikan dan mengukur keterbatasan saat ini.Seringkali, kita melihat fase penemuan ini membuka pintu untuk keterbatasan solusi saat ini yang tidak ada di cloud.Misalnya, baru-baru ini tim layanan kami bekerja dengan pelanggan yang terpengaruh oleh masalah kinerja di cluster database SQL mereka.Seorang pakar SIOS yang membantu migrasi mereka menanyakan tentang solusi dan arsitektur, serta keputusan ukuran VM. Setelah beberapa saat, instans berukuran aplikasi yang lebih besar dikerahkan untuk memperbaiki batasan yang telah diterima pelanggan karena batasan lokal mereka pada komputasi, memori, dan penyimpanan.Demikian pula kami telah bekerja dengan pelanggan yang sensitif terhadap penyimpanan.Mereka akan menjalankan aplikasi dengan disk yang lebih kecil dan kebijakan pengubahan ukuran yang sering, karena keterbatasan kapasitas disk. Sementara biaya penyimpanan harus dipertimbangkan, berjalan dengan margin minimal bisa menjadi batasan di masa lalu. Memahami Perubahan Bisnis dan Tata Kelola Kelompok pertanyaan terakhir membantu tim Anda memahami jadwal, dampak bisnis, tenggat waktu, dan perubahan tata kelola yang perlu diperbarui atau diganti karena mungkin tidak lagi berlaku di cloud. Bermigrasi ke cloud dapat menjadi transisi dan perjalanan yang mulus.Namun, gagal menilai di mana Anda berada dalam perjalanan dan kapan Anda harus menyelesaikan perjalanan dapat membuatnya menjadi mimpi buruk. Memahami waktu adalah penting dan dapat sangat dibantu dengan mempertimbangkan pemangku kepentingan, vendor aplikasi, pencapaian bisnis, dan musim bisnis.Secara egois, SIOS Technology Corp. ingin pelanggan memahami pencapaian mereka karena sebagai penyedia Layanan, hal itu meminimalkan kejutan. Namun, kami juga mendorong pelanggan untuk menjawab pertanyaan-pertanyaan ini karena mereka sering menemukan ketidakselarasan antara departemen dan pemangku kepentingan. DBA percaya bahwa cutover akan terjadi pada akhir pekan terakhir bulan ini, tetapi Finance berniat menutup pembukuan selama akhir pekan terakhir di bulan yang sama; atau tim TI percaya bahwa pengalihan dapat terjadi pada hari Senin, tetapi tim aplikasi tidak tersedia hingga hari Rabu, dan mungkin yang terpenting tim hukum belum menyisir daftar NDA baru, perjanjian, lisensi, dan perubahan tata kelola yang diperlukan untuk menariknya bersama. Saat pelanggan mengerjakan pertanyaan, dengan keamanan dan empati, yang sering muncul adalah potongan-potongan teka-teki, kepemilikan, proses, dan pengambil keputusan yang perlu disatukan kembali menggunakan kotak penyedia cloud dan percakapan jujur tentang anggaran, kepegawaian, pelatihan , dan layanan.Hasil akhirnya mungkin bukan migrasi yang sempurna, tetapi pasti akan menjadi migrasi yang berhasil. Untuk bantuan dengan strategi migrasi cloud Anda dan penerapan ketersediaan tinggi, hubungi SIOS Technology Corp. – Cassius Rhue, VP, Pengalaman Pelanggan Pelajari lebih lanjut tentang umum tantangan migrasi cloud . Baca tentang beberapa kesalahpahaman tentang ketersediaan di awan. Direproduksi dari SIOS
September 5, 2021	3 Langkah untuk Redundansi Sistem TI yang Efektif 3 Langkah untuk Redundansi Sistem TI yang Efektif Di beberapa industri, tugas duplikat dapat menjadi pemborosan sumber daya perusahaan dan dapat menyebabkan kesalahan manusia yang tidak disengaja dan hilangnya waktu. Namun di dunia TI dalam mengelola sistem dan data, proses duplikasi yang disebut sebagai “redundansi” sangat penting untuk kesuksesan organisasi Anda yang berkelanjutan. 1. Lindungi Perangkat dan Perangkat Lunak Anda dengan Alat Redundansi Alat TI yang menyediakan redundansi memastikan sistem dan aset perangkat lunak Anda terlindungi dari kehilangan atau kerusakan. Mereka juga harus menyediakan pemulihan tepat waktu untuk memulihkan gangguan bisnis Anda. Redundansi dalam sistem TI berarti memiliki kemampuan untuk menduplikasi komponen sistem Anda, baik pada perangkat keras, VM, atau cloud. Di tingkat pengguna, contoh sederhana adalah membuat salinan sistem PC pengguna dan menyimpannya di PC lain sebagai cadangan jika PC pengguna gagal. Konsep yang sama ini dapat diterapkan pada komponen komputer lainnya, termasuk server, perangkat penyimpanan, dan peralatan jaringan. Misalnya, “mirroring” adalah mekanisme untuk menulis data yang sama ke beberapa disk, membuat disk tersebut menjadi berlebihan. Redundansi memungkinkan Anda untuk pulih dari kegagalan perangkat dengan beralih ke perangkat cadangan sesegera mungkin. Bisnis sangat bergantung pada sistem TI mereka, dan penghentian layanan yang disebabkan oleh kegagalan sistem dapat menyebabkan waktu henti operasi yang cukup besar. Akibatnya, redundansi sangat diperlukan agar sistem TI tetap tahan terhadap kegagalan dan mengurangi risiko gangguan bisnis. Bergantung pada ukuran dan lokasi geografis organisasi Anda, ini bisa jadi sulit, memakan waktu, dan mahal. 2. Pertahankan Semua Data Saat Ini dan Disinkronkan dengan Pengelompokan Memiliki perangkat yang berlebihan dengan spesifikasi dan lingkungan yang sama (sistem operasi dan perangkat lunak) tidak secara otomatis melindungi hilangnya file dan email pengguna, dan data aplikasi yang sangat penting ketika terjadi kegagalan. Hal ini berlaku tidak hanya untuk PC pengguna individu tetapi juga skala perusahaan yang lebih besar, di beberapa server dan perangkat penyimpanan. Kegagalan perangkat penyimpanan data dapat membuat operasi bisnis Anda mengalami penundaan yang signifikan tanpa akses ke data terbaru. Untuk aplikasi besar seperti SQL Server , Peramal , atau GETAH , waktu pemulihan bisa menjadi signifikan. Sayangnya, banyak perusahaan percaya bahwa risiko mereka berkurang hanya dengan mencadangkan data mereka. Namun, sampai perangkat produksi tiba-tiba gagal, kebanyakan orang tidak menyadari betapa sulitnya untuk benar-benar mengembalikan data ke perangkat siaga dari salinan cadangan. Sangat kontras, dengan perangkat siaga yang sudah memiliki kemampuan untuk menggunakan data yang sama dengan perangkat produksi yang gagal, yang harus Anda lakukan hanyalah menyalakan mesin siaga dan beralih ke sana. Pekerjaan pemulihan akan jauh lebih mudah. Ini dimungkinkan dengan sistem cluster High Availability (HA). Kekelompokan membantu meningkatkan keandalan dan kinerja sistem perangkat lunak dan perangkat keras dengan menciptakan redundansi untuk mengkompensasi kegagalan sistem yang tidak terduga. Sistem cluster HA terdiri dari server redundan dalam sistem aktif dan siaga dan penyimpanan eksternal (misalnya, disk bersama) yang dapat diakses oleh kedua server. Jika server operasi gagal, dengan beralih ke server siaga, layanan dapat dilanjutkan dengan kombinasi server siaga dan penyimpanan eksternal yang berisi data terbaru. Omong-omong, fungsi yang sama dapat dicapai dengan “ replikasi “, yang menyinkronkan data antar disk di dalam server secara real time. Replikasi juga merupakan tindakan yang sangat baik terhadap Pemulihan Bencana karena tidak memerlukan instalasi penyimpanan eksternal yang mahal dan menyimpan data terbaru pada kedua instans. Bergantung pada lokasi instans sekunder, data direplikasi secara sinkron atau asinkron. Ketahuilah bahwa bagaimana data direplikasi memengaruhi Sasaran Waktu Pemulihan (RTO) dan Sasaran Titik Pemulihan (RPO). 3. Mengotomatiskan Kegagalan Baik Anda menggunakan sistem klaster HA atau replikasi, praktik terbaik adalah menghindari peralihan manual server Anda saat terjadi kegagalan. Alih-alih, otomatisasi proses sehingga dilakukan tanpa penundaan dalam proses yang disebut failover. Mengonfigurasi failover otomatis sistem klaster HA / replikasi meminimalkan waktu henti sebanyak mungkin dan mengurangi kesalahan manusia. Solusi pengelompokan berbasis SIOS SAN dan SANLess menyediakan ketersediaan tinggi dan pemulihan bencana untuk aplikasi mission-critical di lingkungan fisik, virtual, cloud atau hybrid cloud. Untuk informasi lebih lanjut, lihat kami Windows dan Linux ketersediaan tinggi produk . Direproduksi dari SIOS
Agustus 29, 2021	Memigrasikan Aplikasi Ke Cloud Memigrasikan Aplikasi Ke Cloud Bagaimana kita bisa sampai di sana? *Dalam perjalanan Anda ke cloud dan ketersediaan yang lebih tinggi, pertimbangkan saran dari penulis dan pengusaha Pedagang Nilofer (memiliki satu tautan di bawah ini baik-baik saja) .* Dalam waktu kurang dari 72 jam, saya telah menjawab pertanyaan yang sama beberapa kali: Bagaimana Anda mendapatkan di sana ?Itu dimulai dengan salah satu putri saya yang lebih tua bertanya kepada saya bagaimana cara pergi ke janji terkait sekolah, diikuti oleh seorang anak yang lebih muda yang bertanya kepada saya rute apa yang kami ambil ke toko, dan akhirnya putri tertua saya bertanya kepada saya bagaimana menuju ke tujuan tertentu. di suatu tempat di negara bagian. Mereka semua menanyakan pertanyaan yang sama. Namun dalam setiap kasus, konteks pertanyaan dan jawaban yang diharapkan sangat berbeda. Sebagai penulis dan pengusaha Pedagang Nilofer mengatakan, banyak tentang jawaban atas pertanyaan 'bagaimana Anda sampai di sana?' tidak hanya tergantung pada Anda di sana , tetapi juga pada Anda di sini . Apa "di sini" Anda dengan aplikasi saat ini? Langkah pertama dalam mencari tahu cara memindahkan aplikasi di sana (ke cloud, atau ke ketersediaan yang lebih tinggi di cloud) adalah memberi nama "di sini" dengan benar.Jadi, apa "di sini" Anda?Jawaban Anda atas pertanyaan ini bisa beragam seperti lokasi percakapan saya dengan putri saya. Salah satu putri saya bertanya dari konteks rumah kami. Konteks lain adalah dari titik awal di negara bagian yang berbeda, dan yang termuda bertanya dari tempat teori (berharap bahwa kita akan mendapatkan milkshake). Saat Anda mempertimbangkan definisi Anda dan detail "di sini" mulailah dengan mengajukan beberapa pertanyaan dasar: apa kamu? aplikasi kritis , dan bagaimana mereka dilindungi? Di mana Anda dalam penerapan perlindungan ketersediaan tinggi untuk aplikasi Anda? Bagaimana data penting Anda dilindungi? Berapa ukuran tim Anda saat ini? Seberapa yakin Anda dengan solusi dan layanan Anda untuk melindungi aplikasi dan data Anda? Di mana sistem perusahaan penting dan beban kerja aplikasi Anda saat ini berjalan? Jika Anda berada di tempat, apakah itu server di tempat, atau mesin virtual? Atau apakah di sini cloud pribadi, atau cloud publik tanpa HA? Berapa anggaran Anda untuk pindah ke cloud dan untuk mengelola aplikasi Anda di cloud ke depannya? Keletihan, ketidakpastian, kegelisahan, atau ketidakpuasan apa yang Anda rasakan “di sini”? Mendefinisikan "di sini" adalah titik awal, yang membantu kita merasakan jalan menuju "di sana" yang lebih baik, jadi luangkan waktu Anda.Pikirkan tentang apa lagi yang membentuk, mendefinisikan, membatasi, atau ada dalam parameter "di sini" Anda?Apakah "di sini" penerapan multi-produk, infrastruktur Tim TI global, atau beberapa lokasi lain, pengaturan beberapa kantor?Apakah tim Anda didistribusikan secara global, dialihdayakan, atau kombinasi?Jika Anda melihat "di sini" hal-hal apa yang menonjol, apa penanda tim, perusahaan, produk, atau perusahaan Anda?Apa masalah utama dan sering berulang, seperti kurangnya pelatihan, redundansi yang hilang, panduan arsitektur yang tidak lengkap, kekecewaan dengan solusi yang sudah ada, kompleksitas cloud, Apa "di sana" Anda? Pribadi, publik, hibrida atau multi-cloud? Setelah Anda mengetahui "di sini" Anda, langkah kedua untuk mengangkat dari artikel Merchant adalah "mencari tahu apa yang mungkin 'ada'. Sebagai VP of Customer Experience, saya telah bekerja dengan sejumlah pelanggan yang menginginkan lingkungan "ada" tanpa downtime, terencana atau tidak terencana, atau lingkungan di mana failover aplikasi mulus dan selesai dalam waktu dua menit atau kurang. Pelanggan lain memiliki tujuan yang lebih rendah, mencari waktu henti yang sesuai dalam jangka waktu lima (5) hingga sembilan (9) menit, atau yang lebih memilih jendela yang lebih panjang dengan opsi untuk penggantian manual berdasarkan tanggapan terhadap pemberitahuan kegagalan. Pelanggan lain masih menginginkan "ada" dengan pemberitahuan yang lebih baik, resolusi dan rekomendasi yang jelas, orkestrasi khusus aplikasi, dan cara untuk menambah tim mereka dengan para ahli dari vendor dan mitra.Jadi apa fitur utama dari 'ada' Anda? Apa yang Anda mampu? Ketika Anda melihat jawaban yang melelahkan dari "di sini," apa yang menonjol?Item apa dari "di sini" yang perlu ditangani untuk membuat versi masa depan yang lebih diinginkan dari tim, perusahaan, ketersediaan, pusat data, dan kehidupan Anda. Apakah "di sana" Anda mencakup lebih banyak ketahanan dan redundansi, lebih banyak orkestrasi aplikasi, analitik yang lebih baik, atau biaya yang lebih rendah?Di mana sosok pribadi, publik, hibrida, atau multi-cloud menjadi "ada" Anda?Bagaimana "di sini" Anda meningkat karena Anda telah berhasil sampai "di sana." Dari sini ke sana" Langkah terakhir, menurut Merchant, adalah “mencari cara kita pergi dari 'sini' ke 'sana'. Jika sulit untuk berada di "di sini" Anda, masuk akal untuk bekerja untuk memikirkan apa yang "di sana" itu. Dengan kata lain, pikirkan lebih dari sekadar memindahkan aplikasi Anda ke cloud. Pertimbangkan sumber daya dan layanan yang Anda perlukan untuk menciptakan hasil yang memenuhi semua harapan Anda. Pikirkan tentang vendor, penyedia solusi, tim layanan, dan perusahaan yang berspesialisasi dalam solusi ketersediaan tinggi yang dibuat khusus dapat membantu Anda mencapai "ke sana". Tidak seperti "sana" putri saya, tidak ada Waze untuk merencanakan perjalanan dari "sini" ke "sana" atau migrasi awan. Namun, dengan hati-hati memikirkan situasi Anda saat ini, termasuk rasa sakit, frustrasi, keterbatasan anggaran, dan hasil yang Anda inginkan, Anda dapat sampai pada solusi yang lebih dari sekadar migrasi cloud sederhana. Ini bisa berarti pengalaman sehari-hari yang lebih memuaskan tanpa dibebani oleh ketakutan akan kegagalan aplikasi dan waktu henti serta kerumitan pemecahan masalah dan keluhan pengguna akhir. Mengikuti saran Merchant saat merencanakan migrasi aplikasi ke cloud dapat membawa Anda ke berbagai kemungkinan mulai dari mendefinisikan arsitektur yang lebih kuat, mengubah solusi perangkat lunak HA, terlibat dalam penyedia layanan, pindah ke multi-cloud, hybrid cloud, atau cloud lainnya model.Bahkan mungkin berarti kembali menggunakan pusat data Anda sendiri. Selama lebih dari 20 tahun, SIOS telah membantu perusahaan menerapkan ketersediaan tinggi dan pemulihan bencana perlindungan untuk aplikasi penting di tempat, di lingkungan cloud dan hybrid cloud. Kami dapat memberikan keahlian untuk membantu Anda melalui perjalanan aplikasi HA dan DR Anda dari 'sini' ke 'sana' dan seterusnya. Untuk informasi lebih lanjut, hubungi SIOS – Cassius Rhee, VP, Pengalaman Pelanggan Direproduksi dari SIOS
Agustus 25, 2021	Clustering SAP #ACS Dan #ERS Di #AWS Menggunakan Windows Server Failover Clustering Clustering SAP #ACS Dan #ERS Di #AWS Menggunakan Windows Server Failover Clustering Saat memastikan ketersediaan tinggi untuk SAP ASCS dan ERS yang berjalan di Windows Server, solusi cluster utama yang ingin Anda gunakan adalah Pengelompokan Kegagalan Server Windows . Namun, saat melakukan ini di AWS, Anda akan segera menemukan bahwa ada beberapa kendala yang perlu Anda ketahui cara mengatasinya saat menerapkan ini di AWS. Saya baru saja menulis ini Panduan langkah demi langkah yang diterbitkan di blog SAP yang memandu Anda melalui seluruh proses. Jika Anda memiliki pertanyaan, silakan tinggalkan komentar. Direproduksi dengan izin dari Mengelompokkan manusia purba
Agustus 19, 2021	Glosarium: Windows Server Failover Clustering (WSFC) Daftar Istilah: Pengelompokan Failover Server Windows (WSFC) Definisi: A Pengelompokan Failover Server Windows (WSFC) cluster adalah sekelompok server independen yang bekerja sama untuk meningkatkan ketersediaan aplikasi dan layanan. SQL Server 2017 memanfaatkan layanan dan kemampuan WSFC untuk mendukung grup ketersediaan Always On dan Instans Cluster Failover SQL Server. SIOS DataKeeper terintegrasi dengan WSFC menambahkan fleksibilitas konfigurasi untuk membangun klaster WSFC di cloud. Direproduksi dari SIOS

Results 251-255 of 928
< Page 51 of 186 >

Bergabunglah dengan Milis Kami

First Name Last Name Email Address
Pencarian