Співробітники компанії «Техопедія», 26 травня 2016 року
Винос: Ведучий Ерік Кавана обговорює управління базами даних та виявлення екземплярів з Робіном Блором, Дез Бланчфілдом та Буллеттом Манале в останньому епізоді Hot Technologies.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Добре, пані та панове. Ласкаво просимо ще раз. Мене звуть Ерік Кавана. Речі гарячі. Тут нагріваються речі. Я не знаю, що відбувається. О, це правильно, настав час для Hot Technologies. Так, мене звати ще раз Ерік Кавана. Ви можете знайти мене на Twitter @eric_kavanagh. Це шоу, яке створене для того, щоб поговорити про те, що на ринку гаряче. Заголовок сьогодні, "Ключі від Королівства: управління SQL сервером за допомогою динамічного відкриття". Там справді ваш. Гаразд, ця картина була з декількох років тому. Я не збираюся брехати, зараз виглядаю трохи старше, але це нормально.
Отже, ми говоримо про те, як технології та SQL Server є насправді, дуже, дуже, дуже гарячими. Сьогодні у нас є цілий куточок вмісту, тому я одразу передам його. Постаньте, ось ми і підемо. Там наші спікери. І Робін Блор йде першим.
Робін Блор: Так. Презентація заглибиться в управління базами даних, тому я просто подумав, що я пробежуся через управління базами даних або, знаєте, лабіринт бази даних, щоб привернути людей до духу цього. Я раніше був DBA, я гадаю, ви можете сказати, що я був консультантом БД приблизно 20 років тому, і те, що насправді мене дивує в базах даних, - це те, що багато чого не змінилося. Багато чого змінилося з точки зору швидкості, з точки зору обсягів даних і подібних речей, але значна частина насправді залишається дуже схожою на те, що раніше.
На мою думку, база даних - це організований розширюваний збір даних, який можна оптимізувати під конкретні навантаження та забезпечити можливості управління даними. Він з'явився насамперед тому, що якщо ви хотіли керувати даними у файлах, це була жахливо важка робота. І ідея скласти частину програмного забезпечення, яке б зробило майже все, що вам потрібно для цього, зникло майже миттєво, як тільки ми отримали випадковий доступ до мейнфреймів IBM ще в 1970-х.
Реляційна база даних була винайдена в 70-х роках і почала існувати з точки зору прототипів у 80-х і набула свого роду тягу на ринку з початку 90-х років. А реляційні бази даних все ще залишаються надзвичайно домінуючими за популярністю. Якщо ви прочитаєте пресу, то почуєте дуже багато речей, про них сказано - бази даних SQL, і останнім часом дуже багато шуму щодо баз даних графіків. І це цікаво, якщо вам подобається, але насправді все ще в останніх числах продажів, реляційні бази даних мають 95% ринку. І Microsoft SQL Server, про який ми сьогодні поговоримо детально, є другим за популярністю Oracle.
Що стосується реляційних баз даних, що робить їх незвичними щодо двигунів, якими вони є, вони можуть працювати як на OLTP, так і на запит навантаження. Ви повинні налаштувати їх по-різному, якщо ви збираєтесь це робити, але вони насправді здатні до обох типів навантаження. Один з них - це короткі випадкові транзакції, а другий - довгі запити, що охоплюють багато даних. Альтернативно, база даних NoSQL і база даних графіків - це в основному аналітика, і вони зросли досить недавно. NoSQL з'явився першим, і останнім часом граф почав отримувати трохи тяги. NoSQL можна використовувати для транзакційних дій, але графіки майже ніколи не використовуються для транзакційних дій. Причина, я натрапив на статистику, яка насправді, на мою думку, становить щонайменше десять років, яка говорить про те, що більшість компаній має принаймні три, насправді ця цифра становила 3, 5, різних марок баз даних, якщо подивитися на їх інвентар програмного забезпечення.
Але реальність полягає в тому, що більшість компаній стандартизуються на певну базу даних. І більшість компаній стандартизували або SQL Server, і Oracle, як дві найпопулярніші для, за своїм бажанням, стандартні бази даних. І вони використовують альтернативи лише у виняткових обставинах, коли, наприклад, вони отримують програмний пакет, який потребує іншої бази даних, або вони збираються після деяких великих цілей на аналітику даних, які вже існують.
Ми також отримали, якщо хочете, втручання Хадоопа. Hadoop так чи інакше став більш ніж файловою системою, але ще не базою даних. Однак у нього є SQL, який знаходиться над його вершиною. Але докази там є, що насправді це не витісняє ні де-небудь близьке до витіснення реляційних баз даних, які заробили серця та розум світу. І причиною цього справді є те, що реляційні бази даних потребували двадцяти років, фактично довше, ніж двадцять років, щоб стати такими ж хорошими, як і вони. І ви не просто будуєте двигун запитів або SQL-движок, який справді працює в дуже малій кількості часу. Це просто не відбувається.
І тому висновок цього слайда полягає в тому, що бази даних є стратегічними і вони розвиваються, стають кращими. І це, безумовно, так було з Oracle та Microsoft SQL Server. Напевно, мало хто з вас згадує ті часи, коли вперше з’явилися бази даних, але я це зробив, тоді я був хлопчиком. Первісна ідея полягала в тому, що буде створена єдина база даних, і це була концептуальна ідея, яка абсолютно ніколи не прижилася. Була спроба IBM з AS / 400 фактично створити файлову систему на базі даних, але це також не домінувало. Вам залишається той факт, що бази даних природно фрагментуються. У вас, природно, є кілька примірників. Є проблеми масштабування. База даних масштабується лише до певного розміру, правда, розмір збільшувався з роками, але вони мали обмеження.
І виникали проблеми з завантаженням, головне питання навантаження полягало в тому, що навантаження OLTP та великі навантаження на запити просто не сумісні між собою. І неможливо було побудувати двигун, який би це зробив. Що ми стикаємось, що цікаво, я нещодавно натрапив на сайт, який мав понад тисячу різних примірників Oracle. Я не можу точно пригадати, скільки у них було DBA, але якщо ви насправді поговорили з ними про те, скільки цих баз даних насправді контролював DBA, це було щось на кшталт десяти. Вони в основному використовували базу даних як шафу і просто кидали в неї дані, оскільки принаймні у вас була схема, і вона була більш організованою, ніж колись файлова система, але ніхто не робив нічого, крім того, щоб надати їй конфігурацію за замовчуванням та встановити її розпушений.
Я не впевнений, чи це було гарною ідеєю. Для мене це звучить химерно, якщо чесно, тому що, на мою думку, кожного разу, коли я працював з базами даних, необхідні були відвідування баз даних, і вам потрібно було, так чи інакше, точно знати, що там відбувається. А надзвичайно багато системних взаємозалежностей означають, що певні рівні сервісу абсолютно повинні бути дотримані, інакше у вас виникнуть проблеми.
Нещодавно були розмови, я натрапив на різні бази даних, які стверджують, що самонастроюються. Магазини стовпців, які налаштовані для трафіку запитів, значною мірою самостійно налаштовуються, оскільки є дуже два варіанти, які потрібно прийняти з точки зору індексів. Але крім цієї конкретної області, бази даних потрібно налаштовувати. І їх потрібно налаштувати, певні реляційні бази даних, головним чином через те, що дуже багато транзакцій передбачає приєднання. Приєднання - це дорога діяльність. Якщо ви не ставите правильні індекси в потрібне місце, тоді приєднання займає непомірні кількості часу, коли вони цього не потребують.
В даний час самонастроювані бази даних добре існують лише в тих областях, де навантаженість добре відома. І мій досвід полягає в тому, що більшість компаній використовують дуже мало DBA, і це тому, що вони дорогі. І тому краще, якщо ви зможете чергувати те, що робить DBA. Це діяльність DBA, наскільки я їх розумію. Вони роблять установку, конфігурацію та оновлення баз даних. Оновлення, до речі, не обов'язково є тривіальною діяльністю. Я маю на увазі причину того, що ви оновили базу даних, це правило, з яким я завжди працював, не торкайтеся її, якщо вона працює, і якщо ви збираєтеся оновити базу даних до будь-якої нової нової версії, ви робите це в тестовому режимі спочатку і після цього ви все модернізуєте. Ви все ще завжди маєте справу з однаковою версією. Але насправді багато сайтів, на які я натрапив, це не те, що відбувається. Існує, скажімо, неабиякий ступінь ентропії. Управління ліцензіями - це проблема, залежить від того, яку ліцензію ви отримали. ETL та реплікація даних.
Один із хитрощів із базою даних - якщо у вас є навантаження на запит, яку потрібно розділити, ви можете створити два екземпляри та копіювати, і це часто робиться там, де люди використовують репліку як гарячу резервну копію, якщо це необхідно. Тоді планування зберігання та ємності - це частина діяльності DBA, оскільки, звичайно, зростають дані, і вам потрібно це відстежувати. І тоді потрібно планувати різні оновлення обладнання або розширення обладнання. Існує усунення несправностей, яке є болючим для більшості DBA. Якщо щось піде не так, і резервне копіювання не працює абсолютно ідеально, і тоді їм доведеться закатати рукави, спуститися і спробувати відновити речі з файлів журналів. Це трапляється набагато частіше, ніж я думаю, добре, я пам'ятаю, що це відбувалося, але я був поза грою принаймні десять років, але я пам'ятаю, що це відбувається частіше, ніж ти коли-небудь очікував. Моніторинг продуктивності та налаштування - це лише серце, що б'ється в роботі DBA. Але є також безпека з точки зору управління доступом, резервного копіювання та відновлення, створюючи тестові системи програмного забезпечення, які розумно паралельні живій системі. І весь життєвий цикл даних. Так що, на мою думку, це список робочих місць DBA окрім всього іншого, що їх можуть попросити зробити. Операційна динаміка. Зрештою, цілісність даних та управління рівнем обслуговування - головна відповідальність DBA. І зазвичай вони критичні. І це все, що я маю сказати. Я збираюся здати Дез.
Дез Бланшфілд: Дуже дякую. Я збираюся взяти нас у трохи веселої, анекдотичної подорожі, чому вся тема, про яку сьогодні йде мова, і більш критична, ніж будь-коли. Не так давно я брав участь у проекті, коли ми мігрували державну платформу, яка використовувалася для реєстрації ліцензій та реєстрації транспортних засобів, і цілий ряд речей навколо цієї теми, з платформи Fujitsu mainframe, на якій працювала річ під назвою A + Addition, яка є операційною системою Solaris, або іншими словами, Unix, запускає Oracle і дуже добре справляється з цим. І думка полягала в тому, що ця річ старіє і настав час перенести її на щось інше. У нас було дуже весело запускати Unix на мейнфреймі, і він був дуже стабільним і дуже захищеним і, як не дивно, платформою SDL, і це було абсолютно блискавично. Але мудрість полягала в тому, що настав час вийти з мейнфрейму та рухатися.
Ця суттєва проблема зіставити всі системи та бізнес-логіку та середовище SQL для баз даних під ними, а також дивитися на те, як ми збираємось архітектором та інженером нового будинку для цього. І ми в кінцевому підсумку взяли його до однієї з таких речей, якій вже пару років, але до одного з верхніх кінці серверів системи стійки Sun Starfire. І це, мабуть, одна з найбільших жерсті, яку ви можете придбати на планеті, яка живе в одній великій коробці та симетричному багатопроцесорному сервері. Це була система середнього класу в нашому світі. Він керував Unix, і він керував Oracle споконвічно, і думка полягала в тому, що "що може піти не так?" Ну, виявляється, багато.
Наприклад, у той час, і про це ми вже не давно говоримо, нам довелося пройти дуже ручний процес, щоб виявити, що було на платформі мейнфрейму, і переконатися в цьому. Зокрема, власне середовище бази даних та логіка SQL. Тож думка полягала в тому, що це буде досить простий хід Oracle-to-Oracle, перехід від бази даних до бази даних; вся бізнес-логіка натрапила б, більшість бізнес-логіки були написані у вбудовані запити та тригери, і наскільки це складно? Але щось, що повинно було зайняти кілька місяців, закінчилося не зовсім рік. Щоб просто фізично та вручну пройти кожну частину Unix в середовищі мейнфрейму, виявити, де були всі бази даних і скільки екземплярів запущено і що працює на цих екземплярах, і це було нетривіальною вправою, і ми закінчили це робити три рази, щоб переконатися, що ми все захопили. Тому що кожен раз, коли ми думали, що ми копали так глибоко, як нам потрібно, під поверхнею виявилося, що там більше.
Іншим завданням було те, які екземпляри працюють і в якому стані? Це середовище розвитку? Це тестове середовище? Це частина інтеграційного процесу? Це інтеграція систем? Це UAT, тестування прийняття користувача? Це виробництво? Це DR середовище? Тому що найважливіше в роботі мейнфреймів - ви можете створити ці маленькі віртуальні середовища, які ми зараз усі приймаємо як належне, і переміщувати речі. І вам доведеться попрацювати, чи ця людина займається розробкою і тестуванням виробничого класу, чи займається виробництвом, чи є в цьому реальні користувачі? Пам’ятаючи, що ця річ робить видачу водійських посвідчень та реєстрацію автомобіля в реальному часі та речі, які дійсно мають значення для життя людей.
І потрібно було довго запускати резервні копії для цієї речі, тому у нас насправді не було вікна обслуговування, щоб забрати річ в офлайн і подивитися, що сталося. Не було такого поняття, як його перепрограмувати. У нас також було завдання не просто знайти, які екземпляри запущені та де і хто для цього, але потім нам довелося розробити, які версії запущених екземплярів. І ось я майже втратив сюжет. Коли я почав розуміти, що у нас є дві-три версії виробничого середовища, які проходять різні рівні тестування, і інструментів та систематичних підходів до цього було дуже мало. Нам буквально довелося заглибитися в код і в запущений екземпляр, а в деяких випадках ризикуємо трохи зайнятись офлайн. Ми дійшли до низу всієї цієї речі, ми склали карту, і, як я вже сказав, це був дуже ручний процес. І ми нарешті здійснили всю зміну ETL, скинувши її з одного місця і перемістивши в інше і в цілому воно спрацювало. І ми були схожі, добре це функціонально, ми дуже задоволені цим.
Але потім ми зіткнулися з низкою дуже серйозних міцних цегляних стін. Зокрема, ми знайшли проблеми з продуктивністю. І розумне мислення цього дня було: ну воно перейшло до більшого, кращого, швидшого та складніше апаратного забезпечення, немає ніяких причин, чому воно мало би працювати в програмі на рівні бази даних, тому давайте почнемо шукати в іншому місці. Тож ми двічі повністю перепрофілювали мережу. Кожен маршрутизатор, кожен перемикач, кожен кабель, ми в деяких випадках переходили від Ethernet до оптоволоконних пристроїв, ми модернізували програмне забезпечення, ми латали, ви отримуєте представлення. Ми, по суті, двічі відновлювали мережу, думаючи, що це проблеми. І це виглядало і здавалося, що це було. Ми пройшли різні системи безпеки, різні брандмауери. Ми зафіксували операційну систему. Ми переміщували речі з одного обчислювального леза на інше. І ми витратили значну кількість часу на розгляд інфраструктури.
І тоді ми зрозуміли, що коли ми відключили сервери і запустили на ній інші додатки, то мережа працює просто чудово. Тож ми почали роз'єднувати операційну систему. Те саме питання. Але цікаво, що мережевий рівень та рівень операційної системи, інструменти були там, насправді нам було порівняно просто порівняння та тестування та доведення, що кожна з цих частин працювала. Але навіть тоді, на апаратній платформі Solaris середнього класу на апаратній платформі SPARC, інструментів просто не було для нас, щоб почати діагностувати середовище бази даних. Ви знаєте, картографуючи, чи ми перенесли всі екземпляри поперек. І тому нам довелося насправді створити власні інструменти, записати деякі і сісти, і чи це в рамках самих інструментів бази даних на рідних мовах сценаріїв, чи це серія скриптів оболонок або, в деяких випадках, купа програм C.
Нарешті ми поглибилися в кілька дуже цікавих питань, де логіка під шаром SQL, власне самими двигунами бази даних, виявилося, що коли щось було побудовано певним чином, щоб щось, що працювало на версії Oracle, було перенесено на Solaris на SPARC Версія Oracle не одразу перенесла ту саму продуктивність. Отже, це була для нас дуже болісна подорож, в першу чергу, просто робимо це і знаходимо все, але тепер нам довелося діагностувати це за новою виробничою системою, і знову ця річ виявила міграцію, яка коштувала місяць, майже до року. І просто зводилося до того, що у нас не було інструментів. Бігаючи, виконуючи такі дії, як спроба зіставити метадані.
У якийсь момент ми майже вирішили, що нам потрібна дошка Ouija, тому що це буде простішим способом просто навмання вказувати і смикатись. Прості речі, такі як з'ясування того, хто мав доступ до старих систем і чому вони мали такий доступ. А кому потрібен був доступ до нового і підтвердження, когось підписати та підтвердити, і це зробити карту. Навіть щось таке просте, як розмір бази даних, не відповідав двом платформам. Нам довелося створити інструмент для цього і провести порівняння між величиною бази даних в тонажі, в необроблених мегабайтах або терабайтах в системі A порівняно з системою B. І зануритися в більш детальну інформацію про продуктивність і зовнішнє середовище. Знову довелося будувати нові інструменти. Просто не було жодної позаштатної для нас.
І ви отримуєте це все повідомлення з цього, коли ми закінчували роботу, і ми стабільно працювали, кожен її фрагмент був дуже ручним процесом, єдиним способом ми могли щось автоматизувати, якщо створити новий інструмент або новий сценарій. І якби ми мали інструменти, які є сьогодні, життя було б набагато простішим і набагато кращим. І ми б заощадили мільйони на цьому проекті. Але я думаю, що сьогодні ми будемо говорити про те, що інструменти доступні зараз, і вони роблять життя набагато простішим. Багато підводних каменів все ще залишаються. Виявлення баз даних, які там знаходяться, і які екземпляри працюють. У якому стані вони перебувають. Скільки працює? Чому вони бігають. Чи добре вони працюють Чи є їх резервні копії?
Це все, що ми багато в чому можемо сприйняти як належне за допомогою правильних інструментів. Але в цьому конкретному анекдоті був період, як я вже казав, де це було щось, через що багато з нас втратили багато волосся, ми, мабуть, забрали п'ятнадцять років від свого життя, і скаржимося на те, що інструментів зараз не було. . І я з нетерпінням чекаю чути про це набагато більше від нашого гостя сьогодні, Буллетта. Тож з цим, Буллетт, я перейду до вас, і я з нетерпінням чекаю почути, як ви вирішили цю проблему.
Bullett Manale: Гаразд. Звучить прекрасно. Еріку, дозволь мені взяти сюди слайди та поговорити трохи, реально швидко, Idera, компанія, перш ніж ми перейдемо до самого продукту. Як і FYI, це певний асортимент різних товарів, які ми маємо в наявності.
Ерік Кавана: Звук настільки гарячий, тому якщо ви використовуєте гарнітуру, просто підтягніть це трохи.
Bullett Manale: Немає проблем. Це краще?
Ерік Кавана: Це набагато краще. Відняти її.
Bullett Manale: Гаразд. Тож сьогодні ми будемо зосереджуватись на Менеджері інвентаризації, який, очевидно, узгоджується з багатьма цими темами, які ми обговорюємо. Я просто хочу трохи розібратися в тому, як цей продукт потрапив там, де він є. Ми почали виглядати щодня з нашої продуктової лінійки, у нас є інструмент моніторингу продуктивності під назвою Diagnostic Manager. У нас є інструмент «Менеджер відповідності». Отже, багато різних інструментів навколо SQL Server, і ми неминуче завжди задаємо питання для ліцензійних цілей: "Яка кількість примірників, якими ви зараз керуєте в межах своєї організації?" І цікаво те, що ми ніколи не змогли дійсно отримати тверду відповідь на це. Не важливо було з ким ти спілкувався. Це завжди було на зразок: "Ну, ми думаємо, це навколо цього числа". Такі речі завжди надходили, і тоді нам доведеться пройти цей процес, щоб зрозуміти, що саме вони мали, щоб хотіти ліцензувати в частині випадків, якими ми керуємо.
Ми, очевидно, швидко зрозуміли, що, здається, є біль, пов’язаний із цим, з великою кількістю DBA. Очевидно, що як DBA одна з речей, за яку вони несуть відповідальність, - це знати, тому що одна з речей, яку вони повинні зробити, - це турбуватися про свої ліцензійні угоди, в нашому випадку з Microsoft та SQL Server. Очевидно, що у них є багато інших різних областей, за які вони відповідають, але це одна з тих, що є різновидом великого квитка з точки зору DBA, які ваші загальні обов'язки. Зважаючи на те, що ми наче прийшли до висновку, - нам потрібен інструмент, який дозволяє DBA легко зрозуміти це число. Оскільки у вас є розповсюдження SQL, якщо ви хочете назвати це так, і це відбувається з кількох різних причин. Неможливо так багато контролювати, хто встановлює програмне забезпечення та подібні речі.
І найгірше, що може статися, це те, що хтось потрапляє на копію SQL Server, встановлює її, починає працювати з нею без будь-яких знань з деякими іншими організаціями чи відділами в компанії, і тоді наступне, що ви знаєте, можливо не створюються резервні копії даних і такі речі, які можуть статися. Де зараз у вас є інша проблема, де у вас є ситуації, коли ви фактично втрачаєте критичні дані, оскільки ви не знаєте, що екземпляр навіть існує в першу чергу.
Одна з речей, яку нам довелося зробити, це сказати, давайте розберемося з фрагментом відкриття. А потім, крім того, бути в змозі організувати та керувати тією інформацією, яку ми збираємо, логічним способом, який має сенс на основі того, що робить бізнес. І тоді, очевидно, з цього зможете приймати рішення навколо цієї інформації та вміти робити такі речі. Ось звідки почався інструмент і звідки він взявся. Я можу вам сказати, що регулярно спілкуючись з DBA, це насправді полягає в тому, що ми не знаємо, скільки примірників у них є.
І це смішно, оскільки, термін, ти не можеш керувати тим, що ти не можеш виміряти, завжди придумував інструменти продуктивності, які ми маємо, як SQL Diagnostic Manager, але ти справді нічого не можеш керувати, якщо ти цього не знаєш «Це» навіть там, в першу чергу. Так що це велика частина цього інструменту також, здатна просто знати, що він є.
Тепер на цій замітці, розмовляючи з деякими більшими організаціями чи підприємствами магазинів із SQL Server, цікава річ, яку ми знайшли з багатьма хлопцями, з якими ми спілкувалися, - це те, що вони насправді встановили час протягом року, де вони насправді фізично ходили з одного місця в інше, щоб спробувати визначити, як виглядає цей підрахунок. Ви можете уявити, як DBA вам платять досить непогану суму грошей, щоб фізично ходити з однієї машини на іншу в деяких випадках, що було дивно, що ми почуємо від деяких досить великих компаній, яких я не назву. Але цікавий момент, що два тижні на рік можуть бути витрачені на виконання подібних вправ, аби тільки з'ясувати, чи правильні їхні кількості ліцензій.
Це все пов’язано з цим інструментом і як він допомагає, окрім як ми вирішили це через здатність робити відкриття на основі ряду характеристик SQL Server. І тому перше запитання - на що ви вказуєте або на що ви намагаєтесь подивитися спочатку? Як ми це зробили, це було сказати, зробимо це за IP-діапазоном, або ми можемо це зробити за допомогою членства в самому домені з точки зору комп'ютерів, які є членами домену. Ось так ми і звернулися до цієї частини, просто щоб можна було сказати, що це сфера, на яку ми хочемо зосередитись з точки зору відкриття.
І тоді інша частина цього ґрунтується на цих характеристиках, портах та інших речах, ключах реєстру WMI та подібних речах, ми можемо зібрати та встановити, що SQL, ймовірно, працює та встановлений у цьому екземплярі чи в цьому конкретному середовищі. Це, очевидно, набагато кращий метод, ніж метод кросівок або метод експрес-кросівок. Тепер найзручнішим є те, що вся ця інформація, яку ми збираємо про екземпляр, зберігається у сховищі, і вона може змінюватися у міру зміни середовища. Справа не лише в тому, що "Ей, є примірник, ось список, який ми знайшли", але це як DBA або особа, яка керує екземплярами, здатна визначити, чи хочуть вони зробити цю частину інвентаря, а потім коли це не частина інвентаризації, щоб мати змогу вивести з експлуатації цей екземпляр. Таким чином, у них є життєвий цикл всього процесу екземпляра SQL Server, який можна легко зрозуміти в цьому інструменті.
Як тільки ми виявили екземпляри, що робити після цього? Інша справа - це багато інформації про екземпляр, я не хочу вручну отримувати її і поміщати в електронну таблицю або подібні речі. І це ще одна цікава річ, розмовляючи з DBA про процес інвентаризації та ліцензування, це те, що ви будете здивовані тим, скільки DBA-учасників я говорив, коли ви запитуєте їх: "Як ви підтримуєте свої запаси?" ми говоримо з DBA, що є дійсно іронічною частиною цього, що вони зберігають це і відстежують це в статичній таблиці всіх речей. Як я вже сказав, дуже іронічно, коли ти думаєш про це хвилину. Але це було у багатьох випадках, і все ж таки це стосується багатьох організацій, як їм це вдається. Як вони це зберігають. Це головна копія електронної таблиці Excel, яка плаває навколо, і її потрібно регулярно оновлювати.
Це те, що було викликом, і тому, зареєструвавши цей примірник і зробивши його частиною інвентарю, ви можете це зробити і забрати інформацію. Ви можете його автоматизувати, чи не стає він частиною інвентарю, версія, видання, інші речі, які ви можете зробити з ним, ви можете вручну додати, можливо, той список або таблицю Excel, які у вас є. Ви можете імпортувати це в цей інструмент, який називається SQL Inventory Manager. Якщо у вас уже є початкова точка, коли ви вважаєте, що ви впевнені, ви можете імпортувати ці екземпляри, а потім зробити цю частину свого керованого інвентарю в продукті. Як тільки ми маємо примірник, і як тільки ми дізнаємося, що він є, то це стає добре, ми маємо багато інформації, яку ми можемо використовувати, знаючи, що цей екземпляр є, виходячи і збираючи цю інформацію.
І багато інформації буде потрібно для більше, ніж просто ліцензійних цілей. Багато з цього можна використати для того, щоб, очевидно, просто знати, де знаходяться речі, мати можливість шукати цю інформацію після її отримання. Але ключовим матеріалом є сервер, саме обладнання. Будучи здатним зрозуміти, що це за машина, можливо, модель чи виробник, пам'ять, обсяг пам’яті, будь то фізична чи віртуальна машина, і особливо кількість фізичних сокетів або ядер і процесорів, і такі речі.
Що стосується кількості ядер, особливо для SQL Server, то, як знати, як вони роблять своє ліцензування, - це основні розрахунки тепер у нових версіях SQL, що стає дійсно важливою його частиною, і це не все, що у вас є вийти і насправді піти копати. Після виявлення екземпляра ми можемо надати цю інформацію та витягнути її, а також дозволити вам її переглянути та зрозуміти, і, очевидно, можемо нею скористатися.
Наступний рівень внизу - це той екземпляр, який, очевидно, має багато різних екземплярів SQL Server, будь то стандартний, корпоративний або навіть експрес з цього питання, або безкоштовна версія SQL Server. Бути в змозі зрозуміти також, які програми прив’язані до цього примірника, і це можна зробити автоматично. Здатність зрозуміти параметри конфігурації та подібні речі, а також іншу інформацію, яка стосується екземпляра самого SQL Server.
Потім ви переходите до фактичної бази даних і бачите параметри конфігурації, кількість місця, прив’язаного до цих даних, де вони знаходяться, весь цей матеріал автоматично заповнюється, і тому це величезна економія часу. І ще раз, оскільки це динамічно виходить і щодня визначає нові екземпляри, це живе, що ви маєте з точки зору свого інвентарю. Ось така мета продукту - зробити це таким чином, це зробити його чимось, що динамічно змінюється.
Тепер, коли вся ця інформація стає нам доступною, і ми зможемо перетягнути всі ці дані, тоді справді має сенс почати створювати в деяких випадках власні метадані, пов’язані з цими екземплярами, і ці метадані можна створювати таким чином, як вирівнюється до того, як ви ведете свій бізнес.
Отже, якщо у вас є примірники, згруповані за географічним місцеположенням, або за власниками додатків, або за власниками DBA або будь-яким іншим, це може бути з точки зору того, як ви хочете згрупувати ці екземпляри, як ви логічно хочете зрозуміти ці екземпляри, тоді є добрий з двох областей інструменту, які дадуть вам таку можливість.
Перший - це можливість створити тег примірника або тегу. Що по суті створює зв'язок із сервером, екземпляром або базою даних, щоб ви могли створювати перегляди та відповідати на питання, які можуть виникати щодня, що справді допомагає вам зрозуміти, що ви маєте, чим ви керуєте і як ви хочете рухатись вперед за допомогою цієї інформації.
Інша річ, яку ми маємо, - це щось, що називається полями інвентаризації або спеціальними полями інвентаризації, і вони більш специфічні для виду деталей інформації, до яких ви можете ознайомитись, наприклад, рівень бази даних, який я міг би вирішити додати розкривний список, у якому є всі DBA, і я можу поставити, хто несе відповідальність за цю базу даних, залежно від типу ситуації чи будь-якої іншої бази, яка б база даних не була, хто несе відповідальність за це, зможе вибрати це, щоб я знав, що вони несуть відповідальність і дуже легко, просто занурившись в інвентар.
Таким чином, ці відомості стають дуже цінними, особливо якщо у вас є велике середовище, оскільки це просто допомагає вам осмислити цю інформацію і знати, що у вас є, і як ви це робите.
Тож дозвольте мені перейти до наступного слайду тут. Що я вам зараз показую, це те, що вся ця інформація, яку ми збираємо, вся ця інформація та дані, які ми збираємо та застосовуємо метадані, щоб ви могли потім приймати набагато простіші та швидші рішення, коли справа стосується підготуйте свої ліцензії у Microsoft на корпоративне ліцензування обсягу чи страхування програмного забезпечення у Microsoft
Це робить вас дійсно легким для цього, а не для того, щоб робити, робити багато ручного збору даних, багато вручну збирати ту інформацію, яка насправді просто загалом робить її набагато кращою для процесу. Отож, це наче один із мандатів продукту, коли-небудь полегшуючи ОПР приймати ці рішення навколо ліцензування.
Тепер інша річ, яку ми, розмовляючи з DBA, виявили та дізналися дуже швидко, це те, що - це щось на кшталт повернення до того, про що йшлося раніше - у вашому оточенні SQL Server може бути 300 екземплярів, але насправді може бути лише підмножина з тих, що реально повністю контролюються та керуються за допомогою традиційного інструменту моніторингу продуктивності.
Отже, якщо ви йдете, і ви фактично сідаєте з DBA, і ви говорите: "Подивіться, ми знаємо, що у вас є ці 20 екземплярів або 10 екземплярів із 300, які контролюються цим інструментом, призначеним для моніторингу цього та відповідності вашим SOA та отримувати сповіщення та всі подібні добрі речі ", що ми також виявили, що якщо ви запитали:" Тоді, що робити з цими іншими 280 випадками, які у вас є? Вам це байдуже? "І вони роблять, вони дбають про них, але вони просто не хочуть обов'язково робити інвестиції для моніторингу тих, хто на рівні глибини, який можна зробити з цими екземплярами порівняно з тими 10 або 20 справді, дійсно критичні екземпляри продукту.
Отже, інша частина рівняння з цим інструментом полягає в тому, що він також допомагає з точки зору можливості переконатися, що на базовому рівні ви охоплені з точки зору здоров’я, наприклад. Тепер вам не збирається розповідати, чи є у вас тупик чи хто є жертвою тупику. Справа не в тому, щоб досягти такого рівня самих сесій та деталей запитів. Але в той же час все одно ви будете повідомляти про це, якщо сервер зменшується, або, якщо гучність заповнюється, або вам потрібно зробити резервні копії бази даних, це важлива частина DBA.
Тож такі речі, безумовно, все ще важливі, і тому з цим інструментом ви зробили так, щоб у вас є вигадка для ваших дійсно критичних екземплярів, які мають багато, багато чого варте, якщо вони йдуть вниз вам потрібно знати це відразу. Вони можуть мати вищий рівень моніторингу та можливість робити такі речі, тоді як завдяки цьому вони зможуть підібрати будь-які нові екземпляри, які додаються до навколишнього середовища, і переконатися, що вони враховуються, а також роблять впевнені, що ці базові рівні перевірок здоров'я формуються.
Отож, у двох словах, у чому полягає диспетчер імпорту SQL Imventory. Зараз я покажу вам демонстрацію цього. Перш ніж ми це зробимо, просто швидко я вам покажу, що це слайд архітектури тут, і просто щоб це показати, екземпляри SQL, якими ми керуємо, ми можемо виявити все, починаючи від SQL 2000, аж до нового версії SQL.
Тож ми можемо це зробити, не маючи необхідності розгортати агенти до самих інстанцій. Ми робимо це через службу збору, і ми збираємося збирати цю інформацію та зберігати її у сховищі, а потім із передньої консолі веб-служби Tomcat ми зможемо потім взаємодіяти з цими даними та переглядати її. Тож це досить просто архітектура.
Я йду вперед, перемикаюся і насправді переймає нас самим продуктом, щоб ви могли відчути його, зрозуміти, як він працює. Тож найкращий спосіб зробити це - спочатку познайомити вас із самим інтерфейсом. Це така собі інформаційна панель, яку ми дивимося тут.
Я бачу, що кількість примірників зараз, що я маю під управлінням, не дуже велика. Але я також не маю цілого центру обробки даних у задній кишені. Отже, у мене є десь шість випадків, які ми бачимо тут. Тепер, коли це було сказано, я збираюся пройти процес відкриття і показати, як це буде працювати.
Тепер перше, що ви зробите, це в розділі адміністрації, ви можете вказати, як ви хочете виявити ваші примірники. Ви зможете вкласти цю інформацію сюди і ще раз, що можна зробити за допомогою ряду IP-адрес. Ви можете вказувати на домен чи субдомен і мати змогу лише на тих машинах, які є членами цього домену, змогли виконати ті перевірки, на які ви зможете вибрати ряд різних видів характеристик, коли SQL працює для перевірки.
Потім, як тільки ви це зробите, ви зможете автоматизувати щоденно, щоб збирати і збирати ці дані. Ви також зможете це зробити на спеціальній основі за потреби. Але як тільки ви почнете це, цей процес виявлення, то те, що ви почнете бачити, - це коли перейдете до перегляду екземплярів тут. У вас є вкладка «Відкрити», а вкладка «Відкрити» буде показувати нам ті випадки, які були нещодавно виявлені. Тож у нашому випадку тут є номер. Те, що я збираюся йти вперед, - це йти вперед і додати той, який ми будемо використовувати в якості прикладу. Так це в цьому випадку є чиказький екземпляр, правда? Я збираюся йти вперед і додати цей екземпляр до мого інвентаря.
Добре, і тут я пройде через кілька речей. Я просто йду вперед, і ви побачите, що ми можемо встановити облікові дані. Мої повноваження мають бути хорошими. Я йду вперед, і ви помітите, що я можу призначити право власності на це, якщо хочу. Я також можу вказати місцеположення. Тепер може бути додано і саму локацію, і це буде пам'ятати, що наступного разу, очевидно.
Ще раз я можу пов’язати теги з цим з точки зору метаданих та того, як ми хотіли б помістити ці екземпляри SQL, зокрема цей, у ті відрізки, у які ми хочемо його вкласти. Отже, у нас є кілька поточних тегів, популярних тегів, тож ми можемо переглянути купу різних тегів, які я, можливо, вже включив. Я просто збираюся вибрати щось із них навмання, і ми можемо застосувати це.
Тож тепер, коли я продовжую і додаю це до інвентарю. Тепер, коли це було додано, ми бачимо, що він відображається під цим керованим поданням, і ви можете бачити його в списку прямо тут. Отже, ви знаєте, що це перший крок, і те, що я щойно я показав вам, - це спосіб, яким ви в основному додаватимете ці екземпляри, проходячи щодня. У деяких випадках ви можете сказати, що знаєте, що якщо це корпоративне видання SQL-сервера, я автоматично хочу додати це до свого інвентаря? Мені не потрібно вручну йти і вирішувати це робити.
Джоселін: Я збираюся вас швидше перервати. Ми не бачимо вашу демонстрацію.
Буллет Манале: Ти не?
Джоселін: Ні.
Буллет Манале: Ну це не добре, давайте подивимось.
Ерік Кавана: Якщо ви переходите до верхнього лівого кута, натисніть кнопку "Пуск", натисніть на це.
Буллет Манале: Ага, добре.
Ерік Кавана: А тепер зробіть загальний екран.
Буллет Манале: Вибачте за це. Так.
Ерік Кавана: Це добре. Гарний вилов там, продюсер Джоселін.
Bullett Manale: Гаразд, так це краще? Ви бачите це зараз?
Робін Блор: Так.
Bullett Manale: Гаразд, так що давайте просто пройдемо вас там, де ми були реально швидко. У нас виявлені випадки, які у нас були раніше. Я тільки що додав екземпляр Чикаго, і те, що ви бачите зараз, це тепер перераховано тут. Зауважте, це вже витягнуло багато додаткової інформації. Якщо я натискаю сам екземпляр, ви почнете бачити всі види інформації, які ми вже зібрали про цей екземпляр. Тепер ось перелік усіх баз даних, які там є. Ми можемо побачити розподіл баз даних за розміром та за активністю, з точки зору того, які з них мають найбільший розмір та активність.
Ще раз, ми також можемо вам сказати, що ми бачимо, які програми ми бачимо запущеними в цьому екземплярі, виходячи з завантаженості, яку ми бачимо, що працює на екземплярі. Тож приємно мати можливість робити це автоматично. Мені не потрібно заходити і пов'язувати заявку на випадковість. На основі того, що ми бачимо, ми можемо це заповнити. Тепер, якщо ви хочете вручну додати програму, ви абсолютно можете це зробити. Але це лише приємний спосіб виявити асоціацію примірника до бази даних або, вибачте, до програми.
Ви також помітите, що в правій частині екрана миттєвий підсумок, а внизу - підсумок сервера. Таким чином, ми говоримо про ключові фрагменти інформації тут, знаючи версію, а не просто, знаєте, SQL Server 2012, але фактичний номер версії, який, в тому числі і повідомляє нам, які виправлення пов'язані з ним, які пакети послуг прив’язані до нього, це може бути дуже важливо знати. Очевидно, що вимога пам'яті важлива. Все подібне, будь то кластеризована, вся ця інформація, мені не потрібно її вносити - вона вже збирається і збирається, і як тільки ми виявимо, що це виявлений екземпляр, це буде частиною нашого інвентаря.
Інша річ, яку ви побачите тут - і це вам покаже - це під цим видом примірника. У нас є ці атрибути, про які я говорив раніше, спеціальні атрибути, які можна додати. Таким чином, ми можемо додати відкриті види полів текстового поля, ми можемо зробити так / ні з точки зору, ви знаєте, мільярдів видів. Ми навіть можемо робити спадні списки. Це можна зробити в екземплярі бази даних або на рівні сервера.
Потім, якщо прокрутити трохи далі, ми зможемо побачити всю пов'язану інформацію на самому сервері. Отже, ви знаєте, що всі подібні речі, очевидно, справді, дуже корисні, тому що всі вони зібрані і зібрані, і це для нас, як тільки ми приймемо це рішення, щоб зробити його частиною нашої інвентаризації. Тут ми можемо показати деякі відмінності щодо процесора, кількості логічних та фізичних, скільки пам’яті. Таким чином, ви дійсно отримуєте дійсно добру та багату інформацію, не потребуючи багато роботи.
Тепер інша частина цього, як я вже сказав, ми збираємо ці дані на рівні сервера. Якщо ми навіть перейдемо до бази даних, ми можемо побачити, що багато цього матеріалу розбито і на нас. Тож якщо я перейду до свого сховища відповідності, то в цьому випадку я можу сказати: добре ви знаєте, що це стосується системи, це база даних відповідності, у якій рівень відповідності чи вимоги регулятора пов'язаний, і це може бути, скажімо, Відповідність SOX або PCI. Тож я можу вибрати, у яких базах даних є відповідність їм відповідності, яку я повинен заповнити, або переконатись, що я підтримую з точки зору цієї нормативної вимоги.
Таким чином, цей матеріал виявився дуже корисним для DBA, оскільки там є місце, куди вони можуть зайняти центральне місце, щоб легко зберігати всі ці пов'язані метадані у своєму оточенні, і вони можуть зробити так, як я вже сказав, відповідно до їхнього бізнесу, оскільки вони ' робиш, як спосіб ведення бізнесу. Отже, якщо ми подивимось на всі речі поки що, що ми побачили, у вас, очевидно, є досить хороший огляд екземпляра, якщо я розглядаю його.
Я також можу здійснити пошук, тому я сказав, що давайте шукатимемо це сховище відповідності для мого інвентаря. Тоді, що ви побачите тут, - це те, що я можу шукати ці речі та вміти їх ідентифікувати. Я говорю це - я не впевнений у чому, моя кнопка переходу не працює. Добре. Подивимось, спробуємо ще раз. Там ми йдемо. Тож ми змогли б побачити розбиття того, де ми бачимо що-небудь, у чому ми дотримуємось, і я можу розібратися в цьому і побачити це також з цієї точки зору. Таким чином, у вас є дійсно швидкий і простий спосіб вникнути ці дані.
Як ми вже згадували раніше, у вас є маса різних способів створення метаданих проти сервера та бази даних екземплярів. Інша частина цього - це можливість скористатися цим способом у тому, як ви згрупували його, і тим, як ви пов’язані з ним. Ми переходимо до виду дослідника, ми можемо зробити саме це. Можна сказати, що я хочу зробити кількість баз даних за локаціями. Отже, кількість баз даних у кожному розташуванні середовищ, які я підтримую. Або, можливо, це базується на власнику, який володіє екземплярами, які я маю там, з точки зору, можливо, кількості примірників. Тож ми зможемо це побачити. Таким чином, ви отримаєте дійсно хороший, простий спосіб нафарбувати ці картинки для вас, грунтуючись на будь-якому питанні, на яке ви намагаєтесь відповісти.
Тоді те, що у вас є, що така інформація створена так, як ви хотіли, ми можемо експортувати її у PDF або різні формати, щоб мати змогу використовувати її та надсилати нашим колегам або робити все, що нам потрібно там. Отже, ви знаєте, що зможете робити такі речі. Повернемось до - я це втратив? Там ми йдемо. Так добре, сподіваюся, це має сенс з точки зору того, про що я говорив до цього часу. Тепер, коли ми зібрали дані, все це, очевидно, дійсно життєво важливо з ряду причин - ліцензування та багато чого іншого.
Останнє, що потрібно згадати, - ми переходимо до цього розділу адміністрації. Тут ви також можете налаштувати свою електронну пошту та сповіщення та мати можливість переконатися, що для речей, про які ви хочете насправді знати, ви також можете налаштувати ці речі. Таким чином, ми можемо налаштувати сповіщення електронною поштою, ми можемо налаштувати можливість вмикати певні речі та вимикати певні речі, а потім зможемо визначити, хто отримуватиме ці електронні листи, і підписавшись на ці сповіщення, ми можемо пов’язати, кого б ми хотіли бути, хто хотів би знати про такі речі.
Але, як я вже говорив раніше, це дійсно приємний спосіб зробити, принаймні мати загальний спокій, щоб знати про всі ваші екземпляри SQL підприємства - що це у вас є, а також переконайтесь, що він працює оптимально, навіть якщо ви цього не робите ' t, не прийняли рішення інвестувати у важкий інструмент моніторингу ефективності для управління цим екземпляром. Це охопить вас, тому що це дуже доступний спосіб виходу на вулицю, і для багатьох випадків можна робити ці запаси та мати можливість робити дуже широкий загальний рівень моніторингу, щоб переконатися, що ви отримав цей спокій і дізнайся, що відбувається.
Тож сподіваємось, що це має сенс у тому, як ми це описали та показали вам. Я думаю, що з цієї точки зору я можу йти вперед і повернути його назад, і ми можемо поговорити ще трохи.
Ерік Кавана: Це звучить чудово. Так Робін? Дез? Які-небудь питання?
Робін Блор: Ну, у мене є питання. Насправді це дуже цікаво, я маю на увазі, що я просто хотів прокоментувати, що я майже всюди, де я був, не просто серед DBA, а серед хлопців у мережі, серед хлопців із сховища, серед хлопців із віртуального управління машиною, вони ' повторно всі відпрацювання електронних таблиць.
Ерік Кавана: Так.
Дез Бланчфілд: Ви начебто знаєте, що це, ви начебто знаєте, що це нормально, поки цифри не почнуть рухатися. Коли цифри починають рухатися, ви знаєте, що вони зіткнуться з проблемою. Тож питання мене зараз якось цікавить, і я знаю, що вам буде складно відповісти, але що, якщо ви заходите в місце, де у них нічого подібного немає для роботи електронних таблиць, тож припустимо DBA - дуже розумні хлопці, і так далі, і таке інше, яку рентабельність інвестицій ви думаєте, що отримаєте, реалізуючи щось подібне? Чи є у вас якісь дані щодо цього чи будь-які вказівки щодо цього?
Bullett Manale: Важко сказати, що таке рентабельність інвестицій, оскільки оточення буде дещо іншим. Очевидно, що чим більше підприємство, тим більшим є середовище, очевидно, тим більше буде рентабельність інвестицій, якщо вони зараз використовують, знаєте, ручні методи.
Я знаю, що я говорив з низкою - коли я кажу про великі організації з тисячами і тисячами співробітників, а також, мабуть, і з тисячами випадків, - де я маю людей, де я їм це показую, і вони кажуть, що це займе два тижні мого часу назад. Я говорив про це не раз. Тому важко сказати з точки зору фактичної суми долара від покупки, але це досить, коли у вас є умови.
Як я вже казав, це досить послідовно, це люди, з якими я, більшість людей, з якими я розмовляю, зберігають ці матеріали в електронній таблиці. Так що це просто дуже, дуже суб'єктивна річ, тому що в кожному середовищі це трохи відрізняється з точки зору того, як вони роблять своє ліцензування та як вони роблять своє ліцензування з Microsoft, це ще одна частина цього фактора. Але якщо їм доводиться робити справжні бажання щороку або кожні три роки, я думаю, що три роки, як максимум, для Microsoft, що вони будуть, вони хочуть, щоб ви справджувались принаймні кожні три роки.
Тоді ви знаєте його значне і це, ви знаєте, що це просто щось, що робить набагато простіше. Оскільки це динамічна річ, яка завжди змінюється, вона дає трохи більше достовірності і з точки зору того, що це ви дивитесь на вірші, добре, що ми не оновлювали електронну таблицю за півроку чи рік. Тож як часто ви оновлюєте електронну таблицю - це ще одне питання, щоб зрозуміти, що це відповідь на рентабельність інвестицій.
Дез Бланчфілд: Так, я маю на увазі ліцензування SQL, ліцензування цього - це просто проклятий кошмар, але це особливо кошмар, оскільки ліцензування не однакове між Microsoft та Oracle та будь-ким іншим, хто там робить речі з базами даних. Якщо ви фактично зберігаєте речі в електронних таблицях, які, як правило, відбуваються, ви знаєте, що час ліцензування настає до того, як ви насправді це усвідомлюєте, і у вас фактично немає даних, якщо ви знаєте, що я маю на увазі, щоб легко отримати та інформація.
У будь-якому випадку, як ви зазначаєте, це динамічно, і я особисто не маю уявлення, тому що мені ніколи насправді не довелося домовлятися з Microsoft, тому я не маю уявлення, але, мабуть, є бази даних, які люди досить часто знімають дані тестів, тестуючи навколишнього середовища, і я б здогадався, що це шип у вашому боці, якщо ви робите ліцензування. Це ти-?
Буллет Манале: Так, так. Це так, тому що багато разів про цей матеріал забувають, і тоді ми починаємо намагатися розібратися, добре, добре, у нас є основне ліцензування, що ми повинні з'ясувати кількість ядер для кожного з цих випадків, і я не Не знаю, з точки зору стандартів того, що ти купуєш апаратним шляхом, ви також можете придбати досить гарне обладнання, якщо ви не використовуєте це обладнання так, як воно повинно бути використане, то ви переплачуєте, тому що ви платити за основні ціни, коли ці ядра не використовуються, тому це стає проблемою.
Отже, кожна версія SQL має інший спосіб застосування ліцензій, що навіть робить її трохи заплутаною. Тож у вас виникають деякі проблеми навколо цього, і тому це велика частина того, чому ця інформація є дуже корисною, оскільки ми можемо сказати вам, в якій версії вона є, ми можемо сказати вам, очевидно, кількість ядер у вас, якщо це старіші версії SQL це було ціноутворення на одну розетку, ми все ще можемо показати це, очевидно. Так що це просто, це робить набагато простішим рутина, яку вам доведеться пройти, коли настає час, щоб виправдати ці речі.
Дез Бланчфілд: Одне, що мені спадає на думку, про жаль
Робін Блор: Добре, ви їдете в Дез, я збирався задати, можливо, невідповідне питання.
Дез Бланшфілд: Просто щось дуже швидко, поки ви переглядаєте тему, яку ви зараз перебуваєте - ми бачимо набагато більше прийняття хмарних середовищ, і якщо ми запускаємо це все в нашому власному центрі обробки даних, в нашому власному середовищі, вони повзають і знаходять, виявляючи речі відносно просто.
Як нам, як ми впораємося зі сценарієм, коли у нас може бути три набори даних, дві хмари, а видимість у цих середовищах розгортається, і часто є кінець даних у кінці труби або VPN. Чи є можливість виявити з переднього кінця чи нам потрібно, щоб почати відкривати порти, щоб ми могли сканувати певні середовища між різновидом хмари та поза приміщеннями, де працює ця платформа?
Bullett Manale: Так, було б певне врахування з точки зору портів. Так що, на жаль, я б хотів сказати, що він прорветься через усі ці середовища, але є кілька різних варіантів, які ви могли б зробити з цим. Очевидно, що якщо ви робите щось на кшталт Amazon EC2, все, що вам дійсно знадобиться, - це доступ до цього середовища через ваше з'єднання, якщо припустити, що ваші порти відкриті, а потім зможете вказати ваші IP-адреси або ваш домен, пов'язаний з цим, і він може запуститися колекцію та почати відкриття.
Отже, це в таких типах середовищ, що насправді не є проблемою; це більш конкретні типи середовищ, такі як RDS, і там, де ви просто отримуєте саму базу даних, де буде трохи складніше бачити та виявляти такий тип інформації.
Дез Бланшфілд: Отже, випливаючи з того, що там було, є бази даних та бази даних. Так, наприклад, старі добрі часи, що мають дуже-дуже великий двигун бази даних, як анекдот, яким я поділився на фронті, де це лише одна масивна платформа, і все, що вона робить, - це надання бази даних. У наші дні бази даних вбудовані у все, адже насправді у моєму телефоні за програмами працює два-три.
Які проблеми ви стикаєтесь із сценаріями, де у вас є середовища Lotus Notes, а додатки за ними, SharePoint з базою даних в різних інтернетах тощо? По суті, все працює на базі даних на зворотному кінці. Які речі ви бачите там і з якими труднощами ви стикаєтеся, що люди просто намагаються скласти карту таких типів світів і що ваш інструмент робить для них?
Bullett Manale: Ну я маю на увазі, що справа в тому, що те, що ви сказали - зараз потрібна база даних, тому багато разів, можливо, дуже багато, є багато баз даних, які вводяться в середовище, що самі DBA навіть не усвідомлюють це, оскільки встановити SQL-сервер, встановлений у середовищі, не дуже важко, взагалі кажучи.
Цей інструмент також визначає такі речі, як експрес-бази даних, тому безкоштовні версії SQL Server. Досить смішно, коли ви знову розмовляєте з DBA, ви не отримаєте послідовної відповіді з точки зору того, чи вони піклуються про безкоштовні бази даних, які там знаходяться. Багато цих програм, про які ви говорите, використовуватимуть безкоштовну версію бази даних. Але самі організації будуть по-різному ставитися до того, хто відповідає за цю базу даних, залежно від того, з ким ви спілкуєтесь.
Деякі DBA, з якими я розмовляю, я можу подумати про те, коли я останній раз, коли я був у SQL Server PASS, що в Сіетлі, ви задавали питання «Чи не піклуєтесь ви про свої експрес-бази?», І це було близько п’ятдесяти п'ятдесяти. Деякі з людей хотіли знати про них як про DBA, оскільки вони відчували, що вони є частиною своїх обов'язків, навіть ті висловлені бази даних, які все ще можуть містити критичну інформацію; їм все одно потрібно пройти процедуру резервного копіювання та все ще потрібно переконатися, що всі справи працюють з точки зору здоров'я на них. Але просто знати, що вони існують, так само важливо, якщо не важливіше.
Тоді як друга половина людей: "Гей, ми не несемо відповідальності за ці бази даних, і все, що вони розміщують на них, опікується людиною, яка їх встановила". Але я б сказав, що загалом те, що ти сказала, що сьогодні майже все є прив'язаним до нього додатком, який лише сприяє більшій складності та плутанині щодо необхідності інвентаризації цієї інформації.
Дез Бланчфілд: Так, я бачив деякі, урядові сайти, мабуть, є моїм улюбленим, але частіше за все я зараз бачу в корпоративних середовищах, де це, як ви сказали, що люди навіть забувають, коли вони встановлюють щось на зразок SharePoint або як самообмін, так що ви знаєте, що вони постачаються з безкоштовно вбудованою версією, тому що вони хочуть, знаєте, встановити її швидко і не турбуватися про необхідність їхати та купувати ліцензії.
Потім він стає великим, і тоді хтось починає скаржитися на продуктивність, і вони виглядають так: "Це просто ваш старий сервер, ваш накопичувач, ваша мережа, що завгодно", і тоді DBA називається, і вони на кшталт "Ну, ти" я просто забила все у цій безкоштовній версії бази даних, а це не те, що вам потрібно для цього великого ».
Зокрема, коли у вас є такі сценарії, як Project Manager та Office, працює сотні, якщо не тисячі проектів на великому підприємстві або в корпорації, і вони використовують SharePoint з Microsoft Project Server, і вони скидають усі свої матеріали PMO в цю базу даних. Але на передньому кінці вони схожі, ну це просто веб-інтерфейс. Але насправді є бази даних та бази даних.
Буллет Манале: Так.
Дез Бланчфілд: Отже, що це таке, один із перших кроків, які люди тут, я думаю, є кілька питань, які ми могли б захотіти запропонувати від аудиторії. Одне з перших питань - де люди починають? Який перший природний крок для них зробити: "Гаразд, нам потрібно зробити анонімну версію алкоголіків?"
У нас більше баз даних, ніж ми знаємо, що робити. Що це за природний вид схожих на них кроків: «Гаразд, нам потрібно зайняти цю справу і почати бігати?» Чи просто вони холодною індичкою або пізніше їм дійсно потрібно почати з малого і просто отримати досвід з картографування свого оточення ?
Bullett Manale: Ну, я думаю, що вони сказали, що вони повинні скласти карту навколишнього середовища. Тепер Microsoft пропонує безкоштовний інструмент для цього, інструмент планування оцінки Microsoft, це безкоштовний інструмент, але він є статичним. Ви робите відкриття і все. Ви отримуєте список речей, які там знаходяться. Ми взяли це і сказали, подивимось, зробимо крок далі, давайте зробимо відкриття, давайте знайдемо, що там, і давайте помістимо його в сховище, і давайте зробимо так, щоб воно було динамічним, і ми зможемо додати його, видалити з нього.
Але загалом найбільший перший крок - я думаю, просто щоб з'ясувати, зробити відкриття. Чи означає це завантаження нашого продукту пробним шляхом, ви можете завантажити його та випробувати його протягом 14 днів, а також ви можете вказати на своє оточення та зробити колекцію.
Тепер, якщо у вас вже є електронна таблиця з купою цієї інформації, що ви дещо впевнені, що ця інформація є правильною, ви також маєте можливість сподобатися імпорту в CSV, який використовує всю електронну таблицю, та всю частину того, що ви вже є. Але з точки зору з'ясування того, чого ви не знаєте, єдиний спосіб зробити це - вручну вийти, зробити це чи мати інструмент, який шукає такий тип речей, як цей. Це рішення, яке вам доведеться в якийсь момент приймати, це таке: "Чи намагаюся я автоматизувати це відкриття або принаймні отримати хорошу основу того, що там спочатку, а потім, можливо, переживаю за деякі винятки?" здебільшого вам, мабуть, потрібен інструмент.
Дез Бланшфілд: Так просто швидко. Куди люди йдуть, щоб розпочати це? Вони потрапили на ваш веб-сайт? Як вони зв’язуються і швидко розпочинають це?
Bullett Manale: Якщо ви перейдете до Idera, IDERA.com, ви побачите, і я насправді просто реально швидко покажу це реально швидко. На веб-сайті Idera ви перейдете до продуктів, перейдіть до менеджера з інвентаризації. Ви побачите, що тут є посилання для завантаження. Ви просто визначаєте, яку саме збірку ви хочете встановити на 64 або 32 біт, і це підніме вас, і ви можете розпочати своє відкриття звідти.
Робін Блор: Фантастична і чудова, чудова презентація, дуже дякую.
Bullett Manale: Дякую.
Ерік Кавана: У нас є кілька запитань від аудиторії, і ми надішлемо їх електронною поштою, тому що сьогодні нам важко зупинити себе, але Буллет, знову ж таки, чудова робота на демонстрації, чудова робота нашого продюсера, зрозумівши, що це не було ' t показ.
Буллет Манале: Вибачте за це.
Ерік Кавана: Ні, це хороші речі, ви бачите видимість в основі бізнесу, правда? Оскільки бізнес працює з даними, і ви надаєте видимість прямо до основи. Тож більше немає ручних хвилястих речей; тепер ви можете фактично вказувати на речі і вирішувати це. Так добре для вас.
Bullett Manale: Дякую.
Робін Блор: Але було чудово побачити, що це теж до речі, молодці.
Ерік Кавана: Так, ми будемо архівувати цю веб-трансляцію для подальшого перегляду, і тоді ми будемо сподіватися, що це буде через годину-дві, початковий архів підніметься, іноді це трохи довше, але ми обов'язково дозволимо людям знати. З цим ми вас відпустимо, люди. Ще раз дякую за відвідування інструктажу, ми фактично є гарячими технологіями. Ми наздоженемо вас наступного разу. Обережно, до побачення.
