Oleh Staf Techopedia, 7 Desember 2016
Bawa Pulang: Tuan rumah Eric Kavanagh membahas ketersediaan dengan Robin Bloor, Dez Blanchfield dan Bert Scalzo dari IDERA.
Anda saat ini belum masuk. Silakan masuk atau daftar untuk melihat video.
Eric Kavanagh: Hadirin sekalian, halo dan selamat datang kembali. Saat ini pukul empat Waktu Timur pada hari Rabu, dan hari-hari ini dapat berarti hampir satu hal jika Anda berada di dunia data: saatnya sekali lagi untuk Hot Technologies! Ya memang.
Nama saya Eric Kavanagh, saya akan menjadi pembawa acara Anda. Ini dirancang untuk mencari tahu apa yang panas, apa yang terjadi di luar sana, apa hal-hal keren yang digunakan di perusahaan, dan tentu saja, tepat di dasar semua yang kita lakukan di seluruh bidang ini adalah database. Jadi kita akan berbicara tentang melindungi basis data Anda. Topik yang tepat adalah, "Lindungi Database Anda: Ketersediaan Tinggi untuk Data Permintaan Tinggi." Jadi, ada slide tentang Anda benar-benar. Dan, cukup tentang saya, pukul saya di Twitter, @eric_kavanagh.
Pertama, tahun ini panas, datanya panas, data besar sangat panas, tapi itu benar-benar masih seperti di tepi. Semakin banyak perusahaan terdepan yang memanfaatkan data besar hari ini, sebagian besar organisasi roti dan mentega di dunia, masih menggunakan data tradisional, dan jika data Anda sangat diminati, maka Anda ingin memastikan bahwa itu tersedia karena ketika sistem turun, ketika data tidak dapat diakses, saat itulah Anda mendapatkan klien yang tidak bahagia, prospek yang tidak bahagia, Anda mendapatkan pelanggan yang churn, Anda mendapatkan semua hal yang tidak bahagia, mitra, dll. Jadi Anda tidak menginginkan hal itu.
Kita akan belajar dari beberapa yang terbaik hari ini dalam bisnis ini - kita akan mendengar dari Dr. Robin Bloor, pakar basis data dari sekitar tiga dekade berjalan. Dez Blanchfield, yang telah melakukan ini selama sekitar, tetapi dia mulai ketika dia benar-benar muda, dan Bert Scalzo dari IDERA, yang benar-benar basis data sabuk hitam. Jadi jangan menahan diri, teman-teman, ajukan pertanyaan - bagian besar dari acara ini yang berharga bagi Anda adalah ketika Anda mengajukan pertanyaan yang bagus dan mendapatkan jawaban yang baik, jadi kirimkan melalui jendela obrolan atau komponen Q dan A dari konsol Anda.
Dan dengan itu saya akan menyerahkannya kepada Robin Bloor - bawa pergi.
Robin Bloor: OK, saya klik ini dan lihat apakah itu bergerak - ya. Saya tidak akan berbicara tentang basis data khususnya. Saya pikir, Anda tahu, karena saya sedang melakukan intro, presentasi pengantar pertama, jadi saya akan berbicara tentang tingkat layanan yang diharapkan dan tentu saja ketersediaan, yang merupakan kesepakatan, yang merupakan topik acara hari ini.
Dan pertanyaannya adalah, Anda tahu, “Sungguh, apa ketersediaan? Dan apa perannya dalam cara orang menjalankan pusat data saat ini? ”Satu hal yang saya perhatikan - saya perhatikan ini kadang-kadang di tahun 90-an - saya bekerja di satu situs dan pengguna mulai mengeluh karena email mereka turun untuk 15 menit.
Dan itu menarik karena CTO atau siapa pun yang bertanggung jawab atas IT sebenarnya, salah satu dari sedikit tempat di mana pada masa itu mereka benar-benar menentukan tingkat layanan dan email yang turun selama 15 menit tidak melanggar tingkat layanan siapa pun. . Saya pikir diizinkan keluar selama dua jam, pada kenyataannya. Itu bukan email yang tidak dapat digunakan, itu hanya karena Anda tidak dapat mengirim dan menerima karena server keluar. Dan hal itu mengingatkan saya pada kenyataan bahwa saya perhatikan bergerak maju sejak saat itu, bahwa semuanya hanya mempercepat dan begitu juga harapan para pengguna, dan ini membawa Anda ke situasi di mana orang mungkin memiliki tiga tingkat layanan, tetapi sering kali mereka akan mulai mengeluh ketika tingkat layanan tidak benar-benar dilanggar.
Jadi definisi tingkat layanan, hanya untuk memberikan- yah, itu bisa bergantung pada apa yang Anda bicarakan dalam hal tingkat layanan. Kami sudah bicara tentang sistem TI atau aplikasi TI. Biasanya ditentukan dalam hal kinerja, ketersediaan, dan metrik - dengan kata lain, Anda tidak dapat benar-benar menentukan tingkat layanan kecuali Anda dapat mengukurnya, jadi biasanya ada semacam pengukuran yang terlibat dan biasanya tentang waktu respons, transaksi tertentu dan ketersediaan sistem selama periode waktu tertentu, dan sebelum sekitar 1994-1995, sangat jarang bahwa sistem apa pun harus tersedia selama lebih dari jam kerja normal. Jadi misalkan jam delapan pagi sampai jam enam malam, untuk memberikan rentang normal - dan orang membangun sistem dan cara itu dan itu artinya - dalam pikiran saya, terutama dengan database - Anda dapat mengkonfigurasi database dengan cara tertentu dan sebagai jendela batch mulai menyusut, kebutuhan untuk berpikir lagi mulai muncul dalam beberapa sistem dan kemudian sistem lain, dan kemudian kami mendapatkan kedatangan layanan atau arsitektur, yang mulai membuat ketergantungan antara sistem yang sebelumnya tidak bergantung pada satu sama lain, membuat segalanya lebih buruk. Kami mendapat tekanan dalam hal ketersediaan sistem.
Maksud saya adalah ketika berbicara tentang ketersediaan, itu termasuk cadangan dan pemulihan dan termasuk - rasanya bukan hanya ketersediaan dalam istilah normal yang kita bicarakan; ada banyak cara di mana aplikasi dapat gagal. Anda tahu, Anda bisa mendapatkan kegagalan perangkat keras atau Anda bisa mendapatkan kegagalan basis data, Anda bisa mendapatkan kegagalan perangkat lunak dan ada banyak spesies yang berbeda dari hal-hal itu, dan ketika itu terjadi Anda harus dapat memulihkan dan karena itu Anda perlu juga kembali sistem. Jadi perlu ada skema untuk membuat cadangan sistem dan Anda juga, di banyak situs saat ini, Anda memerlukan kemampuan pemulihan bencana jika seluruh bangunan meledak. Dan sesuatu yang layak disebutkan di sini, dan saya akan membahasnya sebentar lagi, tetapi dalam proses bisnis, mereka juga memiliki tingkat layanan, dan pada kenyataannya, tingkat layanan dari proses bisnis yang benar-benar penting bagi bisnis. ITU hanya harus melakukan bagiannya dan sesuai dengan kesepakatan apa pun.
Tingkat layanan TI biasanya merupakan tambahan dari tingkat layanan proses bisnis, tetapi sama seperti sangat jarang 15 tahun yang lalu bagi organisasi mana pun untuk memiliki tingkat layanan yang terdefinisi dengan baik, masih sangat jarang bagi organisasi untuk memiliki tingkat layanan yang terdefinisi dengan baik untuk proses bisnis. . Itu adalah sesuatu yang terjadi sekarang; itu bukan sesuatu yang telah berlangsung lama.
Ini adalah akselerasi dan hambatan waktu, hanya layak menyebutkan hambatan waktu. Kami berangsur-angsur pindah ke dunia pemrosesan acara dan karena itu kami berangsur-angsur pindah ke dunia waktu-nyata, dan karena itu kami berangsur-angsur pindah ke ketersediaan yang diperlukan 24 oleh 7, dan itu sebenarnya sulit untuk banyak sistem - itu sulit dicapai. Entah itu sangat mahal, atau dalam beberapa kasus Anda mungkin benar-benar harus mengubah sistem, bahkan pindah ke database yang berbeda, versi berbeda dari perangkat lunak database yang kami gunakan.
Juga hambatan waktu ini - dan saya selalu suka menyebutkan ini setiap kali saya mendapat kesempatan - ini adalah hambatan waktu yang dihadapi aplikasi kita; aplikasi mungkin ingin secepat mungkin, saat itulah perangkat lunak berbicara dengan perangkat lunak. Sebenarnya tidak ada lisensi yang dapat diterima dalam beberapa situasi, Anda ingin menjadi secepat mungkin, dan situasi-situasi dalam istilah bisnis seperti situasi pasar, di mana orang yang datang dengan pesanan pembelian kedua mendapatkan harga yang lebih buruk daripada seseorang siapa yang lebih dulu, dan karena itu kecepatan perangkat lunak sangat penting.
Tapi tahukah Anda, di bawah itu ketika Anda benar-benar berurusan dengan - berinteraksi dengan - manusia, waktu respons terbaik yang benar-benar dapat dituntut dari Anda adalah sepersepuluh detik, karena itu tentang waktu respons manusia. Anda tidak perlu pergi lebih cepat dari itu karena manusia toh tidak akan memperhatikan. Antara 1, 1 dan empat detik adalah waktu tunggu yang biasanya akan ditoleransi manusia, tetapi begitu Anda melewati sekitar empat detik, mereka tidak melakukan hal lain, dan karena itu Anda benar-benar terlibat dalam aktivitas batch.
Jadi Anda dapat melihat bahwa kerangka waktu dan hari, minggu, dan bulan tertentu untuk hal-hal di mana perilaku kumpulan masuk akal dan karena itu Anda tidak berada dalam dunia pemrosesan peristiwa, dan oleh karena itu ketersediaan mungkin sebenarnya sangat berbeda dalam hal apa yang Anda butuhkan untuk dapat menyediakan. Tapi begitu Anda berada di dunia acara, maka Anda berada dalam ketersediaan 24/7 dan perubahan teknologi adalah faktor sebagai teknologi berjalan lebih cepat dan lebih cepat, maka ketersediaannya mungkin tidak meningkat; itu tetap seperti apa adanya.
Ini adalah lapisan kompleksitas dan saya tidak ingin membahas hal ini secara mendalam, hanya saja, Anda tahu, ada tiga hal yang perlu dipertimbangkan di sini. Ada tingkat layanan infrastruktur, ini adalah sumbu vertikal, dan kemudian ada tingkat layanan dari setiap aplikasi yang diberikan dan kemudian ada tingkat layanan bisnis, dan mereka saling bergantung satu sama lain dan mereka harus dipertimbangkan. jika Anda benar-benar ingin menciptakan lingkungan yang responsif di mana tingkat layanan terpenuhi, pada dasarnya.
Kemudian Anda memiliki, di bagian bawah di sini, yang hanya mewakili basis data, tetapi Anda dapat melakukan apa saja di dalam sistem, Anda tahu Anda mendapatkan konfigurasi nonstop, yang artinya seperti yang dikatakan: ia tidak akan pernah berhenti. Anda punya situasi siaga panas, di mana dalam satu atau lain cara, ada berbagai cara untuk mencapainya, tetapi dalam satu atau lain cara, jika database gagal, ia beralih ke siaga panas dan ada sedikit sekali jeda ketentuan waktu, ke titik di mana pengguna mungkin akan memperhatikan, tetapi tidak akan banyak memperhatikan.
Siaga hangat lebih seperti pergantian 20 menit di mana semua orang menelepon meja bantuan dan menggerutu di meja bantuan saat database sedang dialihkan ke siaga. Lalu ada situasi reboot di mana itu bisa memakan waktu yang sangat lama. Perlu dicatat aplikasi apa pun yang diberikan atau basis data yang diberikan mungkin dalam situasi apa pun tergantung pada apa yang sebenarnya terjadi dan pada apa tingkat layanan yang diperlukan dari aplikasi tersebut sebenarnya.
Dari itu, saya hanya ingin membuat poin tentang kurva kompleksitas. Kompleksitas berasal dari node dan koneksi, ketergantungan. Di dunia tempat kita hidup, jumlah simpul dan koneksi yang terlibat dalam apa pun terus bertambah, jadi Anda berlari ke kurva kemanfaatan seperti ini. Jika Anda dapat melihat bagaimana kompleksitas meningkat dan cara dimensi waktu menyusut, maka Anda tahu untuk tingkat ketersediaan, apakah ada target waktu, apakah mereka cenderung berkurang?
Dan evolusi alami adalah menuju operasi tanpa henti, yang tentu saja paling mahal - setidaknya dalam pengalaman saya - ini adalah konfigurasi paling mahal yang dapat Anda buat. Dalam satu atau lain cara, organisasi mana pun yang memikirkan hal ini, benar-benar perlu memikirkan tidak hanya tentang apa yang terjadi sekarang, tetapi apa yang akan terjadi di masa depan.
Mungkin poin terakhir yang ingin saya sampaikan adalah, manajemen tingkat layanan adalah kegiatan yang berkelanjutan; itu bukan sesuatu yang Anda tahu Anda punya proyek, Anda melakukannya dan ini sudah berakhir. Tidak, karena semuanya terus berubah. Karena itu, saya akan mengoper bola ke Dez.
Dez Blanchfield: Terima kasih Robin. Saya suka slide pembuka Anda. Kami baru saja menjalankan tayangan ulang, saya pikir itu adalah "Finding Nemo 2, " film. Anda meminta Nemo mencari ketersediaan dalam bentuk sembilan, yang saya pikir cukup lucu. Selalu tindakan yang sulit untuk diikuti. Ketika saya berpikir tentang waktu aktif dan ketersediaan serta kinerja tinggi, gambar pertama yang muncul di benak saya, karena saya dibesarkan di Kepulauan Solomon dekat gunung berapi dan khatulistiwa, adalah gunung berapi yang meletus di pusat data saya; ada gambar ini yang selalu ada dalam benak saya bahwa itulah yang berpotensi terjadi jika sesuatu terjadi. Ini gambar Gunung yang indah. Etna, yang merupakan sudut timur laut Sisilia, yang berada tepat di sebelah Catania.
Pendekatan saya untuk ini adalah melakukan percakapan dengan Anda dan memberi Anda beberapa takeaways pada tingkat yang sama saya lakukan di ruang rapat secara teratur dari C-suite dan kepala lini bisnis dengan pandangan bahwa kami memiliki percakapan tentang apa yang dapat memengaruhi organisasi Anda dari pengertian komersial atau teknis dan jenis-jenis teknik.
Kita perlu memikirkan dan bagaimana - apa yang kita ambil dari itu, dan bagaimana kita pergi untuk kemudian mengatasi beberapa tantangan yang sedang kita bicarakan ketika kita berbicara tentang ketersediaan tinggi dan uptime, terutama seputar otomatisasi dan platform.
Jadi, pertanyaan yang kita ajukan pada awalnya adalah, apa yang sebenarnya kita maksudkan ketika kita berbicara tentang sistem basis data dan ketersediaan platform basis data? Apa artinya sebenarnya berbicara tentang tantangan aktual untuk membuat sesuatu tersedia untuk tingkat sebagaimana Robin bicarakan dalam perjanjian tingkat layanan memasang pemetaan tentang apa yang sebenarnya kita butuhkan dan inginkan?
Jadi, kenyataan hari ini adalah bahwa - dan sebenarnya di sini ada beberapa realitas puncak dalam pikiran saya - hari ini semuanya secara efektif didorong oleh basis data. Ada sangat sedikit sistem yang dibangun hari ini dan dibangun sedemikian rupa sehingga barang-barang baru saja disimpan dalam file atau semacam log file datar; semuanya selalu didorong oleh basis data. Sebagai akibatnya, kami memiliki kebutuhan untuk berhenti memikirkan tentang ketersediaan basis data tersebut, ke berbagai sistem dan aplikasi serta alat yang bergantung padanya dan bergantung pada mereka untuk memberikan layanan yang kami cari untuk berikan, jual, atau konsumsi . Dan semua infrastruktur di sekitarnya.
Bahkan, sangat banyak, ketika Anda berpikir tentang gangguan besar data akhir-akhir ini, khususnya, digital natives atau cloud natives, beberapa perusahaan yang ikut seperti Uber dan Airbnb dan sebagainya, dan PayPals yang sedikit lebih tua dan eBays di dunia - skala dan ukuran organisasi itu hanya mungkin karena teknologi basis data modern dan infrastruktur cloud modern. Tanpa itu, tanpa kemampuan tambahan yang disediakan, mereka pasti tidak akan ada. Bayangkan sebuah skenario di mana Anda hanya bisa sampai di eBay antara 9:05 dan 9:25 karena tidak tersedia untuk sisa hari itu karena sedang mencoba untuk melakukan iCloud atau cadangan atau sesuatu seperti itu, itu hanya tidak akan memiliki bekerja.
Jadi, dan ada bidang-bidang utama lainnya ketika Anda memikirkan kehidupan kita sehari-hari, Anda tahu, seperti ritel dan perbankan dan keuangan serta perusahaan penerbangan dan sebagainya. Kelompok industri besar seperti logistik penerbangan, pengiriman transportasi, ada pemerintah secara keseluruhan, ada keamanan nasional dan polisi dan sebagainya. Semua industri ini, semua segmen pasar ini, semua badan ini, kelompok bergantung pada lingkungannya yang sedang berjalan.
Jadi, dengan mengingat hal itu, kita juga memiliki peringatan lain yang harus kita pikirkan, bungkus lain yang ingin saya tinggalkan untuk Anda pikirkan, dan itulah dunia kita sekarang yang saya sebut “selalu ada.” Kami terhubung secara permanen dan ini adalah tema yang akan Anda dengar secara teratur dan saya akan mengulanginya dan mengulanginya. Kami sekarang memiliki smartphone di tangan kami sepanjang hari, setiap hari. Kami tidak mematikannya, kami meletakkannya di samping tempat tidur, kami selalu menggunakannya sebagai jam alarm, kami menggunakannya sebagai kamera dan kami mengambil foto, mereka mendorong foto-foto itu ke awan.
Mereka selalu aktif, mental yang terhubung secara permanen. Bahkan, ada koin frase yang saya suka gunakan, dan itu adalah kita sekarang semacam hidup generasi Fitbit, yang mana kita mengukur semuanya, kita memonitor semuanya, dan itu perlu dicatat dan itu akan pergi ke suatu tempat.
Dan ada juga ungkapan lain yang akan saya tinggalkan untuk Anda, yaitu pukul sembilan di suatu tempat, setiap saat. Kita hidup di dunia 24/7/365. Bumi terus berputar mengelilingi Matahari dan pada suatu titik, dan waktu, setiap jam dalam sehari, sudah jam sembilan. Dan itu berarti orang bangun dari tempat tidur dan mencoba melakukan hal-hal, membeli barang, memasang barang, dll.
Jadi, apa yang kita maksudkan ketika berbicara tentang ketersediaan tinggi? Yah itu terdengar sangat jelas sampai Anda mulai menyelami detailnya. Jadi, Anda tahu ketika kita berpikir tentang "OK, apa artinya ketersediaan tinggi?" Ya kenyataannya, tidak ada peluru perak. Ini adalah konsep yang cukup kompleks, seperti yang berkaitan dengan Robin dengan beberapa topik yang ia sebutkan seperti mengukur ketersediaan dan perjanjian tingkat layanan. Kami memetakannya untuk hal-hal seperti, saya punya pertanyaan-pertanyaan ini, apakah ini uptime? Apakah kita khawatir tentang hal-hal seperti apa yang kita sebut lima sembilan, yang akan saya bahas dalam satu menit. Apakah kita menganggap diri kita dengan apa yang ada dalam perjanjian tingkat layanan kita? Misalnya, dalam perjanjian tingkat layanan, maksud saya ada penundaan, akronim tiga huruf untuk perjanjian tingkat layanan menjadi semakin dan semakin kritis akhir-akhir ini.
Saat Anda menjalani seluruh proses on-premise dan self-host untuk di-outsourcing-kan ke pusat data pihak ketiga dan layanan yang dikelola oleh pihak luar, dan sekarang kita akan menuju cloud. Dan kenyataannya adalah ketika Anda berbicara tentang cloud, itu hanya komputer orang lain. Dan itu berarti Anda tidak menjalankan infrastruktur, Anda tidak menjalankan sistem dan selalu Anda tidak menjalankan cloud. Anda sedang melakukan pengaturan infrastruktur sebagai platform, jadi itu bahkan lebih penting dalam layanan tenaga penjualan. Sekarang bayangkan penjualan misalnya, Anda tahu Anda tidak menyentuh infrastruktur itu, Anda hanya masuk ke antarmuka web.
Jadi, satu-satunya mekanisme yang Anda miliki di dunia cloud dan infrastruktur outsourcing dari bentuk apa pun untuk mengendalikan itu adalah perjanjian tingkat layanan, itulah satu-satunya mekanisme yang Anda miliki, dan jika orang tidak memenuhi instalasi Anda, maka mereka juga bertahan hukuman dan pengurangan jumlah uang yang Anda bayar atau Anda tidak membayarnya.
Jadi, ini mengingatkan kembali seluruh tantangan ini, Anda tahu, bagaimana kita mengelola ketersediaan tinggi? Bagaimana kami mengelola ketersediaan waktu jika itu bukan infrastruktur Anda - itu semua tentang SLA, misalnya. Apakah itu infrastruktur Anda atau bahkan infrastruktur orang lain sebagai sudut pandang desain. Kami berbicara tentang penyeimbangan muatan ke model sains, apakah itu paten desain toleransi kesalahan?
Apakah Anda menjalankan siaga aktif, atau siaga aktif di arsitektur Anda? Apakah Anda memiliki beberapa server, beberapa platform penyimpanan? Bagaimana platform penyimpanan itu beroperasi? Apakah mereka saling meniru, apakah mereka saling meniru? Apakah Anda menjalankan RAID? Apa jenis RAID yang Anda jalankan untuk penyimpanan berlebihan? Apakah Anda menjalankan RAID pada tingkat disk? Apakah Anda menjalankan platform penyimpanan objek yang mereplikasi seluruh drive model dan sistem model dan drive? Apakah ini N plus satu untuk setiap bagian kecil dari infrastruktur yang Anda dapatkan? Apakah Anda menambahkan satu lagi dan apakah itu di pusat data yang sama atau pusat data lain? Sudahkah Anda membuat paten desain yang tidak memiliki titik penjualan, misalnya?
Semua hal mendasar ini, sekarang kedengarannya seperti konsep sederhana, tetapi ketika Anda masuk ke masing-masing dari hal-hal ini mereka adalah hal yang sangat, sangat rinci. Ketika kita berbicara tentang ketersediaan, kita akhirnya berbicara tentang sembilan. Dan apa yang kita maksudkan dengan sembilan? Kita semua pernah mendengar tentang ini, tetapi mari kita pikirkan apa artinya selama satu menit dan mengapa itu penting.
Jadi, kita berbicara tentang satu sembilan, yang hanya 90 persen dari ketersediaan kita. Saya tahu itu terdengar sangat tinggi. Jadi, ketika kita berbicara 24 oleh 7 oleh 365, jika kita hanya melihat satu tahun misalnya, ketika kita berbicara di sembilan yang merupakan 90 persen dari waktu, yang memungkinkan untuk tiga puluh enam setengah hari downtime setahun. Mari kita bulatkan itu menjadi lebih dari sebulan.
Sekarang pikirkan bisnis apa pun yang kita tangani setiap hari - apakah itu perbankan online, eBay, PayPal atau platform media sosial seperti LinkedIn, Twitter, atau hanya pengecer umum - katakan saja saya ingin memesan penerbangan untuk datang ke AS dari cerah. Australia, apakah saya akan senang jika saya ingin datang ke Amerika dalam waktu satu minggu, jika maskapai favorit saya turun selama tigapuluh enam setengah hari karena penyedia layanan mereka berkata, "Lihat, kami siap untuk 90 persen dari waktu "? Tentu saja tidak.
Ketika Anda naik model ini, dua sembilan: 99 persen. Nah itu menjadi 3, 65 hari, kira-kira tiga setengah hari downtime setahun. Apakah itu masalah besar? Yah itu jika Anda menjalankan Black Friday, dan Anda menjalankan penjualan khusus dan orang hanya dapat membeli selama beberapa hari.
Tiga sembilan menjadi hanya 8, 7 jam setahun, tetapi bahkan 8, 7 jam setahun, itu berturut-turut non-stop delapan jam dari waktu kita. Baik itu di perbankan dan keuangan, di kesehatan - jika itu rumah sakit, baik itu bisa menelan biaya jiwa. Ketika Anda naik, empat sembilan adalah 52 menit, lima sembilan adalah lima menit dan enam sembilan pada dasarnya adalah 30 detik. Enam sembilan sangat tinggi, dan ketika Anda naik tangga ini, saat Anda memanjat pohon Natal sembilan ini, semakin banyak sembilan yang Anda naik, semakin sulit adalah desain, lingkungan dan platform. Semakin sulit untuk memberikan layanan itu, dan jika Anda berpikir tentang pengurangan jumlah waktu yang Anda miliki untuk hal-hal seperti backup untuk dijalankan, administrasi, penambalan, jendela pemeliharaan untuk segala bentuk pemadaman - semua tantangan non-sepele - dan semuanya turun ke persentase pemadaman, secara efektif.
Kuncinya di sini yang ingin saya sampaikan adalah, tidak ada peluru perak, seperti yang saya sebutkan sebelumnya. Ketika datang ke ketersediaan, tidak ada "satu ukuran cocok untuk semua." Anda mungkin memiliki jenis paten desain yang sesuai dengan industri utama. Tantangan yang sama dihadapi oleh semua bank. Beberapa mungkin bank ritel, beberapa mungkin bank premium. Beberapa bank mungkin berfokus pada perdagangan dan investasi, manajemen kekayaan. Beberapa mungkin murni konsumen. Beberapa mungkin hanya penempatan di internet dan bahkan tidak memiliki teller dan hanya berurusan dengan ATM ketika mengeluarkan uang tunai. Jadi dalam skenario itu, bahkan dalam perbankan dan manajemen kekayaan dan industri jasa keuangan secara keseluruhan, untuk masing-masing dari mereka masih memiliki rasa atau hal tertentu yang mereka butuhkan ketika datang ke ketersediaan.
Jadi ketika kita berpikir tentang ketersediaan dalam bahasa Inggris yang sederhana, perpaduan antara ketersediaan dan ketersediaan tinggi - kita pikir mereka adalah hal yang sama, tetapi mereka sebenarnya adalah kapur dan keju. Ketersediaan adalah, saya telah meletakkannya dalam bahasa Inggris, ukuran waktu bahwa suatu server atau proses berfungsi secara normal atau umum, terkait dengan penggunaannya. Itu hanya berarti bagaimana kami menggambarkan apakah itu tersedia atau tidak. Ketika kita berbicara tentang ketersediaan, kita sering jatuh ke dalam jebakan pemikiran ini, “Saya menyediakannya dalam bentuk yang tersedia, ” versus ketersediaan tinggi dalam melindungi keamanan infrastruktur itu.
Ketersediaan tinggi, dalam arti lain dalam bahasa Inggris, adalah desain di mana Anda menerapkan atau mencapai semacam hasil dan ketersediaan data khususnya di mana hampir sepanjang waktu - 24/7/365 hari setahun - ketersediaan itu sampai ke beberapa di antaranya. sembilan Selalu bukan berarti 100 persen. Seratus persen secara teknis tidak mungkin di dunia nyata di satu lingkungan mana pun. Sangat sulit untuk satu server dalam sistem operasi dengan database di atasnya, dengan platform berjalan dan pada aplikasi yang Anda dapat mengirimkannya dan mengharapkannya berjalan 100 persen. Jadi kami mulai berpikir tentang desain. Apakah kita memiliki redudansi, apakah kita memiliki beberapa slide untuk ditiru? Kemudian ketika Anda menaruhnya dalam bahasa Inggris biasa, sangat menarik betapa berbedanya topik ketersediaan versus ketersediaan tinggi.
Saya pikir saya akan meletakkannya dalam bentuk grafik sederhana yang nyata hanya untuk memberi kita gambaran seperti apa ini ketika Anda mulai mendaki tantangan untuk meningkatkan ketersediaan dalam melindungi waktu layanan Anda. Di sudut kiri bawah kita punya sembilan tunggal. Saya telah meletakkan lima sembilan yang umumnya kita bicarakan. Enam sembilan agak keterlaluan. Ketika kita berbicara tentang lima sembilan di sudut kiri bawah, 35 hari kira-kira pemadaman itu, itu adalah lingkungan berbiaya rendah dan kompleksitas yang Anda coba berikan karena Anda memiliki sejumlah hal yang dapat gagal dan Anda dapat masih memenuhi perjanjian tingkat layanan Anda.
Tetapi ketika Anda berjalan di sepanjang bagian bawah dari kiri ke kanan, dan Anda sampai pada titik di mana ada lebih banyak sembilan dalam gambar, Anda mendapatkan skenario di mana Anda mulai berpikir tentang replikasi sistem dan platform. Anda harus berpikir tentang pengelompokan dan virtualisasi berbagai bagian infrastruktur. Anda harus berpikir tentang geolokasi kluster tersebut, beberapa situs pusat data, dan Anda harus memikirkan jenis industri dan segmen pasar yang Anda tuju. Jadi, jenis layanan apa yang perlu Anda penuhi? Ketentuan layanan apa yang Anda cari? Area yang merupakan layanan berbasis kartu waktu nyata yang menceritakan komunikasi. Apakah ini dinas militer? Jadi grafik ini bergerak dari kiri bawah ke kanan atas dan saat Anda melewati kurva itu, biaya dan kompleksitas bertambah. Ketika Anda mendapatkan lingkungan yang lebih kompleks dan lebih menuntut Anda akan membutuhkan lebih banyak sembilan.
Grafik ini, misalnya, melakukan hal yang sangat mirip: menggambarkan kisah antara komponen biaya versus komponen ketersediaan yang diinginkan. Jadi, di sudut kiri atas kami memetakan sistem yang sangat tersedia kompleks, dan biaya yang dikeluarkan jika ketersediaan turun dibandingkan manfaat memiliki ketersediaan dalam downtime nol. Jadi misalnya, jika kita memiliki lingkungan di sisi kiri di mana segala sesuatunya turun, kita dapat mengalami kerugian yang bersifat finansial. Kami memiliki implikasi hukum yang dapat menjadi implikasi tingkat strategi bisnis komersial.
Saya kira, ada semua jenis masalah moral yang berpotensi di sekitar memiliki manfaat layanan. Jika ini adalah industri kesehatan dan mereka mulai melalui biaya pemadaman, dampak kepada pelanggan, pengurangan kepuasan pelanggan, produktivitas staf, produktivitas pengguna, dll. Hal-hal ini dipengaruhi jika kita berpikir tentang merancang yang sangat kompleks, sangat tergantung, lingkungan yang sangat berisiko di mana ada potensi risiko pemadaman dan oleh karena itu kerugian.
Di sisi kanan kami mencoba untuk mengarahkan skenario di mana jika kami berinvestasi biaya tinggi dan perencanaan dalam desain, kami berinvestasi dalam implementasi cerdas. Kami berinvestasi dalam menyediakan keterampilan dan sumber daya bagi orang-orang dan kami telah sangat menghargai jaringan dan lingkungan operasional serta perangkat keras dan perangkat lunak yang sangat dihargai. Kami mendapatkan ketersediaan tinggi tetapi harganya mahal. Jadi tempat pendulum sihir ayun dari posisi optimal di tengah di mana mereka menyeberang, di mana kami mendapat sedikit biaya berkurang, dan peningkatan ketersediaan yang hanya menyulap antara tingkat sembilan dan ketersediaan tinggi yang merupakan ketersediaan berkelanjutan dan ini merupakan tantangan yang selalu ada untuk kita temui, seperti berapa banyak uang yang ingin Anda investasikan untuk mendapatkan tingkat layanan yang Anda cari?
Kami juga memiliki topik di mana saya tidak akan membahas secara rinci, tetapi saya hanya ingin Anda mengambil ini dan memikirkannya. Perbedaan antara waktu rata-rata antara kegagalan dalam desain Anda, versus waktu rata-rata untuk pulih. Dengan kata lain, apakah Anda berinvestasi dalam infrastruktur berkualitas lebih baik, desain berkualitas lebih baik, perangkat keras dan lunak berkualitas lebih baik, dan staf dan sumber daya terampil berkualitas lebih baik untuk merekayasa berbagai hal dan mengurangi waktu rata-rata di antara kegagalan, waktu rata-rata yang diperlukan untuk menemukan jeda sebagai lawan untuk menurunkan investasi dalam infrastruktur, dalam sumber daya dan desain dan paten buta, kemampuan tinggi untuk pulih? Dengan kata lain, jika sesuatu rusak, Anda harus mencolokkan banyak. Jika seseorang memiliki laptop dan mati, Anda punya cadangan. Anda menyerahkannya kepada mereka dan dalam 30 detik mereka login. Ini adalah ujung yang sangat berbeda dari kutub. Yang teratas menyimpulkan Anda sedang melakukan rekayasa dengan biaya tinggi dan investasi tinggi untuk menghindari kegagalan, dan yang paling bawah mengatakan bahwa “Saya akan menerima bahwa kegagalan akan datang, jadi saya akan merekayasa hal itu dan bersiap untuk kegagalan dan pulih dengan cepat. "
Seperti yang saya sebutkan sebelumnya, di mana saya bisa mengatakan, "Ketersediaan saya bukan ketersediaan Anda." Jadi ketika datang ke lingkungan basis data dan mendukung infrastruktur, menjalankan basis data Anda dan melindungi itu dan memastikan ketersediaan tinggi, sebenarnya tidak ada toko serba ada . Setiap orang memiliki kebutuhan dan keinginan mereka sendiri. Jadi Anda harus bertanya pada diri sendiri pertanyaan-pertanyaan mendasar yang akan saya sampaikan kepada Anda, dan itu adalah: Apa yang mampu dibayar oleh organisasi Anda? Saya tidak hanya berbicara tentang dolar dan sen. Saya berbicara tentang, sebagai sebuah organisasi, apa yang dapat Anda peroleh dari sumber daya, waktu dan upaya, dan sebagainya, sejauh tingkat ketersediaan dapat disediakan? Juga, apa yang dapat didukung bisnis Anda? Jadi, kemampuan saat ini, keterampilan saat ini, infrastruktur saat ini, dana saat ini yang dapat Anda kumpulkan. Sehingga juggle antara apa yang benar-benar Anda mampu versus apa yang dapat Anda dukung adalah keseimbangan yang menarik.
Selain itu, Anda kemudian harus bertanya pada diri sendiri pertanyaan: Keterampilan dan teknologi apa yang Anda miliki di rumah? Bisakah Anda mengalihdayakan sebagian dari tantangan itu? Lalu bisakah Anda memindahkan sesuatu ke cloud? Jika Anda memiliki layanan infrastruktur yang terpisah dari layanan perangkat lunak, Anda dibiarkan tanpa tumpukan itu saat Anda melangkah lebih jauh ke tumpukan. Jadi sebaiknya Anda berinvestasi lebih banyak di platform dan layanan dan tidak khawatir tentang infrastruktur, atau haruskah Anda melihat perangkat lunak sebagai penawaran layanan karena Anda tidak perlu khawatir tentang platform?
Apa jenis pasar dan konsumen atau pelanggan yang Anda layani? Maksud saya, jika Anda seorang telekomunikasi dan seseorang harus mengangkat telepon dan Anda mendapatkan nada panggil sepanjang waktu, itu adalah tantangan yang sangat berbeda untuk membuka toko ritel kecil antara Senin dan Jumat, sembilan hingga lima dan menutup untuk sebuah jam saat makan siang seperti tukang cukur sudut toko. Jadi, Anda harus berpikir sangat lama dan keras bagaimana cara kerjanya dan apa artinya bagi organisasi Anda, apa yang Anda butuhkan untuk dapat menyediakan.
Dan kemudian juggle antara apa yang ada di lokasi, apa yang di-host secara eksternal dan berpotensi, apa yang ada di cloud. Seperti yang saya katakan sebelumnya, itu datang dari tantangan waktu juga. Jadi kita harus menjawab pertanyaan terakhir yang saya nantikan teman-teman kami di IDERA untuk memberi tahu kami bagaimana mereka menangani hal-hal ini, dan itulah juggle yang baik antara mencocokkan ketersediaan yang Anda inginkan dan yang dibutuhkan dengan kinerja, dan apa yang dibutuhkan bisnis Anda dan apa pasar dan kebutuhan konsumen Anda.
Dan kenyataannya adalah itu tidak berarti feat. Diperlukan waktu, tenaga, dan uang untuk memikirkan hal-hal ini. Dan selalu merupakan investasi pada orang dan kemampuan keterampilan dan investasi dalam perangkat lunak dan alat untuk mengotomatisasi beberapa proses tersebut dan memberikan orang-orang alat yang tepat dan sistem yang tepat untuk membuat hidup mereka tidak hanya lebih baik, tetapi mungkin karena memantau lingkungan berskala sangat besar dan melindungi dan mengelola lingkungan berskala besar itu seringkali di luar kemampuan manusia.
Jadi, dengan mengingat hal itu, mudah-mudahan saya telah mengatur adegan untuk percakapan hebat bagi teman-teman kami di IDERA untuk berbicara tentang platform dan alat mereka, dan saya berharap untuk mengajukan beberapa pertanyaan besar di akhir. Dan saya akan meneruskan.
Robin Bloor: Baiklah. Bert, aku baru saja memberimu kunci, ambil saja.
Bert Scalzo: Terima kasih! Terima kasih, Dez dan Robin. Saya akan melanjutkan dengan topik ketersediaan tinggi untuk data Anda. Dan saya benar-benar akan memanfaatkan banyak dari apa yang baru saja Dez bicarakan. Jadi, pilihan, sembilan, pertukaran, keterjangkauan. Saya akan mencoba dan menempatkan lebih dalam hal administrator database atau seseorang yang lebih dekat dengan parit, bagaimana mereka melihatnya? Bagaimana mereka akan merancang itu? Dan apa artinya pilihan itu.
Sekarang, saya akan mencoba menjadi agnostik basis data. Saya tidak akan menggambar, misalnya, solusi Oracle-spesifik atau SQL-Server-spesifik, tapi saya akan menggambar, katakanlah, arsitektur generik yang ditawarkan semua vendor database, sesuatu yang sejalan. Mereka semua menyebutnya dengan nama yang berbeda, tetapi itu adalah satu jenis pilihan yang Anda miliki bersama, dan saya ingin melihatnya dari sudut pandang bisnis dan teknologi, dan bagaimana hal itu berkaitan dengan persyaratan bisnis.
Dan saya ingin memulai dari apa solusi pseudo-ketersediaan tinggi yang paling dasar adalah melalui opsi yang Anda miliki di solusi tingkat penyimpanan, solusi tingkat virtualisasi, di solusi tingkat basis data. Dan kemudian saya agak ingin juga memperkenalkan Anda pada fakta bahwa semua pilihan tersedia di cloud juga.
Jadi, sekali lagi, saya akan mencoba untuk tetap agnostik basis data. Sekarang, sebagian besar hal yang akan saya bicarakan, saya tahu bahwa mereka ada di Oracle, SQL Server, MySQL, PostgreSQL. Ada juga beberapa vendor pihak ketiga, yang membuat alat yang juga akan memberi Anda arsitektur tambahan yang dapat Anda pertimbangkan. Dan, seperti yang Dez katakan, tidak ada satu solusi yang terbaik; semuanya tergantung. Tetapi ada satu fakta universal dalam apa yang akan kita lihat, apakah akan ada lebih banyak bagian yang bergerak, jadi itu akan menjadi lebih kompleks dan karena itu lebih mahal.
Jadi, kita semua tahu data adalah aset penting. Dan semua orang tahu bahwa akses cepat ke data selalu menyenangkan. Tetapi, akses yang andal ke data sangat penting. Dan ketika dia berbicara tentang contoh sembilan tahunnya, dapatkah Anda benar-benar memiliki waktu istirahat 36 ½ hari? Sangat penting bahwa data tersedia sepanjang waktu. Jadi, downtime bisa menghabiskan banyak uang, baik dalam hal pendapatan yang hilang, tetapi bahkan lebih penting, pada pelanggan yang hilang, atau dalam kehilangan niat baik pelanggan. Saya akan memberi Anda contoh yang baik; jika situs web tertentu tempat saya melakukan pembelian lambat, saya dapat mencoba mencari situs web baru yang menjual barang serupa dengan biaya yang sama yang tidak memiliki situs web lambat. Jadi, itu bukan hanya kehilangan pelanggan, itu niat baik yang dimiliki pelanggan terhadap Anda.
Sekarang, perangkat keras jauh lebih murah akhir-akhir ini, oleh karena itu semakin banyak permintaan untuk ketersediaan tinggi. Dan lagi, saya akan membawa kita ke awan, ketika kita melihatnya. Dan kami memiliki penawaran dari berbagai tingkatan: vendor penyimpanan, vendor database, vendor virtualisasi, dan sekarang bahkan vendor cloud. Jadi, yang benar-benar menarik dari cloud adalah setelah saya menggambar semua gambar indah dari arsitektur ini yang bisa Anda bangun di cloud, sering kali hanya beberapa kotak centang yang Anda periksa. Dan Anda berkata, "Saya ingin replikasi di seluruh wilayah geografis." Kotak centang. “Saya ingin replikasi komponen perangkat keras utama.” Kotak centang. Jadi, jika Anda memahami gambar, kadang-kadang di awan itu hanya memeriksa beberapa kotak untuk membangun gambar yang ada dalam pikiran Anda.
Sekarang, kuncinya adalah, apa persyaratan bisnis untuk ketersediaan tinggi? Misalnya, apakah saya hanya perlu khawatir tentang kegagalan di satu situs, atau apakah saya harus memilikinya di beberapa situs? Dengan kata lain, dapatkah saya memiliki satu pusat komputasi dan saya tidak peduli jika satu pusat itu offline? Saya tidak membuat persyaratan bisnis yang diperluas di beberapa situs. Ini pertanyaan bisnis. Dan penting untuk mengetahui bagaimana bisnis memahami jawaban atas pertanyaan itu, karena itu biasanya menentukan anggaran Anda.
Sekarang, Anda juga ingin melihat tingkat perlindungan kegagalan. Mungkinkah itu kegagalan daya? Mungkinkah itu kegagalan komponen? Seperti NIC atau HBA yang rusak, adaptor bus host. Apakah ini hard disk yang rusak? Apakah ini kegagalan kabinet penyimpanan? Apakah ini kegagalan komputer? Atau, dalam beberapa kasus, apakah ini kegagalan situs? Itu berbeda dari, dalam beberapa kasus, Anda dapat memiliki kegagalan situs, karena situs itu sendiri sedang offline. Dalam kasus lain, bisa jadi sebagian besar situs offline, tetapi dari sudut pandang Anda, itulah keseluruhan situs.
Dan kemudian, seperti yang Dez bicarakan, apa harapan waktu untuk melanjutkan operasi? Itu pertanyaan bisnis. Jika bisnis mengatakan Anda harus dapat melanjutkan operasi dalam dua menit, maka jelas, itu akan menentukan beberapa gambar yang akan saya tunjukkan bahwa Anda akan bekerja, dan beberapa di antaranya tidak akan menjadi pilihan yang Anda inginkan. bisa memilih.
Dan pertanyaan lain yang muncul selama ketersediaan tinggi, tetapi sering orang lupa untuk bertanya adalah, "Hei, bisnis, jika sesuatu terjadi ketika saya sedang memproses transaksi, apa yang saya bisa kehilangan setelah dimulainya kembali sistem? " Dengan kata lain, jika saya dapat mengembalikan sistem dalam dua menit, dan saya dapat kehilangan tidak lebih dari 10 detik, katakanlah, transaksi yang sedang dalam penerbangan, apakah itu bisnis yang dapat diterima? Dan lagi, itu akan menentukan apa yang ingin dikeluarkan oleh bisnis untuk itu, dan sekali lagi, yang dapat menentukan gambar mana yang akan saya tunjukkan baik berlaku atau tidak.
Jadi, mari kita mulai dengan solusi ketersediaan semu paling dasar. Ini benar-benar bukan ketersediaan tinggi, tapi saya suka memulai dengan ini, karena membuat orang berpikir dengan cara yang benar. Jika saya punya server dan array penyimpanan, biasanya saya akan meletakkan beberapa NIC, kartu antarmuka jaringan, di server itu, dan mengikat mereka sehingga jika salah satu NIC gagal, saya masih aktif. Dan saya akan melakukan hal yang sama dengan adapter bus host saya, saya akan multi-path melalui switch yang berbeda, sehingga saya memiliki beberapa cara untuk sampai ke penyimpanan saya. Dan saya mendapatkan catu daya universal, dan saya punya pengontrol berulang di dalam array penyimpanan saya, dan mungkin saya telah melakukan sesuatu seperti RAID 10 dengan cakram saya. Dengan kata lain, dalam gambar ini saya telah mencegah kegagalan komponen tunggal pada berbagai tingkatan. Jadi, saya tidak terikat oleh NIC, atau HBA, atau pengontrol, atau saklar.
Tetapi jika Anda perhatikan, server berwarna merah dan array penyimpanan berwarna merah. Saya masih memiliki dua area di mana jika mereka gagal, jika server saya pergi, saya mati, jika kabinet array penyimpanan saya pergi, saya mati. Jadi, walaupun ini bukan ketersediaan yang sangat tinggi, itu mulai Anda untuk melihat dan melihat gambar dan berkata, "Saya ingin gambar di mana tidak ada merah." Dan itu benar-benar tujuan dari foto-foto ini, untuk mengarahkan kita ke arah yang benar.
Jadi, hal pertama yang terjadi adalah, sebagai DBA, saya mungkin selalu ingin menempatkan solusi ketersediaan tinggi sebagai implementasi basis data, tetapi mungkin tersedia bahwa itu dapat dilakukan sebagai solusi penyimpanan, atau mungkin bahwa itu bisa menjadi replikasi tingkat penyimpanan. Dalam hal kiri, saya punya virtualisasi penyimpanan. Apa yang terjadi adalah saya mendapatkan RAID 0 di dua lemari penyimpanan yang berbeda untuk disk saya, tetapi saya memiliki RAID 1 di dua lemari penyimpanan yang berbeda. Dengan kata lain, saya sebenarnya dapat memiliki kabinet penyimpanan gagal, dan saya tidak mati. Jadi, ini lebih baik daripada gambar sebelumnya, karena pada gambar sebelumnya - ingat kami memiliki merah di server dan merah di larik penyimpanan - dan sekarang kami membuat sedikit peningkatan, kami sekarang tidak lagi memiliki merah di tingkat penyimpanan, kami Sudah digunakan - virtualisasi penyimpanan memecahkan masalah itu.
Sekarang, cara lain Anda bisa melakukannya - dan tidak semua vendor menyediakan ini - adalah Anda dapat melakukan replikasi tingkat penyimpanan. Saya tidak berbicara replikasi database, saya sebenarnya berbicara tentang mereplikasi I / O blok Anda untuk penyimpanan Anda. Dan itu bisa dilakukan di tingkat penyimpanan. Dan sekali lagi, sekarang saya memiliki di sisi kanan, gambar lain di mana saya menghapus merah dari bawah, karena saya menggunakan replikasi penyimpanan.
Jadi, ini adalah gambar lain yang mungkin tersedia atau tidak. Dan orang yang akan mengelola ini mungkin adalah administrator penyimpanan Anda, bukan administrator basis data Anda. Saya suka membahas hal ini, karena kadang-kadang orang berpikir, "Oh! Ketersediaan tinggi, pasti DBA yang menangani masalah ini." Itu tidak selalu benar; bisa dalam hal ini menjadi administrator penyimpanan.
Sekarang selanjutnya, kita bisa melakukan virtualisasi server sebagai solusi yang memungkinkan. Sekarang jika Anda ingat, pada gambar pertama saya punya merah di server dan merah di array penyimpanan. Saya dapat, dalam hal ini, menggunakan virtualisasi, saya mungkin dapat pindah, dan dalam beberapa kasus relokasi adalah semacam relokasi yang hangat, dan dalam beberapa kasus sebenarnya dapat menjadi relokasi yang panas. Beberapa virtualisasi atau hypervisor menyediakan kemampuan untuk memindahkan mesin virtual dalam penerbangan. Dan beberapa database akan menerima bahwa pergerakan dalam penerbangan siap. Sekarang, sekali lagi, tidak semua hypervisor menyediakan ini, tetapi ini adalah satu tingkat kemungkinan solusi. Sekarang, saya sudah membuat server teratas tidak lagi merah, tapi saya masih memiliki array penyimpanan bersama dan coba tebak, solusi ini mungkin merupakan upaya bersama antara administrator database dan administrator virtualisasi. Atau bisa juga hanya administrator virtualisasi, tergantung pada tingkat relokasi apa yang didukung pada hypervisor itu dan database itu.
Jika Anda bertanya-tanya, “Wow, apa maksudnya dengan relokasi ini? Berikan saya contoh spesifik. ”Misalnya, di VM tempat Anda dapat menggunakan VMotion untuk memindahkan mesin virtual Anda dari satu host ke host lain dan melakukannya tanpa downtime. Sekarang, jelas bahwa gambar sebelumnya masih berwarna merah. Saya masih memiliki penyimpanan sebagai satu titik kegagalan. Jadi kami beralih ke solusi berikutnya, yaitu, izinkan saya menggabungkan penyimpanan dan virtualisasi server.
Sekarang, dalam kasus ini, sekali lagi, bisa jadi administrator penyimpanan dan administrator virtualisasi yang membangun solusi ini dan sekarang lihat: Saya punya gambar tanpa merah di dalamnya. Saya mendapatkan ketersediaan tinggi karena saya dapat memindahkan mesin virtual atau aplikasi yang sedang berjalan atau database dari satu server ke server lain dan saya memiliki virtualisasi dalam larik penyimpanan saya dengan melakukan RAID 1 melintasi dua larik penyimpanan terpisah. Saya telah multi-path switch saya dan HBA saya.
Jadi sekarang saya telah membangun sistem HA dan saya telah melakukannya terutama bukan di tingkat basis data. Dengan kata lain, saya telah menggunakan teknologi lain untuk mencapai hal yang sama. Jadi ini solusinya. Lalu kita masuk ke apa yang disebut cluster scalable shared-storage. Ini benar-benar bukan solusi HA, tapi sekali lagi, saya suka menunjukkannya untuk gambar.
Dan yang terjadi di sini adalah kami memiliki dua server yang menjalankan basis data dan itu dianggap sebagai satu basis data. Ini bukan dua database terpisah; tidak seperti seorang master dan seorang budak, atau panas dan dingin, atau aktif dan siaga. Ini adalah, kedua node tersebut bekerja bersama untuk menghadirkan satu database logis. Jadi, yang terjadi adalah, jika simpul tertentu gagal, Anda masih aktif. Jadi, ini melindungi Anda dari kegagalan tingkat server dan melakukan itu pada dasarnya dengan, mengurutkan, membelokkan sumber daya simpul, jika Anda mau, tetapi Anda masih memiliki satu titik kegagalan ke bawah untuk disk. Jadi, ini adalah cluster scalable penyimpanan bersama dan Oracle menyebut ini Real Application Cluster atau RAC.
Sekarang, solusi lain adalah dengan menggunakan cluster failover shared-storage. Jadi, di sebelah kiri saya punya simpul aktif, di sebelah kanan saya punya simpul pasif, di antaranya ada detak jantung. Saya punya array penyimpanan bersama, dan ini sangat penting; Anda harus memilikinya. Dan pada dasarnya, yang terjadi adalah jika simpul aktif menemui masalah, simpul pasif dapat mengambil alih. Ada masalah lisensi untuk ini. Beberapa vendor basis data memungkinkan Anda memiliki simpul pasif dengan lisensi yang dikurangi untuk waktu yang tetap. Dalam kasus lain, Anda harus memiliki lisensi duplikat lengkap. Itu semua tergantung pada vendor database Anda. Tetapi mereka semua mendukung jenis gambar ini yaitu, jika satu simpul turun, simpul lainnya dapat mengambil alih.
Dan biasanya, ini adalah salah satu skenario di mana itu semacam, ketika Anda pergi dari node aktif ke node pasif, Anda mungkin akan, di sebagian besar database - tidak semua - Anda akan kehilangan beberapa informasi. transaksi penerbangan. Kemudian kita masuk ke apa yang benar-benar dapat dilihat oleh administrator database, yaitu replikasi basis data, dan ada dua cara berbeda dalam melakukan replikasi basis data.
Ada replikasi fisik, dan yang penting adalah, di tengah-tengah gambar ini, Anda dapat melihat dengan bintang hijau, bahwa replikasi, itu dilakukan oleh database tetapi, seperti virtualisasi tingkat penyimpanan, itu dilakukan di blok tingkat. Jadi, kami mengulangi blok I / O yang sebenarnya dari node aktif ke node read-only atau pasif. Dan ini dianggap replikasi fisik.
Sekarang, izinkan saya pergi ke slide berikutnya karena hampir identik dan ini adalah replikasi logis dan satu-satunya hal yang berubah dalam gambar adalah bahwa di tengah, alih-alih mengirim melalui blok I / O, kami pada dasarnya mengirim lebih dari log file dengan perintah SQL di dalamnya. Jadi, dengan kata lain, apa yang kita replikasi bukanlah I / O fisik, tetapi perintah yang menyebabkan I / O fisik.
Jadi, ini sering disebut pengiriman log atau replikasi berbasis log. Beberapa vendor database memberikan ini kepada Anda secara asli. Vendor database lain mungkin tidak menawarkan ini, tetapi kemudian vendor pihak ketiga menawarkannya, dan jadi ini adalah solusi HA yang sangat populer dan itu dianggap sebagai solusi lengkap. Tetapi solusi ini terutama merupakan tanggung jawab DBA.
Jadi, saya tidak menggunakan virtualisasi untuk mencapai ini. Aku bisa, tapi aku tidak bergantung padanya. Dan saya tidak menggunakan virtualisasi penyimpanan. Sekali lagi, saya bisa, tetapi saya tidak bergantung padanya. Tapi saya sedang membangun solusi dengan database menjadi fitur utama penggerak. Jadi, ini replikasi logis.
Sekarang, dimungkinkan juga untuk menggabungkan virtualisasi basis data dan penyimpanan. Saya bisa saja, di pusat data saya, katakanlah, di sebelah kiri dengan warna biru, saya bisa melakukan virtualisasi untuk penyimpanan sehingga saya tidak terikat pada array penyimpanan yang gagal. Tapi saya mungkin melakukan replikasi logis atau log tingkat basis data dari satu pusat data ke yang lain sehingga perintah dijalankan di pusat data juga, menghasilkan I / O, tetapi tidak harus sama I / O, karena saya Saya tidak mengirim blok I / O, baik dengan solusi penyimpanan atau oleh database, tapi saya mengirim log, dan karena itu perintah SQL.
Jadi, ini adalah gambaran yang sangat umum untuk organisasi yang sangat besar. Dan saya suka gambar ini di sini karena jika saya harus mengatur ini di tempat menggunakan database seperti Oracle, saya bisa melakukannya; ini pekerjaan yang lumayan, cukup rumit, ada banyak bagian yang bergerak. Jika saya melakukan ini di cloud saya benar-benar dapat hanya mengatakan, centang, saya ingin dua wilayah geografis, saya ingin daerah dipisahkan oleh, Anda tahu, di benua yang berbeda, saya ingin virtualisasi tingkat penyimpanan di wilayah geografis tertentu. Saya bahkan dapat mengatakan bahwa saya ingin kemampuan untuk melakukan alokasi tipe virtualisasi atau definisi ketersediaan tinggi, dan sekali lagi, ini kotak centang lain.
Dan hal lain yang saya sukai di cloud, ada kotak centang lain yang sering mengatakan, "Saya tidak ingin berurusan dengan menambal, cukup tambal itu, " Anda tahu, kerjakan saja ke dalam alur kerja dari semua yang Anda lakukan di belakang Adegan, buat saya ditambal setiap saat. Jadi, sementara beberapa gambar ini menjadi sangat kompleks dan mereka mungkin sangat sulit untuk dilakukan di lokasi, mereka sebenarnya menjadi sangat mudah dilakukan di cloud.
Sekarang, hal yang menarik adalah, mudah untuk memeriksa semua kotak centang, tetapi coba tebak, itu membutuhkan lebih banyak uang setiap bulan. Karena jika Anda menjalankan dua pusat data, Anda tahu, Anda memiliki dua pusat data di cloud yang Anda manfaatkan, Anda akan membayar lebih daripada jika Anda hanya menggunakan satu. Demikian juga, jika Anda melakukan tingkat penyimpanan atau ketersediaan tinggi virtualisasi sebagai lapisan tambahan, sekali lagi, mungkin ada biaya tambahan.
Jadi, sangat menarik bahwa meskipun sulit dilakukan di situs dan Anda mungkin terlalu banyak berpikir, di cloud itu sangat mudah dilakukan, Anda bisa memikirkannya. Jadi, selalu tahu seperti apa gambar itu dan selalu tahu apa konsekuensi biaya untuk gambar apa pun yang sedang Anda bangun. Sekarang, ada lebih banyak kombinasi daripada yang saya tunjukkan di sini. Ini bukan contoh lengkap atau lengkap. Ada teknologi baru yang datang secara berkala, jadi siapa tahu - Saya mungkin tidak menunjukkan satu yang baru muncul dalam tiga bulan terakhir. Dan ketersediaan tinggi jauh lebih umum daripada sepuluh tahun yang lalu.
Kenyataannya, saya tidak akan menganggapnya terlalu berat untuk mengatakan bahwa bagi kebanyakan organisasi besar ini merupakan persyaratan bisnis wajib saat ini. Dan saya suka kembali ke slide ini karena saya baru saja mengatakan itu adalah persyaratan bisnis wajib. Dan saya punya dua meja di sebelah kanan. Yang teratas keluar dari dokumentasi SQL Server dan yang bawah keluar dari dokumentasi Oracle. Dan apa ini, ini adalah tabel untuk membantu Anda memilih, yah, metode replikasi mana yang harus Anda gunakan.
Dan perhatikan bahwa Anda mulai dengan beberapa pertanyaan yang sangat sederhana. Berapa banyak data yang saya boleh gunakan? Dan jika jawabannya nol, Anda tahu bahwa Anda hanya bisa, di bagan teratas itu, pilih baris pertama atau keempat. Lalu Anda bertanya pertanyaan lain. Berapa lama saya diizinkan untuk pemulihan? Dan jika seseorang berkata, baik, detik atau menit, maka itu membuat pilihan untuk Anda. Dan kemudian, apakah failover harus otomatis atau memerlukan seseorang secara manual untuk melakukannya? Dan itu pertanyaan bisnis lain. Mereka mungkin mengatakan bahwa mereka menginginkannya secara otomatis karena mereka tidak ingin mengandalkan, Anda tahu, prosedur eskalasi dan kemudian seseorang mendapatkan tiket dan kemudian memecahkan masalah. Mereka hanya ingin itu diperbaiki.
Ini semua adalah pertanyaan bisnis dan itu adalah pertanyaan yang sama jika saya turun dan melakukan hal yang sama untuk Oracle. Dan saya bertanya, OK, kegagalan macam apa yang saya izinkan, durasi seperti apa, apa yang bisa saya hilangkan, bagaimana prosedur pemulihannya? Ini semua adalah pilihan bisnis, jadi jika bisnis memberi saya jawaban atas tiga atau empat pertanyaan, pekerjaan saya mudah, saya hanya datang ke sini, saya memilih yang mana yang paling cocok dan kemudian saya membangunnya. Dan ingat, di cloud, mungkin hanya beberapa kotak centang untuk benar-benar mengimplementasikannya.
Dan dengan itu, itu membawa saya ke akhir materi saya dan waktu untuk membuka ini untuk pertanyaan.
Eric Kavanagh: Baiklah, Dez, mungkin Anda yang pertama dan kemudian Robin?
Dez Blanchfield: Tentu saja. Sebenarnya, mungkin sedikit tidak adil bagi mereka yang tidak di Twitter, tetapi saya hanya men-tweet gambar grafik yang ingin saya visualisasikan di benak semua orang dan kemudian saya ingin melemparkan pertanyaan kepada teman terpelajar kami melalui telepon di sini. Ketika saya memikirkan proprietary versus open source di ruang ini - yang sering kita bicarakan, semacam, database proprietary dari orang-orang seperti Oracle dan Microsoft dan sebagainya, versus open source - Anda berakhir dengan tantangan ini di mana dunia proprietary vendor perangkat lunak internet atau pengembang perangkat lunak atau perusahaan berinvestasi dalam tubuh untuk membangun kompleksitas itu. Jadi, Anda berakhir dengan skenario di mana Anda membeli perangkat lunak dan Anda tidak perlu berinvestasi pada banyak orang karena Anda membeli kemampuan bawaan dan sumber terbuka - Anda tidak membayar untuk perangkat lunak atau biayanya rendah, katakanlah, tetapi Anda tidak membayar untuk perangkat lunak, tetapi Anda harus berinvestasi dalam badan.
Dan saya ingin mendapatkan pemikiran Anda tentang juggle, terutama sekarang kita akan beralih ke model cloud di mana Anda bisa mendapatkan salah satu dari ini. Anda dapat pergi ke AWS atau Azure dan Rackspace Anda, apa pun, dan membeli sebagai layanan yang menyediakan platform basis data Anda, atau Anda dapat melakukannya melalui kode sumber terbuka. Dan apa yang baru saja kita bicarakan, apa juggle antara kepemilikan dan sumber terbuka dan bagaimana pola desain yang Anda bicarakan berpengaruh dan apa pendapat umum Anda mengenai topik ini saat kami bergerak maju, terutama tentang penyediaan ketersediaan?
Bert Scalzo: Salah satu hal besar yang saya temui ketika saya mencoba menjawab pertanyaan itu, saya kembali ke pelanggan dan bertanya kepada mereka tentang persyaratan kinerja mereka. Dan alasan saya melakukan itu adalah, saya telah menemukan - setidaknya secara historis dan dalam pengalaman saya sendiri - bahwa ketika datang ke pelanggan yang membutuhkan throughput tinggi pada replikasi mereka, saya hampir selalu lebih baik dengan replikasi yang disediakan oleh database vendor, karena sifatnya yang lebih inheren dibangun dan pada tingkat yang lebih rendah, dan kadang-kadang menggunakan mekanisme yang tidak tersedia untuk dunia luar, bahkan dalam solusi open-source.
Dan saya akan memberi Anda contoh yang baik dari satu kasus yang saya miliki. Saya memiliki perusahaan berbasis internet yang menggunakan MySQL sebagai database mereka dan mereka menggunakan MySQL versi lama, seperti, Versi 4.0, dan replikasi antara node mereka adalah faktor pembatas pada seberapa besar mereka dapat skala database mereka. Dan mereka mencari untuk membeli solusi pihak ketiga, kemudian mereka melihat, "Yah, mungkin kita bisa menggunakan salah satu solusi open-source." Dan apa yang benar-benar bermuara adalah, yang harus mereka lakukan adalah meng-upgrade MySQL mereka ke Versi, saya pikir 5, 5 kita pergi ke, karena perbedaan antara dua versi database dalam versi 4.0 dari replikasi MySQL versi tidak berulir dan in Version 5.0 it was, and that was actually the best path for them.
Now, we looked at the other choices, but the deciding factor was performance and staying with the database vendor solution, and doing the database upgrade actually ended up being our best solution to get the highest probability of getting the performance they needed to go along with the higher availability.
Dez Blanchfield: Yeah, that mirrors my own thinking, to be honest. Just for full disclosure, and I won't go into brands, but I've come from a proprietary background working for OEMs and software vendors and IOCs in general, and that's definitely been my experience and at the same time I'm very pro-open-source and I'm a code contributor for a bunch of projects that we won't name, but I agree with you in that if you're a large organization – let's say you're a bank, or whatever you might be – invariably you don't want to be an IT shop. You know, like, for example, if you're a newspaper publisher or if you're a retailer, you don't want to be an IT shop that publishes newspapers, you want to be a newspaper shop that actually just leverages IT.
And so, investing in the proprietary capabilities where the software developers build all that capability, the load balancing, and so forth, in the tool, makes a hell of a lot more sense versus if you're, like, a dotcom startup or something like that that can invest in human bodies. Where do you see this going?
Probably my last question before I hand over to Dr. Robin Bloor, because I know we're running short of time. Where do you see this going from a trend point of view? So, you're out there all the time, you're on the bleeding edge of the stuff, are you seeing people have sat up and paid attention and woken up to the need to make this a commercial part of their day-to-day conversation back to the board room? Or are you still seeing it being very much the geek farm, the techies and the hoodies thinking about availability because it makes them wake up at four o'clock in the morning when something goes offline?
Do you think the trend is swinging now to organizations of every size, not the obvious ones like airlines and banking and finance, but just businesses in general? Do you think people have really gotten out of value proposition to protect their database environments and provide high availability and investing in that, or do you think we've still got a way to go? What's the general sense in the market out there?
Bert Scalzo: Right now, I think there is still a gap, but it's not a gap because the business isn't asking for it, it's a gap in the communication levels between the two sides of the fence. In other words, the business people are very clearly saying, “These applications require high availability and have these specific requirements when we say high availability.”
And somehow or other that message is not getting clearly across to the tech people. Or the tech people will come back and say, “Oh, well that's complicated and it'll cost you more money, ” and this, that or the other. I think what's going to happen is that's going to erode away finally because, honestly, with it being, for example, in the cloud, just checking a few boxes here or there to say, “Build me this really complex technology structure, ” there's really no good reason for the technology people to come back and say to the business people, “Oh, it's expensive, ” or, “It's hard to do, ” or this or that, and the business people are starting to know that that's the fact.
And I've even seen in environments where, you know, their own IT people will come and say, “Oh, you can't have what you want. It's too expensive.” And they'll bring in a third-party consulting firm who will then say, “No, that's not correct. Here's how you could do it. Here's what it'll cost you.” So, I think we've got still a little bit of time between the communication levels between the two sides before that becomes automatic still.
Dez Blanchfield: Yeah, that's definitely mirrored what I've seen here in Australia and around Asia Pacific. I'm sure it's a global thing. And that is that a lot of the key decision makers from the boardroom down, all the heads of line of business, they're' a lot more technically savvy – they're reading the blogs, they're watching webinars, they're tuned into various articles and podcasts and they're going to events and forums and meetups and they now know their options and they know cloud is an option.
They also know that they can bring that, as you said, their capability in-house, and so I think there's this interesting challenge now, that conversation's that's got to take place which is basically what we've done today where people, kind of, start doing things internally and just run brown bag lunches and have an internal briefing on what's our current state, what's our ideal state, where do we need to get to? And then, sort of, get that together.
I had a private message which I'm just going to quickly touch on just now. Someone asked a question, “Is it realistic that you can get 100 percent availability?” And you might be able to correct me here, but I'm going to say yes. I've built a platform for an electronic funds transfer, EFTPOS gateway between swift banking platforms and the EFTPOS terminals. I built this in the early 2000s. It's actually been online 100 percent of the time for 17 years. In fact, it was built prior to the 2000s, but it went production only 2000/2001 roughly.
So, the 17 years has been in place from development to testing and then going into production. In that 17 years, very low-cost commodity off-the-shelf PCs, running an open-source operating system, but proprietary database, have been doing active/passive swapping every 90 days, with different design patents being applied, with replication of disks in each server, replication of data between model servers, replication of multiple data centers, and flipping from data center A doing production for 90 days and then flipping to data center B and doing production.
And as it flips, it automatically patches and updates so just to the question I just got privately, yes, it's possible, but with a lot of investment in that project in a design point of view. So, the infrastructure was actually not that expensive, but the design and the testing and the implementation was very expensive to get that. So, we didn't have to spend a lot of money in hardware and infrastructure, but we used very smart tools, back in the day when cloud wasn't even a coinage.
So, the answer's yes, it can be done, even more so now with cloud, as we just heard that, with the click of a button you can enable that capability. I'm going to throw that to Robin because I'm sure he's got questions as well. But thank you very much for answering my questions and I really loved hearing your message today. Completely on board with all that because it mirrors everything I've been doing for the last nearly 30 years myself.
Dr. Robin Bloor: Well, OK, I shall pick it up. One of the things that fascinated me about your presentation was the number of options that are available now that weren't available when I used to have to struggle with this stuff. I'm kind of interested in who's going to design these configurations, or who, nowadays, designs these configurations? What used to happen, or, the world that I'm used to, is that there would be a fairly heavy transactional system and you would be interested in high uptime, high availability. Because, you know, the transactional system, it would be expensive if it went down in any way. And you wouldn't have all the options that you've just presented to me, but in one way or the other, you could find a way, via replication mostly, to create a hot standby that wouldn't click in unnoticeably, but it would give you a degraded service until you got back.
And I'm, kind of, looking at what you were showing me and thinking about it, not having done any of that kind of design work for 15 years, who's doing that work now? Is this, as it was in my day, something that you did at the onset of a project, you know, get the infrastructure running? Or is this something that is an ongoing activity within an organization? Because there's new technology choices that come along.
Bert Scalzo: In the large companies who are very efficient and effective at all of their operations, including their IT, they typically will have a centralized architecture group, or they'll have some name for it, I've heard it called “the architecture group” a lot of times. And it will be their responsibility to know all these different pictures and what the pros and cons are and what the costs are. And what will happen is, when a particular application is looking and says, “Hey, I have to meet business requirements X, Y and Z. Hey, architecture team, what are my choices?”
They will give them the answer, like, here's the two or three that are available, and then at that point, the decision moves back to the lower level to the application team or to the business sponsor of the application. But typically, there's a centralized group who are staying on top of this and having that information at the ready and pre-built.
Now, it's the medium-sized companies where it's not that formal. What will tend to happen is, you will get one or two of your senior DBAs or system administrators and they will informally be quote “the domain expert” for that kind of expertise. So, even in the medium-sized companies it happens, it just happens in a non-formalized structure.
Dr. Robin Bloor: That's really kind of interesting. In my day, we would never be thinking of high availability except for the transactional systems. Well, nowadays, of course you've got streaming systems that are subject probably to even greater demands in terms of availability. But, in the query-based, back-end, analytics, data warehouse, DI kind of environment, do you ever see requirements for high availability there?
Bert Scalzo: Yeah, and I'm glad you asked that question. I did some work for a retail firm and their strategic decisions for the business were based in a large part off of the analysis they would do from the data warehouse. And, in fact, they were interviewed by Forbes Magazine and the CEO of the company said, “Hey, our stock price grew 250 percent over the last five years and a very large reason that's true is because we know how to effectively leverage our data in our data warehouse.” They were so good at making business decisions that, for them, the data warehouse and being able to do those analytics, being able to make decisions on a daily basis against their operational data, was actually, to them, a production system.
And I'll give you a good example of how important it is. With this particular retail vendor, the guy who was responsible for beer sales, he was, like, the third most important executive in the company, because he brought in, you know, 60, 70 percent of the revenue. And so, he had to be able to, in order to stay competitive in that market, he had to be able to know every day, you know, what promotions should I be running. And that could be based on, you know, not just time of the year, but, weather, patterns, and other critical data that can affect sale of something like beer.
Dr. Robin Bloor: Well I guess there's bound to be things like that. We're kind of out of time, I think I should hand on to Eric in case he's got some questions from the audience. Eric?
Eric Kavanagh: Yeah, this has all been great stuff, Bert. I think you addressed all the questions that we had from the audience in your presentation. But it is fun to watch. I'm glad that you, kind of, talked about storage virtualization and how much of an impact that can be. So, this is all good stuff.
Well, folks, we do archive all these webcasts for later viewing. So, hop online to Techopedia.com to look for the webcast section. All those Hot Techs will be listed there. A big thanks to our friend Bert for his expertise. And of course, to Dez and Robin. And with that we're going to bid you farewell, folks. Hati hati. We'll talk to you next time. Sampai jumpa.
