Співробітники компанії «Техопедія», 7 грудня 2016 року
Винос: Ведучий Ерік Кавана обговорює наявність з Робіном Блором, Дез Бланчфілдом та Бертом Скальцо.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Дами та панове, привіт і ще раз вітайте. Це чотири години східного часу в середу, і ці дні можуть означати лише одне, якщо ви перебуваєте у світі даних: знову час для Hot Technologies! Так, справді.
Мене звуть Ерік Кавана, я буду твоїм ведучим шоу. Він розроблений, щоб зрозуміти, що є гарячим, що там відбувається, які класні речі використовуються на підприємстві, і, звичайно, саме в основі всього, що ми робимо у цій цілій галузі, - це база даних. Тож ми поговоримо про захист вашої бази даних. Точна тема: "Захистіть свою базу даних: висока доступність для даних з високим попитом". Отже, слайд про ваш справді. І, досить про мене, вдарив мене у Twitter, @eric_kavanagh.
По-перше, цей рік гарячий, дані гарячі, великі дані дуже гарячі, але насправді це все ще є на межі. Більшість найсучасніших компаній використовують великі дані в наші дні, більшість організацій з виробництва хліба та масла в світі вони все ще використовують традиційні дані, і якщо ваші дані користуються великим попитом, то ви хочете переконатися, що вони доступні, оскільки коли системи знижуються, коли дані недоступні, це коли ви отримуєте нещасних клієнтів, нещасних потенційних клієнтів, ви отримуєте збитки клієнтів, ви отримуєте нещасні всілякі речі, партнерів тощо. Тому ви цього не хочете.
Ми сьогодні вчимося в одних з найкращих сьогодні в бізнесі - почуємо від власного доктора Робіна Блора, експерта по роботі з базами даних, який триває протягом трьох десятиліть. Дез Бланчфілд, який займався цим вже близько, але він почав, коли був дуже молодий, і Берт Скальцо з IDERA, який насправді є досить чорним поясом у базі даних. Тому не стримуйтесь, люди, не задавайте питань - велика частина цієї події для вас цінна, коли ви ставите хороші запитання та отримуєте хороші відповіді, тому надсилайте їх через вікно чату або компонент Q та A на вашій консолі.
І з цим я збираюся передати це Робіну Блору - забрати його.
Доктор Робін Блор: Гаразд, дозвольте мені натиснути це і побачити, чи воно рухається - це так. Я особливо не буду говорити про базу даних. Я подумав, що, знаєте, адже я роблю вступ, першу презентаційну презентацію, тож я поговорю про очікувані рівні обслуговування та, звичайно, доступність, що є угодою, яка є темою сьогоднішнього шоу.
І питання полягає в тому, щоб ви знаєте: "Дійсно, що таке наявність? І яку роль він відіграє у тому, як люди зараз управляють центрами обробки даних? "Одне, що я помітив - я помітив це фактично десь у 90-х - я працював на одному сайті, і користувачі почали скаржитися, оскільки їх електронний лист був відключений 15 хвилин.
І це було цікаво, оскільки КТО або той, хто відповідав за ІТ насправді, одне з небагатьох місць, де в ті дні вони фактично визначали рівні сервісу, а електронна пошта знижувалася протягом 15 хвилин, не порушувала чийогось рівень обслуговування. . Я думаю, що це фактично може бути на вулиці протягом двох годин. Це не електронна пошта, яку не можна було використовувати, це просто те, що ви не можете надсилати та отримувати через те, що сервер не працює. І це сповістило мене про те, що я відтоді помітив просування вперед, що все просто прискорюється, а також очікування користувачів, і це призводить вас до ситуації, коли люди можуть мати три рівні обслуговування, але часто вони почне скаржитися, коли рівні обслуговування фактично не порушені.
Отже, визначення рівнів обслуговування, просто для того, щоб це зробити - ну, це може залежати саме від того, про що ви говорите з точки зору рівня обслуговування. Ми говорили про ІТ-систему або ІТ-додаток. Зазвичай визначайте з точки зору продуктивності, доступності та показників - іншими словами, ви не можете реально визначити рівень обслуговування, якщо не зможете його виміряти, тому зазвичай проводиться якесь вимірювання, і зазвичай це час відгуку, конкретні транзакції та наявність систем протягом певного періоду часу, і до приблизно 1994–1995 рр., справді рідко було, щоб будь-які системи були доступні більше, ніж у звичайний робочий час. Тож скажімо, вісім ранку до шостої вечора, щоб нормально розтягнути - і люди будували системи, і саме це означало - на мій погляд, особливо з базою даних - ви могли налаштувати базу даних певним чином і як пакетне вікно почало скорочуватися, в деяких системах, а потім в інших системах знову почала виникати потреба думати, і тоді ми отримали появу сервісу чи архітектури, яка почала робити залежність між системами, від яких раніше не залежали один одного, роблячи все ще гірше. Ми отримали стиснення з точки зору наявності систем.
Я говорив про те, що я говорив про доступність, він включає в себе резервне копіювання та відновлення і включає - це як би не просто доступність у звичайних умовах, про які ми говоримо; існує безліч різних способів, за допомогою яких програма може вийти з ладу. Ви знаєте, ви можете отримати збої в апаратному забезпеченні або ви можете отримати збій у базі даних, ви можете отримати збій програмного забезпечення і є безліч різних видів цих речей, і коли це виникає, ви зможете відновитись, і тому вам також потрібно повернутись до систем. Тому потрібно створити схему резервного копіювання системи, і вам також на багатьох сайтах сьогодні потрібна можливість відновлення після аварій, якщо вибухне ціла будівля. І тут варто щось згадати, і я збираюся про це розповісти за хвилину, але в бізнес-процесах вони теж рівні обслуговування, а насправді - рівні обслуговування бізнес-процесу, які справді мають значення для бізнесу. ІТ просто повинен виконати свою частину цього та відповідно до будь-якої угоди.
Рівні ІТ-послуг, як правило, є допоміжними до рівнів обслуговування бізнес-процесів, але так само, як це було досить рідко 15 років тому, коли будь-яка організація мала чітко визначені рівні обслуговування, організаціям все ще досить рідко є чітко визначені рівні обслуговування для бізнес-процесів. . Це щось таке, що зараз відбувається; це не те, що триває давно.
Це прискорення та часові бар'єри, варто лише згадати часові бар'єри. Ми поступово переходимо у світ, що обробляє події, і через це ми поступово переходимо у світ реального часу, і через це ми поступово переходимо у доступність до необхідності 24 на 7, і це насправді важко для багатьох систем - це важко досягти. Або це дуже дорого, або в деяких випадках вам, можливо, доведеться змінити системи, навіть перейти на іншу базу даних, іншу версію програмного забезпечення бази даних, яку ми використовуємо.
Також ці часові бар'єри - і я завжди люблю згадувати про них, коли я отримую можливість - це часові бар'єри, з якими стикаються наші програми; програми можуть захотіти якомога швидше, саме тоді програмне забезпечення розмовляє з програмним забезпеченням. Насправді немає жодної прийнятної ліцензії в деяких ситуаціях, ви хочете бути настільки швидкими, як це можливо, і такі ситуації в ділових умовах, як ринкові ситуації, коли людина, яка приходить із замовленням на купівлю вдруге, отримує гіршу ціну, ніж хтось хто перший, і тому швидкість програмного забезпечення дійсно має значення.
Але ви знаєте, що нижче, коли ви насправді маєте справу з - взаємодіючи з - людськими істотами, найкращий час відгуку, який можна реально вимагати від вас, - це десята частина секунди, тому що це час реагування людини. Вам не потрібно йти швидше, тому що людина все одно не помітить. Між 1, 1 та чотирма секундами - час очікування, який люди нормально переносять, але як тільки ви пройдете близько чотирьох секунд, вони закінчують щось інше, і тому ви справді займаєтеся тимчасовою діяльністю.
Таким чином, ви можете бачити, що певні часові рамки та день, тиждень та місяці для тих речей, де поведінка партії має сенс, і тому ви не перебуваєте в світі обробки подій, і тому доступність може бути насправді зовсім іншою з точки зору того, що вам потрібно бути в змозі забезпечити. Але як тільки ви перебуваєте у світі подій, ви знаходитесь у доступності 24/7, а зміна технології є фактором, оскільки технологія йде все швидше і швидше, тоді доступність може не збільшуватися; воно просто залишається таким, яким воно є.
Це складні шари, і я не хочу вникати в це в будь-якій глибині, це просто, ви знаєте, тут слід розглянути три речі. Є рівень інфраструктури обслуговування, це вертикальна вісь, а потім рівень обслуговування будь-якої заданої програми, а потім рівень бізнес-сервісу, залежать один від одного, і їх потрібно враховувати якщо ви насправді дивитесь на те, щоб створити сприятливе середовище, де рівні обслуговування задовольняються, в основному.
Тоді у вас внизу, що є лише представленими базами даних, але ви можете робити все в системі, ви знаєте, що ви отримали конфігурацію без зупинки, що означає, що вона говорить: вона ніколи не зупиниться. У вас є ситуація з гарячим режимом очікування, коли в тій чи іншій мірі існують різні способи її досягнення, але так чи інакше, якщо база даних не працює, вона переходить у режим гарячого режиму очікування і дуже мало відставання в той час, коли користувачі, мабуть, помітять, але не помітять багато.
Теплий режим очікування більше схожий на 20-хвилинний перемикач, коли всі дзвонять у службу допомоги та сукаються за службою довідки, коли база даних переходить у режим очікування. Тоді виникає ситуація перезавантаження, коли це може зайняти дуже тривалий проміжок часу. Варто зазначити, що будь-яка програма чи будь-яка дана база даних можуть опинитися в будь-якій із ситуацій, залежно від того, що відбувається насправді та від того, який рівень обслуговування вимагається для програми.
З цього я просто хочу зробити крапку щодо кривої складності. Складність випливає з вузлів і зв’язків, залежностей. У світі, в якому ми живемо, кількість вузлів та з'єднань, що беруть участь у чому-небудь, просто продовжує зростати, тому ви біжите до такої кривої доцільності. Якщо ви можете подивитися на те, як складність збільшується і як зменшуються часові розміри, то ви знаєте про рівень доступності, чи є цільові показники часу, чи вони, ймовірно, зменшаться?
Отже, природна еволюція спрямована на нон-стоп, який, звичайно, є найдорожчим - принаймні, на мій досвід, - це найдорожчі конфігурації, які ви можете створити. Так чи інакше, будь-якій організації, яка замислюється над цим, дійсно потрібно думати не лише про те, що зараз відбувається, а про те, що буде в майбутньому.
Можливо, останнім моментом я хочу зауважити, що управління рівнями обслуговування - це поточна діяльність; це не те, що ви знаєте, що у вас є проект, ви робите це і все закінчено. Це не так, адже все просто змінюється. Сказавши це, я передаю м'яч Дезу.
Дез Бланчфілд: Дякую Робін. Я люблю ваш слайд відкриття. Ми щойно повторювали, я думаю, що це фільм "Пошук Немо 2". У вас Немо шукав доступність у вигляді дев’яти, що я вважав досить милим. Завжди потрібно суворий вчинок. Коли я замислююсь про тривалість роботи та доступність та високу продуктивність, перше зображення, яке мені спадає на думку, оскільки я виріс на Соломонових островах поблизу вулканів та екватора, - вулкан, що вивергається в моєму центрі обробки даних; я завжди маю на увазі цей образ, що це потенційно може статися, якщо щось вдарить. Це картина милого гору. Етна, що є північно-східним куточком Сицилії, що прямо біля Катанії.
Мій підхід до цього полягає в тому, щоб розмовляти з вами і давати вам пару виїздів на тому ж рівні, який я регулярно роблю в залі засідань C-Suite та керівників бізнесу, з тим, що у нас є розмова про те, що може вплинути на вашу організацію від комерційного чи технічного сенсу та типів техніки.
Нам потрібно думати і про те, що ми відбираємо від цього, і як ми вирішуємо деякі проблеми, про які ми говоримо, коли ми говоримо про високу доступність та час роботи, особливо навколо автоматизації та платформ.
Отже, питання, яке ми ставимо спочатку, полягає в тому, що ми маємо на увазі, коли говоримо про системи баз даних та наявність платформи бази даних? Що насправді означає говорити про актуальну проблему зробити щось доступним до рівня, про який розповідав Робін у угоді про рівень обслуговування, встановленому відображенням того, що нам насправді потрібно та хочемо?
Отже, реальність сьогодні така - і насправді тут є кілька пікових реалій у моєму розумі - сьогодні все фактично керується базами даних. Є дуже мало систем, які побудовані сьогодні та побудовані таким чином, що матеріал просто зберігається у файлах або це якийсь плоский журнал файлів; незмінно все керується базами даних. Внаслідок цього у нас є ця потреба перестати думати про доступність до цих баз даних, про різні системи та додатки та інструменти, які залежать від них, і покладатися на них для надання послуг, які ми хочемо доставити, продати чи споживати . І вся інфраструктура навколо нього.
Насправді, настільки, коли ви думаєте про великі збої в даних пізніх, зокрема, цифрових тубільців або тубільців, деяких компаній, які поєдналися, такі як Uber і Airbnb тощо, і трохи старших PayPals та світові eBays - масштаб та розмір цих організацій можливі лише завдяки сучасній технології баз даних та сучасній хмарній інфраструктурі. Без цього без додаткової наданої здатності вони точно не існували б. Уявіть собі сценарій, коли ви могли потрапити на eBay лише між 9:05 та 9:25, оскільки він був недоступний для решти дня, тому що він намагався зробити iCloud чи резервну копію чи щось подібне, просто не було б працювали.
Отже, і є інші ключові сфери, коли ви думаєте про наше повсякденне життя, знаєте, як роздрібна торгівля, банківська справа, фінанси та авіакомпанії тощо. Великі промислові групи, такі як авіаційна логістика, транспортне судноплавство, є уряд в цілому, є національна безпека, поліція тощо. Усі ці галузі, усі ці сегменти ринку, всі ці органи, групи залежать від того, що їх середовище працює та працює.
Отже, маючи на увазі, ми також маємо інший застереження, про яке ми повинні подумати, інший випадок, про який я хочу залишити вас думати, і це те, що наш світ зараз є тим, що я називаю "завжди". Ми постійно зв’язані, і цю тему ви будете чути регулярно, і я збираюся її повторити і повторити. Зараз у нас в руках смартфони цілий день, кожен день. Ми їх не вимикаємо, ми ставимо їх поруч з ліжком, ми незмінно використовуємо їх як будильники, ми використовуємо їх як камери і робимо фотографії, вони виштовхують ці фотографії в хмару.
Вони завжди увімкнені, постійно пов'язані менталітетом. Насправді є монета з фразою, яку я люблю використовувати, і це те, що ми зараз живемо поколінням Fitbit, саме там ми все вимірюємо, ми все контролюємо, і це потрібно зареєструвати і що кудись піде.
І є ще одна фраза, з якою я тебе залишу, і це десь дев'ять годин, весь час. Це світ, який ми живемо 24/7/365. Земля постійно крутиться навколо Сонця і в якийсь момент, і час, кожну годину дня - дев'ять годин. А це означає, що люди встають з ліжка і намагаються робити речі, купувати речі, встановлювати речі тощо.
Отже, що ми маємо на увазі, коли говоримо про високу доступність? Добре це звучить дійсно очевидно, поки ви не почнете занурюватися в деталі. Отже, ви знаєте, коли ми думаємо про «Гаразд, що означає висока доступність?» Ну реально, срібна куля немає. Це досить складна концепція, оскільки Робін стосувався деяких тем, про які він згадував, таких як вимірювання доступності та домовленості про рівень обслуговування. Ми відображаємо це на зразок, у мене є ці питання, чи це час роботи? Чи хвилюємося ми про такі речі, як те, що ми називаємо п’ять дев'яток, про які я піду за хвилину. Чи вважаємо ми себе тим, що є у наших угодах про рівень обслуговування? Наприклад, у угодах про рівень послуг, я маю на увазі затримки, триголосна абревіатура для угод про рівень обслуговування стає все більш критичною в ці дні.
Поки ви проходите весь цей процес, коли ви базуєтесь і самостійно влаштовуєте аутсорсинг на сторонні центри обробки даних та надавайте аутсорсинг керовані сервіси, і тепер ми йдемо повністю до хмари. А реальність - коли ти говориш про хмари, це просто справді чужі комп'ютери. А це означає, що ви не запускаєте інфраструктуру, ви не запускаєте системи і незмінно ви не запускаєте хмару. Ви робите інфраструктуру, створену як платформу, тому це ще важливіше в сервісі продажів. Тепер уявіть собі, наприклад, продажі, ви знаєте, що не торкаєтесь жодної інфраструктури, ви просто увійдете в веб-інтерфейс.
Отже, єдиний механізм, який ви маєте у тому світі хмарної та аутсорсингової інфраструктури будь-якої форми для контролю, що є угодами про рівень сервісу, це єдиний механізм, який ви маєте, і якщо люди не відповідають вашій установці, вони або терплять штрафних санкцій та зменшення кількості грошей, які ви їх сплачуєте, або ви просто не сплачуєте їх.
Отже, це повертає до уваги весь цей виклик, як ви знаєте, як нам управляти високою доступністю? Як ми можемо керувати режимом доступності, якщо це не ваша інфраструктура - наприклад, це стосується SLA. Якщо це ваша інфраструктура або навіть якщо це чужа інфраструктура як проектна точка зору. Ми говорили про збалансування навантаження до модельної науки, це патент на дизайн на відмову?
Чи працюєте у вашій архітектурі активний чи активний режим очікування? У вас є кілька серверів, кілька платформ зберігання? Як працюють ці платформи зберігання? Вони копіюють одне одного, чи дзеркально один одного? У вас працює RAID? Який тип RAID використовується для надмірного зберігання? У вас працює RAID на рівні диска? Ви використовуєте платформу об'єктів для зберігання даних, яка реплікує між модельними приводами та модельними системами та накопичувачами? Це N плюс один для кожного отриманого вами інфраструктури? Ви додаєте ще один чи він знаходиться в тому ж центрі обробки даних чи іншому центрі обробки даних? Ви створили патент на дизайн, який не передбачає жодної точки продажу, наприклад?
Всі ці основні речі, зараз вони звучать як прості поняття, але коли ви потрапляєте в кожну з цих речей, це дуже і дуже детально. Коли ми говоримо про доступність, ми незмінно закінчуємо розмову про дев’ять. А що ми маємо на увазі під дев'ятками? Ми всі про це чули, але давайте поміркуємо, що вони означають хвилину і чому вони важливі.
Отже, ми говоримо про одну дев'ятку, що становить лише 90 відсотків нашої доступності. Я знаю, що це звучить дуже високо. Отже, коли ми говоримо 24 на 7 на 365, якщо ми дивимось, наприклад, один рік, коли ми говоримо о дев’яті, що становить 90 відсотків часу, це дозволяє тридцять шість з половиною днів простою на рік. Давайте просто обійдемо це трохи більше місяця.
Тепер подумайте про будь-який бізнес, з яким ми маємо справу щодня - будь то онлайн-банкінг, eBay, PayPal або платформи соціальних медіа, такі як LinkedIn, Twitter або просто загальний роздрібний продавець - скажімо, що я хотів забронювати рейс, щоб приїхати до США із сонячного світла Австралія, я був би щасливий, якби хотів приїхати до Америки через тиждень, якщо моя улюблена авіакомпанія була тридцять шість з половиною днів, тому що їхній постачальник послуг сказав: "Подивіться, ми за 90 відсотків часу "? Звичайно, я б не став.
Коли ви піднімаєте цю модель, дві дев'ятки: 99 відсотків. Добре, що це стає 3, 65 дня, приблизно три з половиною дні простою на рік. Це велика справа? Добре, якщо ви працюєте у Чорну п’ятницю, а ви продаєте спеціальні розпродажі, і люди можуть купувати лише протягом цих двох днів.
Три дев'ятки стають всього 8, 7 годин на рік, але навіть 8, 7 годин на рік, це поспіль вісім годин нашого часу. Добре, що в банківській справі та фінансах, в галузі охорони здоров'я - якщо це лікарня, то це може коштувати життя. Коли ви піднімаєтесь вгору, чотири дев'яти - це 52 хвилини, п'ять дев'ять - це п'ять хвилин, а шість дев'яток - це в основному 30 секунд. Шість дев'яток надзвичайно високі, і коли ви піднімаєтесь по цій драбині, коли піднімаєтесь на цю ялинкову ялинку дев’яти, тим більше дев'яток піднімаєтеся, тим складніше дизайн, навколишнє середовище та платформа. Чим складніше надати цю послугу, і якщо ви думаєте про скорочення кількості часу, яке ви потребуєте для запуску резервних копій, адміністрування, виправлення, вікна технічного обслуговування для будь-якої форми відключення - всі нетривіальні проблеми - і це ефективно зводиться до відсотків відключень.
Головне, що я хотів би передати, - це немає срібної кулі, як я вже згадував раніше. Що стосується доступності, то немає "одного розміру, який підходить усім". Можливо, у вас є певний тип патенту на дизайн, який відповідає ключовим галузям. З тими ж проблемами стикаються всі банки. Деякі можуть бути роздрібними банками, деякі - преміальними банками. Деякі банки, можливо, зосереджуються на торгівлі та інвестиціях, управлінні статками. Деякі можуть бути суто споживачами. Деякі з них можуть бути лише в Інтернеті, а навіть не мають абонентів і мають справу лише з банкоматами, коли видають готівку. Тож у тих сценаріях, навіть у банківській справі та управлінні багатствами та галузі фінансових послуг в цілому, для кожного з них вони все ще мають свій особливий смак або те, що їм потрібно, якщо мова йде про доступність.
Отже, коли ми думаємо про доступність простою англійською, суміш між доступністю та високою доступністю - ми думаємо, що вони одне і те ж, але насправді це крейда та сир. Доступність - я кажу, це простою англійською мовою - це міра часу, коли сервер або процес функціонує нормально або загалом, пов'язані з їх використанням. Це просто означає, як ми описуємо, чи він доступний чи ні. Коли ми говоримо про доступність, ми часто потрапляємо в цю пастку мислення: "Я надаю це у доступній формі", порівняно з високою доступністю захисту безпеки цієї інфраструктури.
Висока доступність, в іншому розумінні простою англійською, - це дизайн, де ви впроваджуєте або досягаєте певного результату та наявності даних, зокрема там, де майже весь час –24/7/365 днів на рік - що доступність потрапляє до деяких із них дев’ять. Незмінно це не означає 100 відсотків. Сто відсотків технічно неможливо в реальному світі в жодному середовищі. Дуже важко для одного сервера в операційній системі з базою даних на ньому, з запущеною платформою, і на цьому додатку ви можете доставити його і очікувати, що він працює на 100 відсотків. Тоді ми починаємо думати про конструкції. Чи є у нас надлишки, чи є кілька слайдів для копіювання? Тоді, коли ви викладете це простою англійською мовою, цікаво, наскільки відрізняється тема доступності від високої доступності.
Я подумав, що я викладу це в реальній простой графічній формі, просто щоб дати нам уявлення про те, як це виглядає, коли ви починаєте підніматися перед проблемою підвищення доступності щодо захисту часу служби. У нижньому лівому куті у нас одинарна дев'ятка. Я виклав п’ять дев'яток, про які ми загалом говоримо. Шість дев'яти - це трохи обурливо. Коли ми говоримо про п’ять дев'яток у нижньому лівому куті, приблизно за 35 днів це невдача, це намагається забезпечити це недорогим середовищем та низькою складністю, оскільки у вас є ряд речей, які можуть вийти з ладу, і ви можете як і раніше відповідають вашим угодам про рівень обслуговування.
Але проходячись знизу зліва направо і добираючись до точки, де на малюнку більше дев'яти, ви отримуєте сценарії, де починаєте думати про тиражування систем та платформ. Ви повинні подумати про кластеризацію та віртуалізацію різних частин інфраструктури. Вам потрібно подумати про геолокацію цих кластерів, декілька сайтів центрів обробки даних, і ви повинні подумати про тип галузі та ринковий сегмент, до якого ви прагнете. Отже, який рівень обслуговування вам потрібно відповідати? Яке надання послуг ви шукаєте? Області, які є послугами на основі карт в режимі реального часу, які повідомляють про комунікації. Це військова служба? Таким чином, цей графік йде знизу вліво вгорі праворуч і, як ви проходите через цю криву, вартість і складність збільшуються. Коли ви отримуєте більш складні та вимогливі умови, вам знадобиться більше дев'яти.
Наприклад, цей графік робить дуже подібне: він описує історію між складовою вартості та бажаною складовою доступності. Отже, у верхньому лівому куті ми відображаємо високодоступні складні системи, і витрати, понесені, якщо ця доступність знизиться, порівняно з вигодою наявності в нульовому простої. Наприклад, якщо у нас є ліве середовище, де все знижується, ми можемо понести фінансові збитки. Ми маємо юридичні наслідки, які можуть мати наслідки на рівні комерційної ділової стратегії.
Можливо, є всі види потенційно, навіть, моральні проблеми, пов'язані з тим, що має переваги в обслуговуванні. Якщо це галузь охорони здоров’я, і вони починають переживати витрати на відключення, вплив на клієнтів, зниження задоволеності клієнтів, продуктивність персоналу, продуктивність користувачів тощо. Ці речі впливають, якщо ми думаємо про розробку дуже складних, сильно залежних., дуже ризиковане середовище, де існує потенційний ризик відключення, а отже, і втрат.
З правого боку ми намагаємось націлитись на сценарій, коли, якщо ми вкладаємо високу вартість і плануємо в дизайн, ми вкладаємо гроші в інтелектуальну реалізацію. Ми вкладаємо гроші в надання людям навичок та ресурсів і високо цінуємо мережеве та високооцінене операційне середовище та апаратне та програмне забезпечення. Ми отримуємо високу доступність, але це дуже дорого. Таким чином, маятникове маятникове місце маятника оптимального положення посередині, де вони перетинаються, де у нас є дещо знижена вартість, і збільшення доступності, що просто перемикається між рівнями дев'яти і високою доступністю, яка є постійною доступністю, і це постійний виклик для нас, як нам відповісти, як у скільки грошей ви готові вкласти, щоб отримати необхідний рівень обслуговування?
У нас також є тема, в яку я не буду детально описуватись, але я просто хочу, щоб ти це забрав і задумався. Різниця між середнім часом між відмовою у вашому дизайні та середнім часом відновлення. Іншими словами, чи інвестуєте ви в якіснішу інфраструктуру, більш якісний дизайн, більш якісну апаратуру та програмне забезпечення та кращу якість кваліфікованого персоналу та ресурсів для інженерних речей та скорочення середнього часу між відмовою, середнього часу, необхідного для пошуку перерви на противагу знизити інвестиції в інфраструктуру, ресурси та дизайн та сліпі патенти, високу можливість відновити? Іншими словами, якщо щось зламається, у вас багато підключити. Якщо у когось ноутбук, і він помирає, у вас є запасний. Ви передаєте їх їм і за 30 секунд вони входять. Це дуже різні кінці полюса. Верхня частина підказує, що ви розробляєте інженер з високою вартістю та високими інвестиціями, щоб уникнути невдачі, а нижній - "Я збираюся прийняти, що невдача настане, тому я збираюся інженером зробити це і бути готовим до відмови" і швидко відновитися ».
Як я вже згадував, де я міг би сказати: "Моя доступність - це не ваша доступність". Отже, коли мова йде про середовище бази даних та підтримку інфраструктури, запуск вашої бази даних та захист її та забезпечення високої доступності, насправді немає єдиного магазину . У кожного є свої потреби та бажання. Отже, ви повинні задати собі ці основні питання, які я залишу вас, і це: що ви можете собі дозволити? Я не просто кажу про долари та центи. Я кажу про організацію, що ви можете собі дозволити з ресурсів, часу та зусиль тощо, наскільки може забезпечити рівень доступності? Також, що може підтримувати ваш бізнес? Отже, наявні можливості, поточні навички, поточна інфраструктура, поточне фінансування, яке ви можете залучити. Так що жонглювати між тим, що ти можеш собі дозволити, а не тим, що можеш підтримати, - це цікавий баланс.
Крім того, вам доведеться задати собі питання: Які навички та технології у вас є? Чи можете ви передавати щось із цього завдання? Чи можете ви потім перемістити речі в хмару? Якщо у вас є інфраструктурна послуга, окрім програмного забезпечення, ви залишаєтесь без цього стека, піднімаючись далі по стеку. Тож чи варто інвестувати більше у платформи та сервіс, а не турбуватися про частину інфраструктури, чи варто дивитися на програмне забезпечення як на пропозицію послуг, оскільки вам не доведеться турбуватися про платформу?
Який тип ринку та споживача чи замовника ви обслуговуєте? Я маю на увазі, якщо ви телекомунікаційний, і хтось повинен підняти телефон, і ви постійно отримуєте тони набору, це зовсім інша задача відкрити невеликий роздрібний магазин між понеділком та п’ятницею, дев'ять-п’ять та закрити для годину в обідній час, як перукарня кутового магазину. Тож вам доведеться дуже довго і наполегливо думати, як це працює і що це означає для вашої організації, що вам потрібно мати.
І тоді жонглюйте між тим, що знаходиться у приміщенні, що розміщено зовні та потенційно, що є у хмарі. Як я вже говорив, це також є наслідком часових викликів. Таким чином, ми залишаємося на останнє запитання, яке я з нетерпінням чекаю від наших друзів в IDERA, щоб вони сказали нам, як вони вирішують ці самі речі, і це прекрасний жонглювання між відповідності бажаної та необхідної доступності та продуктивності, а також того, що потрібно вашому бізнесу та що ваш ринок і ваші споживачі потребують.
А реальність - це не подвій подвиг. Потрібно зайняти час, зусилля та гроші, щоб продумати ці речі. І незмінно це вкладення коштів у здатність людей та навичок та вкладення коштів у програмне забезпечення та інструменти для автоматизації деяких із цих процесів та надання цим людям правильних інструментів та правильних систем, щоб зробити їх життя не просто кращим, а можливим, оскільки моніторинг дуже масштабних середовищ та захист і управління цими масштабними середовищами часто виходить за межі індивідуальних можливостей людини.
Тож, маючи на увазі, я сподіваюся, що я створив сцену для великої розмови для наших друзів з IDERA, щоб поговорити про їх платформу та інструменти, і я з нетерпінням чекаю, щоб на завершення поставити кілька чудових питань. І я перейду далі.
Доктор Робін Блер: Добре. Берт, я щойно дав тобі ключі, забирай.
Берт Скальцо: Дякую! Дякую, Дез та Робін. Я продовжу тему про високу доступність ваших даних. І я фактично збираюся використовувати багато того, про що щойно говорив Дез. Отже, вибір, дев'ять, компроміси, доступність. Я спробую сказати, що більше з точки зору адміністратора бази даних чи когось ближчого до траншей, як вони би на це дивилися? Як би вони це архітектували? І що означають ці вибори.
Тепер я спробую бути агностиком бази даних. Я не збираюся малювати, наприклад, специфічне для Oracle рішення або SQL-сервер, але я буду малювати, скажімо так, загальну архітектуру, яку пропонують усі постачальники баз даних, щось у цьому напрямку. Всі вони називають це різними іменами, але це єдиний тип вибору, який у вас є спільний, і я хочу подивитися на це як з точки зору бізнесу, так і з точки зору технологій, і як це стосується бізнес-вимог.
І я хочу почати з того, що найосновніше псевдо-рішення з високою доступністю - через варіанти, які ви маєте на рішеннях на рівні зберігання, рішеннях на рівні віртуалізації, на рішеннях на рівні бази даних. І тоді я хотів би також познайомити вас із тим, що всі варіанти доступні також у хмарі.
Отже, знову ж таки, я спробую залишатися досить агностиком бази даних. Тепер більшість речей, про які я буду говорити, я знаю, що вони існують в Oracle, SQL Server, MySQL, PostgreSQL. Є також сторонні постачальники, які виготовляють інструменти, які також нададуть вам додаткову архітектуру, яку ви можете розглянути. І, як щойно сказав Дез, жодне рішення не є найкращим; все залежить. Але є один універсальний факт у тому, що ми будемо дивитись, чи буде більше рухомих деталей, тож це буде складніше і, отже, дорожче.
Отже, всі ми знаємо, що дані є важливим надбанням. І всі знають, що швидкий доступ до даних завжди приємний. Але надійний доступ до даних є критичним. І коли він говорив про свої дев'ять прикладів, чи справді ви можете дозволити собі 36½ днів простою? Важливо, щоб ці дані були доступні постійно. Отже, час простою може коштувати цілого статку, як з точки зору втраченого доходу, але ще важливіше - у втрачених клієнтів, чи у втраті доброзичливості клієнтів. Я надам вам гарний приклад; якщо певний веб-сайт, на якому я здійснюю покупки, повільний, я можу спробувати знайти новий веб-сайт, який продає подібні товари за аналогічну ціну, у яких немає повільних веб-сайтів. І так, це не лише втрата клієнта, це доброзичливість, яку замовник має до вас.
Зараз апаратні засоби набагато дешевші в цей час, тому тому все більший попит на високу доступність. І знову я збираюся вести нас до хмари, коли ми це дивимось. А у нас є пропозиції різних рівнів: постачальники сховищ, постачальники баз даних, постачальники віртуалізації, а тепер навіть постачальники хмар. І ось, що насправді цікаво з хмарою - це після того, як я намалював усі ці чудові фотографії цих архітектур, які ви могли побудувати в хмарі, багато разів - це лише деякі прапорці, які ви перевіряєте. А ви кажете: "Я хочу тиражувати в усіх географічних регіонах". "Я хочу тиражувати ключові апаратні компоненти". Отже, якщо ви розумієте картинки, іноді в хмарі це просто перевірка декількох коробок, щоб створити ту картину, яку ви отримали на увазі.
Тепер ключовим є те, які бізнес-вимоги до високої доступності? Наприклад, чи потрібно мені турбуватися лише про помилки на одному веб-сайті, чи потрібно мати його на кількох сайтах? Іншими словами, чи можу я мати один обчислювальний центр, і мені байдуже, чи той центр перейде в офлайн? Я не висуваю вимог бізнесу, щоб він розширювався на декілька сайтів. Це ділове питання. І важливо знати, як сприймає бізнес відповіді на це питання, адже це, як правило, визначає ваш бюджет.
Тепер ви також хочете подивитися на рівень захисту від відмов. Чи може це бути відключенням живлення? Чи може це бути збій компонента? Як і NIC або HBA погано, адаптер хост-шини. Це поганий жорсткий диск? Це поломка шафи для зберігання? Це помилка комп'ютера? Або в деяких випадках це збій сайту? Це інакше, ніж, в деяких випадках, ви можете мати збій на сайті, оскільки сам сайт в автономному режимі. В іншому випадку може бути, що значна частина сайту в автономному режимі, але з вашого погляду це весь сайт.
І тоді, як Дез говорив, який очікує час на відновлення операцій? Це ділове питання. Якщо бізнес каже, що ви зможете відновити операції протягом двох хвилин, очевидно, це визначить деякі з цих зображень, які я збираюся показати, що ви працюєте, а деякі з них не будуть варіантами, які ви може вибрати.
І ще одне питання, яке виникає під час високої доступності, але часто люди забувають запитати: "Ей, бізнес, якщо щось трапляється, коли я перебуваю в середині обробки транзакції, що мені дозволяється втратити після відновлення системи?" " Іншими словами, якщо я можу повернути систему назад за дві хвилини, і я можу втратити не більше 10 секунд, скажімо, транзакцій, які були в польоті, це прийнятний бізнес? І знову, це визначить, що бізнес готовий витратити на це, а потім ще раз, це може визначити, які фотографії, які я збираюсь показати вам, застосовуєте чи не застосовуєте.
Отже, почнемо з найпростішого псевдо-рішення з високою доступністю. Це насправді не надто висока доступність, але я люблю починати з цього, тому що це змушує людей думати правильно. Якщо у мене є сервер і масив пам’яті, зазвичай я розміщую кілька серверів NIC, мережевих інтерфейсних карт на цьому сервері і зв’язую їх так, що якщо один NIC вийде з ладу, я все ще буду. І я зроблю те саме, що з адаптерами хост-шини, я буду переходити через різні комутатори, так що у мене є кілька способів дістатися до мого сховища. І я отримав універсальний блок живлення, і у мене в масиві зберігання є контролери, що повторюються, і, можливо, я зробив щось на зразок RAID 10 зі своїми дисками. Іншими словами, на цій фотографії я запобігла виходу однокомпонентних збоїв на декількох рівнях. Отже, я не пов'язаний NIC, або HBA, або контролером, або комутатором.
Але якщо ви помітили, сервер червоний, а масив пам’яті - червоний. У мене ще є дві області, де якщо вони виходять з ладу, якщо мій сервер заходить, я мертвий, якщо мій кабінет масиву зберігання йде, я мертвий. Отже, хоча це не дуже висока доступність, воно починає вас бачити і дивитися на картину і казати: "Я хочу малюнок, де немає червоного". І ось це справді мета цих картин, щоб нас вказали в правильному напрямку.
Отже, перше, що має відбутися, - це як DBA, я завжди хотів би поставити рішення з високою доступністю як реалізацію бази даних, але можливо, це можливо, що це можна зробити як рішення для зберігання даних, або це може бути що це може бути реплікація рівня зберігання. У випадку зліва, у мене є віртуалізація пам’яті. Що відбувається - у мене є RAID 0 у двох різних шафах для зберігання дисків, але RAID 1 у двох різних шафах для зберігання даних. Іншими словами, у мене зараз може вийти з ладу шафа для зберігання, і я не мертвий. Отже, це краще, ніж попереднє зображення, тому що в попередньому малюнку - пам’ятайте, у нас було як червоний на сервері, так і червоний на масиві пам’яті - і тепер ми зробили невелике покращення, тепер у нас більше немає червоного кольору на рівні пам’яті, я використовував - віртуалізація зберігання вирішила цю проблему.
Тепер, ще один спосіб, як ви могли це зробити - і не всі постачальники цього забезпечують - це те, що ви можете зробити реплікацію на рівні зберігання. Я не кажу про реплікацію бази даних, я фактично кажу про реплікацію блоку вводу-виводу для вашого сховища. І це можна зробити на рівні зберігання. І так знову, тепер у мене з правого боку є ще одне зображення, де я знімаю червоний колір знизу, бо використовую реплікацію пам’яті.
Отже, це ще одна картина, яка може бути, а може і не бути в наявності. І особа, яка керувала б цим, може бути вашим адміністратором пам’яті, а не адміністратором вашої бази даних. Мені подобається піднімати це, тому що іноді люди думають про: "О! Висока доступність, ця проблема повинна вирішувати DBA". Це не завжди так; в цьому випадку він може бути адміністратором пам’яті.
Тепер далі ми можемо зробити віртуалізацію сервера як можливе рішення. Тепер, якщо ви пам’ятаєте, на першому знімку у мене був червоний на сервері та червоний на масиві пам’яті. Я міг би в цьому випадку, використовуючи віртуалізацію, я міг би переїхати, а в деяких випадках переїзд - це якесь тепле переїзд, а в деяких випадках насправді навіть може бути гарячим переїздом. Деякі віртуалізації або гіпервізори забезпечують можливість переміщення віртуальної машини в польоті. І деякі бази даних легко сприймуть цей рух у польоті. Зараз, знову ж таки, не всі гіпервізори забезпечують це, але це один із можливих рівнів рішення. Тепер я зробив, що верхні сервери вже не червоні, але все ще маю спільний масив пам’яті і здогадуюся, що це рішення може бути спільним зусиллям між адміністратором бази даних та адміністратором віртуалізації. Або навіть це може бути лише адміністратор віртуалізації, залежно від того, який рівень переїзду підтримується на цьому гіпервізорі та цій базі даних.
Якщо вам цікаво: "Вау, що він має на увазі під цим переїздом? Наведіть конкретний приклад ». Наприклад, у VM, де ви можете використовувати VMotion для переміщення віртуальної машини з одного хоста на інший і робити це без простоїв. Тепер ясно, що на попередньому знімку все ще було червоне. У мене все ще було сховище як єдине місце відмови. І тому ми переходимо до наступного рішення, яке, ну, дозвольте мені поєднати сховище та віртуалізацію сервера.
Тепер у цьому випадку знову може бути адміністратор пам’яті та адміністратор віртуалізації, який будує це рішення, і тепер подивіться: у мене є зображення, на якому немає червоного. У мене висока доступність, оскільки я можу перемістити віртуальну машину або запущений додаток або базу даних з одного сервера на інший, і я маю віртуалізацію в своєму масиві зберігання, роблячи це RAID 1 через два окремі масиви зберігання. Я багаторазово переміщав свої перемикачі та свої HBA.
Отже, тепер я створив систему HA, і я це зробив, головним чином, не на рівні бази даних. Іншими словами, я використовував інші технології, щоб здійснити те саме. Отже, це рішення. Тоді ми потрапляємо до того, що називається масштабованим кластером спільного зберігання. Це насправді не рішення HA, але знову ж таки, я люблю це показувати для малюнка.
І що тут відбувається - у нас є два сервери, на яких працює база даних, і це вважається однією базою даних. Це не дві окремі бази даних; це не як хазяїн і раб, чи гарячий і холодний, або активний і черговий. Це означає, що обидва ці вузли працюють разом, щоб представити одну логічну базу даних. І так, що трапляється, якщо певний вузол виходить з ладу, ви все ще піднімаєтеся. Таким чином, він захищає вас від збоїв на рівні сервера і робить це, в основному, начебто, прискорюючи ресурси вузла, якщо ви хочете, але у вас все одно є одна точка відмови до диску. Отже, це кластер, що масштабується з спільним зберіганням, і Oracle називає цей реальний кластер додатків або RAC.
Тепер іншим рішенням є використання кластеру відмови від спільного зберігання. Отже, ліворуч у мене активний вузол, праворуч - пасивний вузол, між ними у мене серцебиття. У мене є спільний масив пам’яті, і це дуже важливо; ви повинні мати це. І в основному, те, що відбувається, якщо активний вузол зіткнеться з проблемами, пасивний вузол може перейняти його. У цьому є проблеми з ліцензуванням. Деякі постачальники баз даних дозволяють мати пасивний вузол зі зниженою ліцензією протягом певного часу. В інших випадках вам доведеться мати повне копіювання ліцензій. Все залежить від постачальника вашої бази даних. Але всі вони підтримують таку картину, яка є, якщо один вузол опуститься, другий вузол може перейняти.
І, як правило, це один із тих сценаріїв, коли це свого роду, коли ви переходите від активного вузла до пасивного вузла, ви, мабуть, у більшості баз даних - не у всіх - ви втратите частину вбудованого, польотні операції. Потім ми розбираємося в тому, що дійсно може подивитися адміністратор бази даних, що є реплікацією бази даних, і є два різні способи реплікації бази даних.
Існує фізична реплікація, і що важливо, в середині цієї картини ви можете побачити із зеленою зіркою, що реплікація, це робиться в базі даних, але, як і віртуалізація на рівні зберігання, це робиться в блоці рівень. Отже, ми повторюємо фактичний блок вводу / виводу з активного вузла на вузол, що приймає лише читання, або пасивний. І це вважається фізичною реплікацією.
Тепер, дозвольте мені перейти до наступного слайду, тому що він майже однаковий і це логічна реплікація, і єдине, що змінюється на малюнку, - це те, що посередині, замість того, щоб надсилати через блок вводу / виводу, ми по суті надсилаємо через журнал файли з командами SQL в ньому. Отже, іншими словами, те, що ми реплікуємо, - це не фізичний I / O, а команди, які викликають фізичний I / O.
Отже, це часто називають доставкою журналу або реплікацією на основі журналу. Деякі постачальники баз даних надають вам це вдома. Інші постачальники баз даних можуть не пропонувати цього, але тоді пропонують його сторонні постачальники, і це дуже популярне рішення HA, і це вважається повним рішенням. Але це рішення в першу чергу є відповідальністю DBA.
Отже, я не використовую віртуалізацію для цього. Я міг би, але я від цього не залежний. І я не використовую віртуалізацію пам’яті. Знову міг би, але я від цього не залежний. Але я будую рішення, коли база даних є основною функцією водіння. Отже, це логічна реплікація.
Тепер також можна поєднувати віртуалізацію бази даних та зберігання. У моєму центрі обробки даних, скажімо, ліво-синім кольором ліворуч я міг би мати віртуалізацію для зберігання, щоб я не прив'язувався до відмови певного масиву пам’яті. Але я можу робити логічну реплікацію на рівні бази даних або логічну реплікацію з одного центру обробки даних в інший, щоб команди виконувались і в центрі обробки даних, в результаті чого входи-виведення, але не обов'язково однакові введення-виведення, тому що я ' не надсилаю через блок вводу / виводу ні рішення для зберігання, ні базу даних, але я пересилаю журнали, а отже, команди SQL.
Отже, це картина, яка є дуже поширеною картиною для дуже великих організацій. І мені подобається ця картинка тут, тому що якщо мені доведеться встановити це на приміщенні за допомогою бази даних, як Oracle, я можу це зробити; це досить велика робота, вона досить складна, багато рухомих деталей. Якщо я це роблю в хмарі, я можу буквально просто сказати, прапорець, я хочу два географічні регіони, я хочу, щоб регіони були розділені, ви знаєте, на різних континентах, я хочу віртуалізацію рівня зберігання у певному географічному регіоні. Навіть можу сказати, що я хочу зробити розподіл типів віртуалізації або визначення високої доступності, і знову ж таки, це ще один прапорець.
І інше, що мені подобається у хмарі, є ще один прапорець, який часто говорить: "Я не хочу займатися виправленням, просто закріпіть його", ви знаєте, просто працюйте в робочому процесі всього іншого, що ви робите за сцени, тримайте мене латками весь час. Отож, хоча деякі з цих зображень стають дуже складними, і це може бути дуже важко зробити в приміщенні, насправді це стає досить легко зробити у хмарі.
Тепер цікаво, що легко встановити всі прапорці, але здогадайтесь, що коштує більше грошей щомісяця. Оскільки, якщо ви працюєте з двома центрами обробки даних, знаєте, у вас є два центри обробки даних у хмарі, яку ви використовуєте, ви заплатите більше, ніж якщо ви просто використовували один. Крім того, якщо ви робите рівень зберігання або високу доступність віртуалізації в якості додаткового шару, знову можуть виникнути додаткові витрати.
Отже, цікаво, що хоча це важко зробити на місці, і ти можеш його переосмислити, у хмарі це так просто зробити, ти можеш задуматися. Отже, завжди знайте, як виглядає малюнок, і завжди знайте, які кошти мають для будь-якої картини, яку ви будуєте. Зараз є набагато більше комбінацій, ніж те, що я показав тут. Це не повний чи вичерпний приклад. Нові технології надходять регулярно, тож хто знає - я, можливо, не показав жодної, що з’явилася за останні три місяці. А висока доступність набагато частіше, ніж це було десять років тому.
Насправді, я б не вважав за розтяг говорити, що для більшості великих організацій це є обов'язковою вимогою бізнесу в ці дні. І мені подобається повертатися до цього слайду, тому що я просто сказав, що це обов'язкова ділова вимога. І я отримав ці дві таблиці праворуч. Верхня частина - із документації на SQL Server, а нижня - з документації Oracle. І що це, це таблиці, які допоможуть вам вибрати, який метод реплікації ви повинні використовувати.
І зауважте, що ви починаєте з дуже простих питань. Скільки даних мені дозволено використовувати? І якщо відповідь нульова, ви знаєте, що ви можете лише в цій верхній діаграмі вибрати перший чи четвертий ряд. Тоді ви ставите ще одне питання. Ну, як довго мені дозволено приймати відновлення? І якщо хтось каже, ну, секунди чи хвилини, то це робить вибір для вас. І тоді, чи повинен відмовитися бути автоматичним чи для цього потрібен хтось вручну? І це ще одне ділове питання. Вони можуть сказати, що вони хочуть це автоматично, тому що вони не хочуть покладатися на, напевно, процедуру ескалації, а потім хтось отримує квиток і потім вирішує проблему. Вони просто хочуть, щоб це було виправлено.
Це все питання бізнесу, і це ті самі запитання, якщо я знижусь і зроблю те саме для Oracle. І я запитую, добре, яку помилку я дозволяю, яку тривалість, що я можу втратити, яка процедура відновлення? Це все бізнес-варіанти, тож якщо бізнес каже мені відповіді на три-чотири запитання, моя робота справді проста, я просто заходжу сюди, я вибираю те, що з цих відповідає найближчим, і тоді я будую це. І пам’ятайте, у хмарі може бути лише кілька прапорців, щоб реально їх реалізувати.
І з цим, це підводить мене до кінця свого матеріалу та часу, щоб відкрити це для запитань.
Ерік Кавана: Добре, Дез, може, ти спочатку, а потім Робін?
Дез Бланшфілд: Абсолютно. Насправді, мабуть, трохи несправедливо для тих, хто не в Twitter, але я просто твітнув зображення графіку, яке хочу візуалізувати у всіх у свідомості, і тоді я хотів передати це питання нашому вченому другу під час дзвінка тут. Коли я думаю про власність проти відкритого коду в цьому просторі - про що ми часто говоримо, про власні бази даних, подібні до Oracle і Microsoft тощо, проти відкритих джерел - ви стикаєтеся з цим завданням, у якому власний світ постачальник програмного забезпечення в Інтернеті або розробник програмного забезпечення або компанія інвестує в органи, щоб створити цю складність. І так, ви закінчите сценарій, коли ви купуєте програмне забезпечення, і вам не потрібно вкладати гроші у багатьох людей, тому що ви купуєте можливість, вбудований у відкритий і вихідний код - ви не платите за програмне забезпечення або це низька вартість, скажімо, але ви не платите за це програмне забезпечення, але вам доведеться інвестувати в органи.
І я прагну розглянути ваші думки про жонглювання, особливо зараз, коли ми переходимо до хмарних моделей, де можна отримати або /, або. Ви можете перейти до AWS або Azure та вашої Rackspace, будь-що, і придбати послугу, що надає вашу платформу бази даних, або зробити це через відкритий вихідний код. І про що ми тільки що говорили, що таке жонглювання між власником та відкритим кодом та як дизайнерські моделі, про які ви говорите, набувають чинності та які ваші загальні думки щодо цієї теми, коли ми рухаємось вперед, особливо щодо забезпечення доступності?
Берт Скальцо: Один із великих предметів, з якими я стикаюся, коли намагаюся вирішити це питання, я повертаюся до замовника і запитую їх про їхні вимоги до ефективності. І чому я це роблю, це те, що я виявив - принаймні історично і на власному досвіді - те, що, коли мова йде про клієнтів, які потребують високої пропускної здатності для їх тиражування, я майже завжди краще розглядаю реплікацію, яку надає база даних постачальника, зважаючи на природу, що вона вбудована і вона знаходиться на нижчому рівні, а іноді використовує механізми, недоступні для зовнішнього світу, навіть у рішенні з відкритим кодом.
І я наведу вам гарний приклад одного з випадків, які я мав. У мене була інтернет-компанія, яка використовувала MySQL як свою базу даних, і вони були на старій версії MySQL, наприклад, версії 4.0, і реплікація між їхніми вузлами була обмежуючим фактором того, наскільки великі вони могли масштабувати свої бази даних. І вони дивилися на придбання стороннього рішення, потім дивились: "Ну, може, ми можемо використати одне із відкритих джерел". І те, що воно насправді зводилося до цього, все, що вони повинні були зробити, це оновити MySQL до Версії, я думаю, це було 5, 5, ми пішли, тому що різниця між цими двома версіями баз даних була у версії 4.0 реплікації MySQL не була потоковою і у версії 5.0 це було, і це був насправді найкращий шлях для них.
Тепер ми розглянули інші варіанти, але вирішальним фактором була ефективність та дотримання рішення постачальника баз даних, і оновлення бази даних насправді виявилося нашим найкращим рішенням, щоб отримати найбільшу ймовірність отримання необхідної продуктивності. тим більша доступність.
Дез Бланчфілд: Так, це відображає моє власне мислення, якщо чесно. Просто для повного розкриття інформації, і я не буду входити в бренди, але я прийшов з власного досвіду, який працює для виробників оригінальних виробників та програмного забезпечення та МОКів взагалі, і це, безумовно, мій досвід, і в той же час я дуже професійний -відкрити джерело, і я дописувач коду для багатьох проектів, які ми не будемо називати, але я згоден з вами в тому, що якщо ви велика організація - скажімо, ви банк, або все, що ви можете бути - незмінно ти не хочеш бути ІТ-магазином. Ви знаєте, як, наприклад, якщо ви видавець газети чи продавець, ви не хочете бути ІТ-магазином, який видає газети, ви хочете бути газетним магазином, який фактично використовує лише ІТ.
І так, вкладення у власні можливості, де розробники програмного забезпечення будують усі ці можливості, врівноважують навантаження і так далі, в цьому інструменті, мають пекельний сенс набагато більше, ніж якщо ви, начебто, запуск dotcom чи щось таке як, що може інвестувати в людські тіла. Куди ви бачите, що це йде?
Можливо, моє останнє запитання, перш ніж я здати доктору Робіну Блору, тому що я знаю, що нам не вистачає часу. Де ви бачите, що це відбувається з точки зору тренду? Отже, ти весь час там, ти перебуваєш на межі, що кровоточить, чи бачиш ти, як люди сіли і звернули увагу і прокинулися перед необхідністю зробити це комерційною частиною свого щоденного дня - денна розмова назад до кімнати правління? Або ти все ще бачиш, що це дуже сидить на фермах-вундеркіндах, техніках та толстовках, які думають про доступність, бо це змушує їх прокидатися о четвертій ранку, коли щось переходить в офлайн?
Як ви думаєте, зараз тенденція коливається для організацій будь-якого розміру, не очевидних, таких як авіакомпанії та банківські справи та фінанси, а лише бізнесу взагалі? Чи вважаєте ви, що люди справді вийшли з ціннісних пропозицій, щоб захистити свої середовища баз даних та забезпечити високу доступність та інвестиції в це, чи ви думаєте, у нас ще є шлях? Який загальний сенс на ринку там?
Берт Скальцо: Зараз я думаю, що ще існує розрив, але це не розрив, оскільки бізнес цього не просить, це розрив у рівнях комунікацій між двома сторонами забору. Іншими словами, ділові люди дуже чітко говорять: "Ці програми вимагають високої доступності та мають ці особливі вимоги, коли ми говоримо про високу доступність".
І так чи інакше це повідомлення не переходить чітко до людей, що знають технологію. Або технічні люди повернуться і скажуть: "О, добре, що складне, і це коштуватиме вам більше грошей", і це, те чи інше. Я думаю, що трапиться, це остаточно зникне, тому що, чесно кажучи, при цьому, наприклад, у хмарі, просто перевіряючи кілька тут або там, щоб сказати: "Створіть мені цю дійсно складну технологічну структуру". насправді немає вагомих причин для того, щоб люди, які повернулися до технології, повернулися і сказали діловим людям: "О, це дорого" або "Це важко зробити", або те чи інше, і ділові люди починають знати, що це факт.
І я навіть бачив у середовищах, де, знаєте, їх власні ІТ-люди прийдуть і скажуть: «О, ти не можеш мати того, чого хочеш. Це занадто дорого ". І вони привезуть сторонніх консалтингових фірм, які потім скажуть:" Ні, це не правильно. Ось як ви могли це зробити. Ось, що це вам коштуватиме. "Отже, я думаю, у нас є ще небагато часу між рівнями зв'язку між двома сторонами, перш ніж це все ще стане автоматичним.
Дез Бланчфілд: Так, це, безумовно, відображає те, що я бачив тут, в Австралії та навколо Азіатсько-Тихоокеанського регіону. Я впевнений, що це глобальна річ. І це те, що багато ключових осіб, що приймають рішення, з зали засідань, всі керівники бізнесу, вони набагато технічніше - вони читають блоги, вони переглядають вебінари, вони налаштовані на різні статті та подкасти, і вони збираються на події, форуми та зустрічі, і тепер вони знають свої варіанти, і вони знають, що хмара - це варіант.
Вони також знають, що вони можуть донести до цього, як ви сказали, їхні здібності, і тому я думаю, що зараз є ця цікава проблема, що розмова повинна відбутися, і це в основному те, що ми сьогодні зробили там, де люди, , почніть робити все внутрішньо і просто проведіть обід у коричневій сумці та проведіть внутрішній інструктаж про те, який у нас зараз стан, який ідеальний стан, куди нам потрібно дістатися? А потім, начебто, зібрати це разом.
У мене було приватне повідомлення, яке я просто зараз швидко торкнуся. Хтось задав питання: "Чи реально, що ви можете отримати 100-відсоткову доступність?", І ви, можливо, зможете мене тут виправити, але я скажу так. Я створив платформу для електронного переказу коштів, шлюз EFTPOS між швидкими банківськими платформами та терміналами EFTPOS. Я будував це на початку 2000-х. Це насправді в мережі 100 відсотків часу протягом 17 років. Насправді вона була побудована до 2000-х, але виробництво йшло лише у 2000/2001 роках.
Отже, 17 років пройшло від розробки до тестування, а потім до виробництва. За ці 17 років дуже недорогі товарні нестандартні ПК, що працюють з операційною системою з відкритим кодом, але власницькою базою даних, здійснювали активну / пасивну заміну кожні 90 днів із застосуванням різних патентів на дизайн із тиражуванням диски на кожному сервері, реплікація даних між модельними серверами, реплікація декількох центрів обробки даних та відвернення від центру обробки даних A, що займається виробництвом протягом 90 днів, а потім перевертання до центру обробки даних і здійснення виробництва.
І коли він перегортає, він автоматично виправляє та оновлює, так що лише до питання, яке я отримав приватно, так, це можливо, але з великою кількістю інвестицій в цей проект з точки зору дизайну. Так, інфраструктура насправді була не такою дорогою, але дизайн та тестування та реалізація були дуже дорогими, щоб отримати це. Отже, нам не довелося витрачати багато грошей на обладнання та інфраструктуру, але ми використовували дуже розумні інструменти ще в той час, коли хмара не була навіть монетою.
Отже, відповідь "так", це можна зробити, тим більше зараз із хмарою, як ми щойно почули, що натисканням кнопки ви можете включити цю можливість. Я збираюся кинути це Робіну, бо впевнений, що і у нього є питання. Але дуже дякую, що відповіли на мої запитання, і я дуже любив сьогодні почути ваше повідомлення. Повністю на борту з усім цим, тому що воно відображає все, що я робив за останні майже 30 років сам.
Доктор Робін Блор: Ну добре, я підберу це. Однією з речей, яка мене зачарувала у вашій презентації, - це кількість варіантів, які зараз доступні, коли вони були недоступні, коли мені доводилося боротися з цими матеріалами. Мене начебто цікавить, хто збирається проектувати ці конфігурації, або хто сьогодні розробляє ці конфігурації? Те, що раніше було, або в світі, до якого я звик, - це те, що існувала б досить важка трансакційна система, і вам було б цікаво високий час роботи, висока доступність. Тому що, знаєте, транзакційна система була б дорогою, якби вона в будь-якому разі знизилася. І у вас не було б усіх варіантів, які ви мені щойно представили, але так чи інакше ви можете знайти спосіб, головним чином, за допомогою реплікації створити гарячий режим очікування, який не натискатиметься непомітно, але це надасть вам деградований сервіс, поки ви не повернетесь.
І я, начебто, дивлюся на те, що ти мені показував і думав про це, не роблячи жодної подібної дизайнерської роботи протягом 15 років, хто займається цією роботою зараз? Це, як було в мої дні, щось, що ви робили на початку проекту, знаєте, запускаєте інфраструктуру? Або це щось, що є постійною діяльністю в організації? Тому що тут є нові технології вибору.
Берт Скальцо: У великих компаніях, які дуже ефективні та ефективні у всіх своїх операціях, включаючи свої ІТ, вони, як правило, матимуть централізовану архітектурну групу, або вони матимуть якусь назву для цього, я чув, що це називається " архітектурна група »багато разів. І їхня відповідальність буде знати всі ці різні картинки, які плюси і мінуси і які витрати. І що станеться, коли певна програма шукає і каже: "Ей, я повинен відповідати бізнес-вимогам X, Y і Z. Ей, архітектурна команда, що я вибираю?"
Вони дадуть їм відповідь, наприклад, ось два або три, які є в наявності, і тоді в цей момент рішення повертається на нижчий рівень, до групи заявок або до бізнес-спонсора заявки. Але, як правило, є централізована група, яка залишається над цим і має цю інформацію заздалегідь готовою та попередньо створеною.
Зараз це середні компанії, де це не так формально. Що, як правило, відбудеться, це те, що ви отримаєте одного або двох ваших старших DBA або системних адміністраторів, і вони неофіційно будуть цитувати "експерта по домену" для такого роду експертизи. Так, навіть у середніх компаніях це відбувається, це просто відбувається в неформалізованій структурі.
Доктор Робін Блор: Це справді цікаво. У мої дні ми ніколи не думали б про високу доступність, окрім транзакційних систем. Ну, а зараз, звичайно, у вас є потокові системи, які, можливо, пред'являються ще більшим вимогам щодо доступності. Але, коли ви бачите запити, бек-енд-енд, аналітика, сховище даних, оточення DI, ви коли-небудь бачите вимоги до високої доступності там?
Берт Скальцо: Так, і я радий, що ти задав це питання. Я зробив деяку роботу для роздрібної фірми, і їх стратегічні рішення для бізнесу значною мірою базувались на аналізі, який вони будуть робити зі сховища даних. І насправді з ними взяли інтерв'ю журналу Forbes, і генеральний директор компанії сказав: «Ей, ціна акцій зросла на 250 відсотків за останні п’ять років, і це дуже велика причина, тому що ми знаємо, як ефективно використовувати наші дані в нашому сховищі даних. "Вони були настільки гарні у прийнятті бізнес-рішень, що для них сховище даних і вміння робити таку аналітику, здатні приймати рішення щодня проти їхніх операційних даних. виробнича система.
І я наведу вам гарний приклад того, як це важливо. Цей конкретний продавець роздрібної торгівлі, хлопець, який відповідав за продажі пива, він був, мовляв, третім найважливішим керівником компанії, адже він приносив, знаєте, 60, 70 відсотків доходу. І так, він мав змогу, щоб залишатися конкурентоспроможними на цьому ринку, він повинен був знати кожен день, знаєте, які акції я повинен проводити. І це могло б базуватися на, знаєте, не лише порі року, але й погоді, зразках та інших важливих даних, які можуть вплинути на продаж чогось, наприклад, пива.
Доктор Робін Блор: Ну, мабуть, такі речі повинні бути такими. У нас щось поза часом, я думаю, я повинен передати Еріку на випадок, якщо у нього з’являться якісь запитання від аудиторії. Еріку?
Ерік Кавана: Так, це все було чудово, Берт. Я думаю, ви вирішили усі питання, які ми мали від аудиторії у вашій презентації. Але це весело дивитися. Я радий, що ви, начебто, говорили про віртуалізацію сховища та про те, який вплив може бути. Отже, це все хороші речі.
Ну, люди, ми зберігаємо всі ці веб-трансляції для подальшого перегляду. Отже, перейдіть в Інтернеті на Techopedia.com, щоб шукати розділ веб-трансляції. Усі ці гарячі технології будуть перераховані там. Велика подяка нашому другові Берту за його досвід. І звичайно, до Деза та Робіна. І з цим ми попрощаємося, люди. Піклуватися. Ми поговоримо з вами наступного разу. Бувай.
