От служители на Techopedia, 7 декември 2016 г.
Отнемане: Домакинът Ерик Кавана обсъжда наличността с Робин Блур, Дез Бланчфийлд и Берт Скалцо на IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Дами и господа, здравей и добре дошли отново. Това е четири часа източно време в сряда и тези дни това може да означава само едно, ако сте в света на данните: отново е време за горещи технологии! Да, именно.
Казвам се Ерик Кавана, ще ви бъда домакин на шоуто. Той е предназначен да разбере какво е горещо, какво се случва навън, кои са готините неща, които се използват в предприятието и, разбира се, точно в основата на всичко, което правим в цялото това поле, е базата данни. Така че ще говорим за защита на вашата база данни. Точната тема е „Защитете своята база данни: Висока наличност за данни с високо търсене“. Така че, има слайд за истински вашите. И, достатъчно за мен, удари ме в Twitter, @eric_kavanagh.
Първо, тази година е гореща, данните са горещи, големите данни са много горещи, но наистина все още е вид на ръба. Повечето от най-модерните компании използват големи данни в наши дни, повечето организации за хляб и масло там по света все още използват традиционните данни и ако вашите данни са с голямо търсене, тогава искате да гарантирате, че те са налични, защото когато системите спадат, когато данните са недостъпни, това е, когато получавате нещастни клиенти, недоволни перспективи, получавате бързина на клиентите, получавате нещастни всякакви неща, партньори и т.н., така че не искате това.
Ще се научим от едни от най-добрите днес в бизнеса - ще чуем от собствения ни д-р Робин Блур, експерт по бази данни от около три десетилетия. Дез Бланчфийлд, който се занимава с това от доста време, но той започна, когато беше много млад, и Берт Скалцо от IDERA, който наистина е доста черен колан на базата данни. Така че не се сдържайте, хора, задавайте въпроси - голямата част от това събитие е ценна за вас, когато задавате добри въпроси и получавате добри отговори, затова ги изпратете през прозореца за чат или Q и A компонента на вашата конзола.
И с това ще го предам на Робин Блур - отнеси го.
Д-р Робин Блур: Добре, нека кликнете върху това и да видя дали се движи - прави се. Няма да говоря особено за базата данни. Помислих си, че знаете, защото правя интро, първото представяне на въвеждането, така че ще говоря около очакваните нива на услуги и разбира се наличност, което е сделката, която е темата на днешното шоу.
И въпросът е да знаете: „Наистина, какво е наличност? И каква роля играе в начина, по който хората управляват центрове за данни в наши дни? ”Едно нещо, което забелязах - забелязах това всъщност някъде през 90-те - работех в един сайт и потребителите започнаха да се оплакват, защото имейлът им беше прекъснат 15 минути.
И това беше интересно, защото CTO или който и да отговаряше за ИТ всъщност имаше едно от малкото места, където през онези дни всъщност бяха определили нивата на услугата и имейлът беше свален в продължение на 15 минути, не нарушава никого нивото на услугата, Мисля, че това е позволено да бъде навън за два часа, всъщност. Това не беше имейл, не можеше да се използва, а просто не можете да изпращате и получавате, защото сървърът е излязъл. И този вид ме предупреди за факта, че съм забелязал да се движа напред оттогава, че всичко просто се ускорява и също така очакванията на потребителите и това ви води до ситуацията, в която хората може да имат три нива на обслужване, но често те ще започне да се оплаква, когато нивата на услугата действително не са нарушени.
Така че дефиниране на нивата на обслужване, само за да - да, може да зависи точно от това, за което говорите по отношение на нивата на услуги. Говорихме за ИТ система или ИТ приложение. Обикновено дефинирайте по отношение на производителността, наличността и показателите - с други думи, не можете да дефинирате наистина ниво на услуга, освен ако не можете да го измерите, така че обикновено има някакъв вид измерване и обикновено става въпрос за време на реакция, конкретни транзакции и наличността на системите за определен период от време и преди около 1994–1995 г., наистина рядко се налагаше да се предлагат системи за повече от обичайното работно време. Така че нека да кажем осем сутринта до шест вечерта, за да дадем нормален период от време - и хората изградиха системи по този начин и това означаваше - според мен, особено с базата данни - бихте могли да конфигурирате базата данни по определен начин и като пакетният прозорец започна да се свива, необходимостта да мислим отново започна да възниква в някои системи, а след това и в други системи, след което получихме появата на услуга или архитектурата, която започна да прави зависимости между системи, които преди не са били зависими от помежду си, което прави всичко още по-лошо. Ние стиснахме по отношение на наличието на системите.
Точката, която изтъквах, беше, когато говорим за наличност, тя включва архивиране и възстановяване и включва - все едно не е просто наличност в нормалните условия, за които говорим; има много различни начини, по които дадено приложение може да се провали. Знаете, можете да получите повреда в хардуера или можете да получите повреда в базата данни, можете да получите софтуерна повреда и има много различни видове от тези неща, а когато се случи, трябва да можете да се възстановите и следователно трябва да върнете обратно нагоре системите. Така че трябва да има някаква схема за архивиране на системата и вие също в много сайтове в днешно време се нуждаете от способността за възстановяване при бедствия в случай, че цяла сграда избухне. И нещо, което си струва да спомена тук, и ще се спра на това за минута, но бизнес процесите, те също имат нива на обслужване и всъщност нивата на обслужване на бизнес процеса, които наистина имат значение за бизнеса. ИТ просто трябва да направи своята част от това и според каквото и да е споразумение.
Нивата на ИТ услугите обикновено са спомагателни за нивата на обслужване на бизнес процесите, но тъй като преди 15 години наистина беше рядко някоя организация да има добре дефинирани нива на услуги, все още е доста рядко организациите да имат добре дефинирани нива на услуги за бизнес процеси, Това е нещо, което се случва сега; не е нещо, което продължава от дълго време.
Това са бариерите за ускорение и време, просто си струва да споменем бариерите във времето. Постепенно преминаваме в свят на обработка на събития и поради това постепенно се преместваме в свят в реално време и поради това постепенно преминаваме в наличност, за да се изискваме 24 на 7, а това всъщност е трудно за много системи - това е трудно постижим. Или е много скъпо, или в някои случаи може всъщност да се наложи да промените системите, дори да се преместите в друга база данни, различна версия на софтуера за база данни, който използваме.
Също така тези времеви бариери - и винаги обичам да ги споменавам винаги, когато имам възможност - това са бариери във времето, в които се сблъскват нашите приложения; приложенията може да искат да бъдат възможно най-бързи, когато софтуерът говори със софтуера. Наистина няма приемлив лиценз в някои ситуации, искате да сте толкова бързи, колкото е възможно, и тези ситуации в бизнес условия като пазарни ситуации, при които човекът, който идва с втората поръчка за покупка, получава по-ниска цена от някой кой идва на първо място и затова скоростта на софтуера наистина има значение.
Но знаете, че по-долу, когато всъщност се занимавате - взаимодействате с - човешките същества, най-доброто време за реакция, което наистина може да се изисква от вас, е една десета от секундата, защото това е времето за реагиране на човека. Не е нужно да вървите по-бързо от това, защото човек така или иначе няма да забележи. Между 1, 1 и четири секунди е време за изчакване, което човешките същества нормално ще понасят, но щом преминете около четири секунди, те се отказват да правят нещо друго и следователно наистина сте в активна партида.
Така че можете да видите, че определени времеви рамки и ден, седмица и месеци за онези неща, при които поведението на партида има смисъл и следователно не сте в света на обработка на събития, и следователно наличието може да е всъщност съвсем различно по отношение на това, от което се нуждаете да мога да осигуря. Но щом сте в света на събитията, тогава сте в някаква денонощна наличност и промяната на технологията е фактор, тъй като технологията върви все по-бързо и по-бързо, тогава наличността може да не се увеличи; просто остава такъв, какъвто е.
Това е сложни слоеве и не искам да навлизам в това в дълбочина, просто, знаете, тук трябва да се разгледат три неща. Има ниво на инфраструктура на обслужване, това е вертикалната ос, след това има ниво на обслужване на всяко приложение и след това има ниво на бизнес услуги, които са зависими един от друг и те трябва да бъдат взети под внимание ако всъщност търсите създаване на отзивчива среда, където нивата на обслужване са изпълнени, по принцип.
След това тук, долу в долната част, която е току-що представена бази данни, но можете да направите всичко в системата, знаете, че сте получили конфигурацията за непрекъснато, което означава, че тя казва: тя никога няма да спре. Имате гореща ситуация в режим на готовност, където по един или друг начин има различни начини за постигането му, но по един или друг начин, ако база данни не успее, тя се превключва в гореща готовност и има много малко изоставане във времето, до момента, в който потребителите вероятно биха забелязали, но не биха забелязали много.
Топлият режим на готовност прилича повече на 20-минутното преминаване, при което всички звънят на бюрото за помощ и кучкат в бюрото за помощ, докато базата данни се превключва в режим на готовност. Тогава възниква ситуация на рестартиране, при която това може да отнеме много дълъг период от време. Струва си да се отбележи, че дадено приложение или дадена база данни може да се окаже във всяка една от ситуациите в зависимост от това какво всъщност става и от това, какво всъщност се изисква нивото на услугата на приложението.
От това просто искам да направя точка за кривата на сложност. Сложността произтича от възли и връзки, зависимостите. В света, в който живеем, броят на възлите и връзките, участващи във всичко, просто продължава да расте, така че тичаш към този вид целесъобразна крива. Ако можете да разгледате начина, по който сложността се увеличава и начина, по който времевите измерения се свиват, тогава знаете за нивата на наличност, има ли времеви цели, вероятно ли ще намаляват?
И естествената еволюция следователно е към непрекъсната работа, която разбира се е най-скъпата - поне според моя опит - това е най-скъпата конфигурация, която можете да създадете. По един или друг начин всяка организация, която мисли за това, наистина трябва да мисли не само за това, което се случва сега, но какво ще се случи в бъдеще.
Може би последната точка, която искам да отбележа, е управлението на нивата на услугите да е продължаваща дейност; не е нещо, което знаеш, че имаш проект, правиш го и всичко свършва. Не е, защото нещата просто продължават да се променят. След като каза това, ще предам топката на Дез.
Дез Бланчфийлд: Благодаря ти Робин. Обичам вашия слайд за отваряне. Току-що имахме повторение, мисля, че това е филмът „Намиране на Немо 2“. Немо търсеше наличност под формата на деветки, което мислех за доста сладко. Винаги труден акт, който трябва да следвате. Когато се замисля за продължителност и наличност и висока производителност, първото изображение, което идва на ум, тъй като израснах на Соломоновите острови в близост до вулкани и екватора, е вулкан, изригващ в моя център за данни; имам това изображение, което винаги имам в ума си, че ето какво потенциално може да се случи, ако нещо се чуе. Тази картина на прекрасната планина Етна, която е североизточният ъгъл на Сицилия, който е точно до Катания.
Моят подход към това е да провеждам разговор с вас и да ви дам няколко начина на същото ниво, което редовно правя в заседателна зала от C-пакети и ръководители на бизнес с оглед, че имаме разговор за това какво може да повлияе на вашата организация от търговски или технически смисъл и видовете инженеринг.
Трябва да мислим и как - какво отнемаме от това и как да се справим с някои предизвикателства, за които говорим, когато говорим за висока наличност и продължителност, особено около автоматизацията и платформите.
И така, въпросът, който поставяме първоначално, е какво всъщност имаме предвид, когато говорим за системи от бази данни и наличност на платформата на базата данни? Какво всъщност означава да говорим за действителното предизвикателство да направим нещо достъпно до ниво, както Робин говори в споразумението за ниво на услугата, инсталирано картографиране на това, което всъщност се нуждаем и искаме?
И така, реалността на днешния ден е, че - и всъщност тук има няколко върхови реалности в съзнанието ми - днес всичко е ефективно управлявано от база данни. Има много малко системи, които са изградени днес и са изградени по такъв начин, че нещата просто се съхраняват във файлове или са някакъв плосък регистър на файловете; неизменно всичко се управлява от база данни. В резултат на това имаме тази необходимост да спрем да мислим за наличността на тези бази данни, за различните системи и приложения и инструменти, които зависят от тях, и разчитаме на тях да доставят услугите, които търсим да доставим, продаем или консумираме, И цялата инфраструктура около него.
Всъщност, толкова много, когато мислите за големите прекъсвания на данните за късно, по-специално за дигиталните туземци или местните потребители, някои от компаниите, които се срещат като 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-Server решение, но ще нарисувам, да речем, обща архитектура, която предлагат всички доставчици на база данни, нещо в тази посока. Всички го наричат с различни имена, но това е един вид избор, който имате общо, и искам да разгледам това както от гледна точка на бизнеса, така и от технологията и как е свързано с бизнес изискванията.
И искам да започна от това, което е най-основното решение за псевдо-висока достъпност, чрез опциите, които имате на решения на ниво съхранение, решения на ниво виртуализация, на решения на ниво база данни. И тогава искам да ви запозная с факта, че всички избори са налични и в облака.
И така, отново, ще се опитам да остана доста агностик на базата данни. Сега повечето неща, за които ще говоря, знам, че съществуват в 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.
Сега, друго решение е да използвате клъстер за отказ от споделено съхранение. И така, отляво имам активен възел, отдясно имам пасивен възел, имам пулс между тях. Имам споделен масив за съхранение и това е изключително важно; трябва да го имаш. И по принцип, това, което се случва е, ако активният възел срещне проблеми, пасивният възел може да поеме. Това има проблеми с лицензирането. Някои доставчици на база данни ви позволяват да разполагате с пасивен възел с намален лиценз за фиксирано време. В други случаи трябва да имате пълно дублиране на лицензи. Всичко зависи от вашия доставчик на база данни. Но всички те поддържат този вид картина, която е, ако единият възел слиза, другият възел може да поеме.
И обикновено това е един от онези сценарии, при които е нещо като, когато преминете от активния възел към пасивния възел, вероятно в повечето бази данни - не всички - ще загубите част от трансакционни полети. След това влизаме в това, което администраторът на база данни наистина може да разгледа, което е репликация на база данни и има два различни начина за извършване на репликация на база данни.
Има физическа репликация и важното е, че в средата на тази снимка можете да видите със зелената звезда, че репликацията се прави от базата данни, но подобно на виртуализацията на ниво съхранение, това се прави в блока ниво. Така че, повтаряме действителния блок I / Os от активния възел към само четещия или пасивния възел. И това се счита за физическо възпроизвеждане.
Сега, нека да отида на следващия слайд, тъй като е почти идентичен и е логично репликация и единственото нещо, което се променя в картината е, че в средата, вместо да изпращаме през блоковия I / O, ние по същество изпращаме през дневника файлове с SQL командите в него. Така че, с други думи, това, което репликираме, не са физическите I / O, а командите, които причиняват физическия I / O.
И така, това често се нарича доставка на журнали или репликация въз основа на дневника. Някои доставчици на база данни ви дават това. Други доставчици на база данни може да не предлагат това, но тогава доставчици от трети страни го предлагат и затова това е много популярно решение за HA и се счита за цялостно решение. Но това решение е основно отговорност на DBA.
Така че, аз не използвам виртуализация, за да постигна това. Можех, но не съм зависим от това. И не използвам виртуализация на съхранението. Отново бих могъл, но не съм зависим от това. Но аз изграждам решение, като базата данни е основната функция за шофиране. Това е логично репликация.
Сега също е възможно да се комбинират виртуализация на база данни и съхранение. Можех в моя център за данни, да речем, отляво в синьо, да мога да имам виртуализация за съхранението, така че да не съм обвързан с определен масив за съхранение. Но може да правя лог-базирана или логическа репликация на ниво база данни от един център за данни в другия, така че командите да се изпълняват и в центъра за данни, което води до I / O, но не непременно същата I / O, защото I ' не изпращам през входно / изходния блок, нито от решението за съхранение, нито от базата данни, но изпращам регистрационните файлове и следователно SQL командите.
И така, това е картина, която е много често срещана картина за много големи организации. И тук ми харесва тази картина, защото ако трябва да настроя това на предпоставка, използвайки база данни като Oracle, мога да го направя; това е доста голяма работа, доста сложна е, има много движещи се части. Ако направя това в облака, мога буквално просто да кажа, квадратче, искам два географски региона, искам регионите, разделени от, знаете, на различни континенти, искам виртуализация на ниво съхранение в определен географски регион. Дори мога да кажа, че искам възможността да направя разпределение на типа за виртуализация или дефиниция с висока наличност, и отново, това е друга отметка.
И другото, което ми харесва в облака, има друга отметка, която често казва: „Не искам да се занимавам с кръпка, просто го закърпете“, знаете, просто го задействайте в работния процес на всичко останало, което правите зад сцени, дръжте ме закърпен по всяко време. И така, докато някои от тези снимки стават много сложни и може да се окажат много трудни за предпоставки, те всъщност стават доста лесно да се правят в облака.
Интересното е, че е лесно да проверите всички квадратчета, но познайте какво, това струва повече пари на месечна база. Тъй като, ако използвате два центъра за данни, знаете, че имате два центъра за данни в облака, който използвате, ще плащате повече, отколкото ако просто използвате такъв. По същия начин, ако правите нивото на съхранение или високата наличност за виртуализация като допълнителен слой, отново може да има допълнителни разходи.
Така че е интересно, че макар да е трудно да се направи на място и може да го преодолееш, в облака е толкова лесно да се направи, че можеш да го подмислиш. Така че, винаги знайте как изглежда картината и винаги знайте какви са разходите за последната картина, която изграждате. Сега има много повече комбинации от това, което показах тук. Това не е пълен или изчерпателен пример. Има нови технологии, които идват на редовен интервал, така че кой знае - може да не съм показал такава, която току-що се появи през последните три месеца. А високата наличност е много по-често срещана, отколкото преди десет години.
Всъщност не бих считал за разтягане да кажа, че за повечето големи организации това е задължително бизнес изискване в наши дни. И аз обичам да се връщам към този слайд, защото току-що казах, че това е задължително бизнес изискване. И получих тези две маси отдясно. Горната част е извън документацията на SQL Server, а долната - от документацията на Oracle. И какви са това, това са таблици, които ще ви помогнат да изберете, добре, кой метод на репликация трябва да използвате.
И забележете, че започвате с някои много прости въпроси. Колко данни мога да използвам? И ако отговорът е нула, знаете, че можете само в горната диаграма да изберете първия или четвъртия ред. След това задавате още един въпрос. Е, колко време ми е позволено да взема за възстановяването? И ако някой каже, е, секунди или минути, тогава това прави избор за вас. И тогава, отказът трябва ли да бъде автоматичен или изисква някой ръчно да го направи? И това е друг бизнес въпрос. Те могат да кажат, че го искат автоматично, защото не искат да разчитат на ескалационна процедура и след това някой получава билет и след това решава проблема. Те просто искат да се оправи.
Това са все бизнес въпроси и едни и същи въпроси, ако сляза и направя същото за Oracle. И питам, ОК, какъв отказ допускам, каква продължителност, какво мога да загубя, каква е процедурата за възстановяване? Това са всички бизнес избори, така че ако бизнесът ми каже отговорите на три или четири въпроса, работата ми е много лесна, просто влизам тук, избирам кой от тези съвпадения е най-близкият и тогава го изграждам. И не забравяйте, че в облака може да са само няколко квадратчета за реално прилагане на тези.
И с това това ме довежда до края на материала ми и времето да отворя това за въпроси.
Ерик Кавана: Добре, Дез, може би ти първо, а после Робин?
Дез Бланчфийлд: Абсолютно. Всъщност, вероятно е малко несправедливо за тези, които не са в Twitter, но просто туитвах снимка на графика, която искам да визуализирам в съзнанието на всеки и тогава исках да прехвърля въпроса на нашия учен приятел по време на разговора тук. Когато се сетя за собственост срещу отворен код в това пространство - за което често говорим, нещо като патентовани бази данни от харесвания на Oracle и Microsoft и така нататък, срещу отворен код - вие се озовавате пред това предизвикателство, в което собственият свят интернет доставчикът на софтуер или разработчикът на софтуер или компанията инвестира в органите, за да изгради тази сложност. И така, завършвате със сценарий, при който купувате софтуера и няма нужда да инвестирате в много хора, защото купувате способността, вградена и с отворен код - не плащате за софтуера или е ниска цена, да речем, но не плащате за софтуера, но трябва да инвестирате в органите.
И аз искам да разбера вашите мисли за жонгъла, особено сега, когато се движим в облачни модели, където можете да получите или /, или. Можете да отидете до AWS или Azure и вашето Rackspace, каквото и да е, и да си купите като услуга, която осигурява платформата на вашата база данни, или можете да го направите чрез отворен код. И това, за което току-що говорихме, какво е жонглирането между патентован и отворен код и как дизайнерските модели, за които говорите, влизат в сила и какви са вашите общи мисли около тази тема, докато вървим напред, особено около осигуряването на наличност?
Bert Scalzo: Едно от големите елементи, в които се сблъсквам, когато се опитвам да адресирам този въпрос, се връщам при клиента и ги питам за техните изисквания за ефективност. И причината да го направя е, че открих - поне исторически и от моя собствен опит - че когато става въпрос за клиенти, които се нуждаят от висока пропусквателна способност при тяхното копиране, почти винаги съм по-добър с репликацията, предоставена от базата данни доставчик, поради естеството, че е по-присъщо вграден и е на по-ниско ниво, а понякога използва механизми, които не са достъпни за външния свят, дори в решение с отворен код.
И ще ви дам един добър пример за един случай, който имах. Имах интернет базирана компания, която използва MySQL като тяхна база данни и те бяха на стара версия на MySQL, като версия 4.0, и репликацията между техните възли беше ограничаващият фактор за това колко големи могат да мащабират своите бази данни. И те гледаха да си купят решение на трети страни, след което гледаха: „Е, може би можем да използваме едно от решенията с отворен код“. И това, което наистина се свеждаше, беше, че всичко, което трябваше да направят, беше да надстроят MySQL до Версия, мисля, че беше 5.5, ние отидохме, тъй като разликата между тези две версии на базата данни беше в 4.0 Версията на MySQL репликацията не беше резбована и във Версия 5.0 това беше и това всъщност беше най-добрият път за тях.
Сега разгледахме другите възможности за избор, но решаващият фактор беше ефективността и оставането с решението на доставчика на базата данни и извършването на ъпгрейд на базата данни всъщност се оказа най-доброто ни решение за получаване на най-голяма вероятност за постигане на необходимата им ефективност. по-високата наличност.
Дез Бланчфийлд: Да, това е огледало на собственото ми мислене, за да бъда честен. Само за пълно разкриване и няма да се впускам в марки, но произхождам от собствена среда, работеща за OEM производители и доставчици на софтуер и IOC като цяло и това определено е моят опит и в същото време съм много професионалист -Open-source и аз съм сътрудник на кода за куп проекти, които няма да назовем, но аз съм съгласен с вас, ако сте голяма организация - да речем, че сте банка или каквото може бъди - неизменно не искаш да бъдеш ИТ магазин. Знаете, например, ако сте издател на вестници или сте търговец на дребно, не искате да бъдете ИТ магазин, който публикува вестници, искате да сте магазин за вестници, който всъщност само използва ИТ.
И така, инвестирането в собствените възможности, където разработчиците на софтуер изграждат цялата тази способност, балансирането на натоварването и така нататък, в инструмента, има адски много по-голям смисъл в сравнение с това, ако сте, например, стартиране на 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, за да потърсите секцията за уеб предаване. Всички тези горещи техники ще бъдат изброени там. Голяма благодарност на нашия приятел Берт за неговата експертиза. И разбира се, на Дез и Робин. И с това ще се сбогуваме, хора. Пази се. Ще говорим с вас следващия път. Чао чао.
