Найповніша інформація про те, що таке цод при обробці персональних даних та його основні функції. Як побудувати власний цод Запорука успішності ЦОД - це грамотне проектування

В основному наводиться інформація щодо вже реалізованих проектів ЦОД, або за передовими технологіями, що застосовуються при його створенні. Чомусь питання про обґрунтування вибору ЦОД, питання грамотного складання ТЗ на нього, а також питання про ефективне використання всіх можливостей закладених у ЦОД виявляється втраченими. У міру своїх сил та можливостей постараюся висвітлити докладніше ці питання.

Область застосування документа та перелік питань, що розглядаються

Цей документ призначений для отримання комплексу необхідної інформації для фахівців, які займаються створенням та експлуатацією ЦОД, серверних та машинних залів.

У документі розглядаються:

• Проблеми, що з'являються на етапах проектування, будівництва та експлуатації ЦОД, а також можливі вирішення цих проблем
• Наводяться рекомендації щодо використання сучасних стандартів, а також дається коротка їх характеристика
• Наводяться основні помилки при проектуванні, і проблеми, що з'являються при експлуатації, показуються їх наслідки, а також можливі шляхи усунення помилок та вирішення проблем.
• Окремо наводяться правила створення успішних IT-проектів
• Розкриваються найважливіші вимоги до основних елементів ЦОД, і, по можливості, пояснюється причина цих вимог та наслідки їх недотримання
• Перераховуються основні тенденції у створенні ЦОД та деякі статистичні дані зарубіжних та російських ЦОД

Звичайно це не всеосяжний документ, і в рамках одного документа розглянути основні питання, що виникають на стадіях обґрунтування, проектування, введення в експлуатацію і самої експлуатації неможливо. Тому я постараюся, по можливості висвітливши ключові моменти всього життєвого циклу ЦОД, приділити особливу увагу питанням, як на мене, найменш описаним у літературі та Інтернеті. Від того, що деякі питання не отримали належного освітлення, вони не перестають бути важливими, тим більше, що деякі з них, як показано буде далі замовчуються з певних причин.

Попередньо спробую уточнити коло фахівців, для яких документ буде орієнтований. Це будуть фахівці організацій, що не мають ЦОД, але бажають його побудувати, фахівці, які прийняли рішення побудувати ЦОД, але не знають, на що звернути увагу при написанні технічного завдання (Т)З і як вибрати партнера, фахівці, які побудували ЦОД, але намагаються при його експлуатації. забезпечити заявлені характеристики та знизити витрати. А також ймовірно, документ буде цікавий постачальникам обладнання та розробникам ЦОД, хоча б у плані розуміння проблем їхніх клієнтів. Хоча документ і розглядатиме більшість питань, що виникають при обґрунтуванні вибору ЦОД, його проектуванні, побудові та експлуатації, але в документі не буде вказівок на вибір того чи іншого обладнання, і навіть на обов'язкове використання тих чи інших технологій. Справа в тому, що нова техніка, рішення та технології з'являються щороку, часто, по суті, відрізняючись внесенням деяких несуттєвих змін або реалізацією давно відомих рішень, але на новому технічному рівні. Пам'ятайте - Знання декількох принципів, звільняє нас від знання безлічі частковостей ». Виходячи з цього, я і постараюся в першу чергу, розповісти про принципи проектування та експлуатації складних обчислювальних систем, які, якнайкраще підходить для ЦОД.

Для того щоб обговорювати проблеми побудови та експлуатації ЦОД треба визначитися з деякими термінами і зрозуміти що ж таке ЦОД. Тому я спочатку спробую визначитися з самим терміном «ЦОД».

Визначення терміна «ЦОД»

Останнім часом дуже модно почало міркувати про створення ЦОД. Майже кожна фірма, що себе поважає, заявляє, що однією з її спеціалізацій є побудова ЦОД або Дата-центрів. Зазвичай компанії посилаються на позитивні відгуки, виконані проекти, і т.д. і т.п.

Спробуємо спочатку розібратися, що таке ЦОД, чим він відрізняється від просто хорошої серверної, а також які властивості ЦОД дозволяють йому називатися ЦОД. Так само спробуємо зрозуміти, виконання яких робіт при побудові ЦОД вимагає особливої ​​уваги і де можна заощадити без втрат в якості. Аналіз всього цього дозволить не тільки створити якісніший ЦОД, а й стане в нагоді при побудові інших об'єктів зберігання та обробки даних.

Якщо звернутися до Вікіпедіїто ЦОДабо центр зберігання та обробки даних (ЦОД/ЦХІД) - це спеціалізована будівля для розміщення (хостингу) серверного та комунікаційного обладнання та підключення абонентів до каналів мережі Інтернет. Інша назва ЦОД Дата центр(Від англ. data center).

Зауваження : Якщо в документі наводиться термін « Дата центр», то це означає, що цитується, або переказується документ, де використовується саме такий термін, а не термін « ЦОД».

Насправді таке трактування як мінімум не розкриває всієї суті, що таке ЦОД. Значно ближче за змістом таке трактування «ЦОД – це будівля (або його частина) для якого застосовані комплексні рішення щодо зберігання, обробки та розповсюдження інформаційних даних з IT-інфраструктурою, що дозволяє забезпечувати свої функції, що задовольняють певним критеріям».

Принаймні, у визначенні ЦОД не варто підкреслювати наявність хостингу та Інтернету, т.к. вони дійсно можуть бути, але їхня відсутність не є критичною для ЦОД. У тому вигляді, як наводиться уточнене формулювання ЦОД, воно найбільш повно відповідає концепції ЦОД, викладеної в Стандарті TIA-942. Хоча, на мій погляд, варто було б уточнити формулювання. ЦОД - Це будинок, його частина, або група будівельдля яких застосовані… " далі по тексту. Т.к. цілком може виявитися, що з реалізації ЦОД з дублюванням підсистем територіально ЦОД виявиться рознесений між кількома будинками. Іноді згадують і про те, що при функціонуванні ЦОДу необхідно розробити комплекс організаційних процедур і постійно займатися навчанням персоналу. Але це не настільки важливо, т.к. Варто лише розуміти, що ЦОД це як будинок, а й комплекс інженерних рішень, та й як її, а як і забезпечення необхідних сервісів і наявність кваліфікованого персоналу.

Історично дата-центри (назва ЦОД з'явилося пізніше в Росії) виросли з великих серверних IT-компаній у 90-х роках. Цій якісній зміні сприяла поява клієнт-серверної технології, поява нових стандартів кабельних мереж та поява ієрархічного управління носіями даних. Основні риси ЦОД склалися до 2000 року, коли дуже затребувані стали ЦОД для розгортання інтернет серверів організацій, які мають можливостей з їхньої підтримки, а також забезпечення роботи у своїх обчислювальних центрах баз даних різних організацій, що розрослися.

В даний час в одному Санкт-Петербурзі більше 30 ЦОД. Насправді їх більше, т.к. деякі організації побудували собі інфраструктури, що підходять під поняття ЦОД.

Щодо Стандарту TIA-942Необхідно зауважити, що в документі докладно опрацьовані питання побудови (в основному у формі викладів вимог) інженерних підсистем, але якщо спробувати поставити питання питання вибору конкретного проекту для побудови ЦОД, з метою виконання конкретних завдань, відразу з'являються питання. У стандарті TIA-942 вводиться поняття рівнів TIER. Стандарт розглядає чотири рівні, пов'язані з різним ступенем готовності (термінологія TIA-942 ) інфраструктури обладнання дата-центру. Вищі рівні відповідають як вищої готовності, але відповідно викликають підвищені витрати створення інфраструктури. Фактично Стандарт TIA-942 поділяє (класифікує) ЦОДи тільки за рівнем надійності (іноді пишуть що за рівнем доступності, але цей термін хоч і близький, але все ж таки він вже терміну « надійність»).

Класифікація ЦОД

Саме поняття ЦОД досить малоінформативне, річ у цьому всі ЦОДи різні як за розмірами, а й у завданням, покладеним ними, наскільки можна забезпечувати з певним рівнем (якістю) свої основні функції. Та й основними функціями різних ЦОД залежно від своєї орієнтації можуть вважатися різні функції.

Якщо подивитися більш уважно, можна виділити досить багато критеріїв, за якими можна розділити ЦОДи. В основному саме ці критерії будуть визначальними при функціонуванні ЦОДів, або ці критерії нестимуть у собі набір якихось властивостей, що дозволяють виділити певну групу ЦОДів.

Можна розділити ЦОДи за:

• Призначення або точніше - розділити їх на публічні та не публічні (частіше використовується термін "корпоративні") ЦОДи;
• Надійності зберігання даних (якщо бути точнішим, то за сукупністю надійності та доступності).

Існують ще як окремі групи КатастрофостійкіЦентри Обробки Даних (КЦОД) та « треш-дата-центри». Назва «треш» походить від (англ. trash- сміття) – зазвичай це невеликі ЦОДи, охолодження у яких реалізовано лише рахунок природного повітрообміну.

Такі «сміттєві» ЦОДи здебільшого не відповідають повністю вимогам до ЦОДів, але менш затратні, екологічні та оренда серверних стійок у них коштує значно дешевше.

З поділом на громадські і публічні ЦОД все ясно, і підхід до проектування вони різний. Адже роблячи ЦОД під себе, організація досить добре знає, які основні властивості їй необхідні, а де вона може заощадити. Звідси випливає можливість вибіркового виконання вимог для ЦОД. У публічних ЦОД все трохи складніше і якщо на ЦОД хочуть отримати сертифікацію, щоб збільшити кількість своїх клієнтів, то, як мінімум, обов'язкові рекомендації доведеться виконувати все.

Якщо говорити про надійність, то треба починати з розгляду терміна «Напрацювання на відмову». Взагалі-то не факт, що система після виходу з ладу у разі відмови одного зі своїх елементів перестане функціонувати. Якщо при виході з ладу (переході з працездатного стану в не працездатний) одного з елементів системи система стає непрацездатною, то кажуть, що стався відмова. Якщо все ж таки система залишилася працездатною, то кажуть, що стався збій. Момент та частота появи збоїв та відмов описуються методами теорії ймовірності та в цьому документі не розглядається. Єдино про що треба пам'ятати що, лише аналізуючи схемунадійності системи та маючи дані про напрацювання на відмову в цифровому вираженні кожної його складової частини можна говорити про рівень доступності або працездатності всієї системи. Частка (%) часу протягом року, коли система знаходиться в робочому стані та/або у стані простою (% Uptime and Down time), безпосередньо пов'язані між собою. Період простою (downtime) – це сумарний показник простоїв протягом року. Цими термінами часто оперують під час обговорення різних рівнів ( Tier) ЦОД. Але їхнє цифрове вираження для різних рівнів не коректне, т.к. розкид показників відмовостійкості у ЦОД одного рівня може бути значним. У відповідному місці документа буде показано, що всі цифри, що характеризують період простою у різних рівнів ЦОД від лукавого, і реально спиратися на них не можна. Якщо говорити коротко, то перелік найбільш характерних рис різних рівнів ЦОД можна звести у просту таблицю.

Наприклад, наводжу відповідність доступності, часу знаходження системи в неробочому стані (на рік). До цифр прив'язувати рівні нічого очікувати, т.к. я вже сказав вище, розкид показників доступності на рік може бути в межах одного рівня досить великий.

Запис виду «Без резервування» не говорить про те, що у разі виходу з ладу буде очікуватися замовлення та отримання від постачальника блоку, що відмовив. Наявність прорахованих запасів ЗІП та зниження значення показника MTTR (середній час ремонту) також помітно впливає на час простою.

Ще одне важливе зауваження. ЦОД буде максимально того рівня якого мінімальний рівень однієї зі складових його частин. Але з іншого боку слід пам'ятати, що не всі рекомендації зі стандартів є обов'язковими, і якщо знати конкретно на що і як впливає їхнє порушення, то зазвичай можна дещо заощадитипри побудові ЦОД.

Приклад

Розробники досить часто борються за підвищення енергоефективності ЦОД, яка,оцінюється як співвідношення загальної потужності до потужності ІТ-обладнання, що довго боролися за можливість підвищити робочу температуру. Ідея здорова, адже реальний термін служби більшості комп'ютерного обладнання в ЦОДі 3-4 роки, хоча водночас слід зазначити, що апаратура, що відповідає за енергозабезпечення, зазвичай замінюється рідше, щоправда, при правильному технічному обслуговуванні. Після цього терміну обладнання замінюється, або найбільш критичні програми переносяться на інше нове обладнання. Збільшення ж на кілька градусів температури в приміщенні реально не впливає на можливість відмови обладнання за цей термін, але помітно зменшує втрати на охолодження, тим самим підвищуючи енергоефективність.Наразі є тенденції для деяких класів ЦОД ще підвищити допустиму температуру.

Тому дуже важливе знання про те, чому в Стандартах наводяться ті чи інші вимоги і що буде при відхиленні від стандарту в той чи інший бік. З усім цим можна розібратися, лише аналізуючи вимоги до тих чи інших частин ЦОД. Також необхідно розібратися і з питанням, які стандарти регламентують вимоги до складових частин ЦОД, чи не суперечать вони один одному, і чи взагалі варто ці стандарти дотримуватися. Тому наступний розділ буде присвячений стандартам та їх вимогам.

Вимоги стандартів до складових частин ЦОД

Спочатку треба визначитися вимогами, яких стандартів необхідно керуватися, і головне — що буде, якщо їх дещо «порушити» відповідно на краще чи гірше. На самому початку глави, я висловлю дещо крамольну думку. Стандарти необхідно знати, щоб у разі потреби їх можна було за необхідності порушувати. Точніше обґрунтовано робити деякі з вимог для вашого конкретного ЦОДвище або нижче, ніж вимоги стандарту до обраного Вами класу ЦОД. Написав я цей рядок і зрозумів, тепер точно доведеться писати назву цього «розумного» стандарту, вимогам якого слід дотримуватися розробки ЦОД. Але ... ні - не все так просто. Документи, що несуть у своєму заголовку горде ім'я «Стандарт…» насправді найчастіше є узагальненим досвідом групи експертів, які створили цей Стандарт. До доступності (% UP TIME)або часу простою (DOWNTIME) рекомендації немає прямого відношення. Дотримання вимог стандартів дійсно дозволяє покращити ці показники, але на яку величину, то це є таємницею вкритою мороком. Справа в тому, що практично неможливо врахувати всі фактори, що впливають на зменшення або збільшення цих показників і тим більше неможливо отримати дані на всю, використовувану конкретно вами апаратуру вашого ЦОД. Що ж робити? Насамперед, вибудувавши за пріоритетами вимоги до ЦОД, що створюється, спробувати прийняти за основу один із стандартів і надалі дотримуватися його вимог з можливою точністю.

На мій погляд, почати пошук відповідного вам Стандарту потрібно з раніше згадуваного TIA-942 « Телекомунікаційна інфраструктураЦентрів обробки даних». Перша версія стандарту була опублікована у 2005 році. Тут докладно деталізовані вимоги до конструктивів, енергопостачання, тепловідведення, контролю безпеки, надмірності, обслуговування та порядку приймання в експлуатацію.

У червні 2010 року корпорація Building Industry Consulting Service International Inc. (BICSI) опублікувала новий стандарт 002-2010 : Data Center Design and Implementation Best Practices. Цей стандарт BSCI 002-2010відображає зростання складності облаштування обчислювальних центрів та потребу компаній та організацій у розумінні вимог до енергетики, механічних навантажень та телекомунікацій при проектуванні інфраструктури ВЦ.

Яким стандартом краще користуватися? У чому їхня різниця? Як тоді сертифікуватися? Адже є й стандарти від інших організацій. Наприклад, головною відмінністю при сертифікації за стандартами Uptime Institute (Інститут безперебійних процесів) є те, що сертифіковані фахівці цієї організації мають на місці переконатися у реалізації вимог, викладених у своїх стандартах. У середині 2010 року Uptime Institute випустив ще один стандарт “ Operational Sustainability(Операційної стійкості)” регламентуючий та служби експлуатації. Саме вимог до служби експлуатації не вистачало TIA-942 . І хоча спільно виконуючи вимоги Стандарту TIA-942 тастандарту Operational Sustainabilityможна вже досить точно сформулювати вимоги до ЦОД, але на практиці будівельники нових обчислювальних центрів найчастіше посилаються на стандарт TIA-942. Справа в тому, що кожен із стандартів складався різною організацією і в багатьох деталях відрізняються один від одного. Тим більше що, на думку фахівців Uptime Institute, їхній порядок поділу на рівні доступності ніяк функціонально не пов'язаний із рівнями TIA-942, вони оцінюють здатність обчислювальних центрів підтримувати працездатність в умовах відмов та аварій. Щоб уникнути плутанини, фахівці Uptime Institute пропонують позначати рівні доступності в їх тлумаченні римськими цифрами I, II, III та IV. Досить складно та сертифікувати ЦОД. Якщо звернутися до сайту Uptime Institute(сайт http://uptimeinstitute.com) то на кінець травня 2012 року реально забезпечує IV Рівень (тобто не тільки документація та створена будівля з технічними засобами в ньому, а й рівень експлуатації) тільки 1 центр, сертифікація збудованого об'єкту на IV Tier проведена для 6 ЦОДів. Сертифікацію документації для побудови ЦОД IV Tier отримано для 22 об'єктів. Російських ЦОД серед Tier IV зараз немає. ЦОД рівня III так само не дуже багато. Забезпечують повневиконання вимог для ІІІ рівня по «Операційній стійкості» всього лише 4 ЦОДи. Російських серед них немає. Документація та приміщення відповідає Tier III у 5 російських ЦОД (4- Design Documents та 1 Constructed Facility).

Протягом 2012 року буде опубліковано Стандарт TIA-942-A, що включить зміни та доповнення наступних версій TIA-942-1 і TIA-942-2. На жаль, нова версія стандарту дуже змінилася. Новий стандарт TIA-942-A стосуватиметься лише теми кабельних систем і вже не буде таким всеосяжним, яким був стандарт TIA-942. Тобто. переважно він буде регламентувати лише побудову кабельних систем. Розділ про енергетичну ефективність, швидше за все, стосуватиметься цієї теми лише з погляду кабельної системи та використання «зеленого» середовища передачі даних – оптоволокна.

Нижче наведено перелік основних змін, включених до поточного проекту TIA-942-A (згідно з попередньою заявою розробника). Ця інформація виділена курсивом.

TIA-942-A приведений у відповідність до серії стандартів TIA-568-C щодо топології, термінології та класифікацій середовища, представлених у стандарті 568-C.0, а також специфікацій компонентів, представлених у TIA-568-C.2 та C .3;

• Додатки, TIA-942-1 та TIA-942-2, включені до стандарту TIA-942-A;
• Інформація із заземлення була переміщена зі стандарту TIA-942-A до стандарту TIA-607-B;
• Інформація з адміністрування буде переміщена до стандарту TIA-606-B;
• Більшість інформації, що стосується телекомунікаційних шаф та серверних стійок, поділу силових та телекомунікаційних кабельних систем, буде переміщена до стандарту TIA-569-C;
• Інформація щодо зовнішньої кабельної розводки переміщена до TIA-758-B;
• Скасовано обмеження довжини горизонтальних оптоволоконних кабельних систем на 100 метрів.
• Кабелі Category 3 та Category 5e більше не повинні застосовуватись у горизонтальних кабельних системах. У робочій версії стандарту дозволено застосування збалансованих кручених пар типу Category 6 і Category 6A в горизонтальних кабельних системах. Category 6 і Category 6A можна використовувати і в магістральних кабельних системах;
• Схвалено застосування в горизонтальних та магістральних кабельних системах багатомодових оптоволоконних кабелів типу OM3 та OM4 (багатомодове оптичне волокно з діаметром сердечника/оболонки 50/125 мкм, оптимізоване для роботи з джерелами світла на основі лазерів на довжині хвилі 850 нм). Кабелі типу OM1 та OM2 більше не дозволяються для використання;
• Для з'єднання одного або двох волоконних кабелів повинні використовуватися волоконно-оптичні роз'єми типу LC та для багатоволоконних роз'єми типу MPO;
• У топологію ЦОД включена проміжна розподільна зона (IDA);
• До стандарту додано розділ з енергетичної ефективності;
• Додані терміни «апаратна розетка» (EO – equipment outlet) та «зовнішній мережевий інтерфейс» (ENI – external network interface), запозичені з міжнародного стандарту ISO/IEC 24764.

Стандарт "Operational Sustainability (Операційної стійкості)" всього лише доповнює TIA-942особливо у частині експлуатації ЦОД.

Стандарт «Operational Sustainability» визначає вимоги, що дозволяють гарантувати стійкість центрів обробки даних, а також мінімізувати пов'язані з цим ризики. Як відомо, попередній широко поширений стандарт Tier Standard: Topology регламентував технічні параметри ЦОД, необхідні для досягнення певного рівня надійності. Особливість нового стандарту у тому, що він враховує людський фактору стійкій роботі ЦОД. І це має велике значення, тому що відсоток помилок у роботі, пов'язаних з цим фактором досягає 70% , з них трохи більше 40% пов'язані з помилками керуючих служби експлуатації. Щоб мінімізувати ці помилки необхідно вести цілеспрямовану роботу з персоналом, підвищувати його кваліфікацію, проводити заходи щодо утримання кваліфікованих кадрів.

Якщо розглядати стандарти від корпорації BICSI, можна помітити, що й підхід відрізняється від підходів до оцінки рівнів стійкості інших організацій.

Система оцінки рівнів стійкості та основні розділи стандарту BICSI 002 2010 . Як стверджують в асоціації, розробники стандарту ставили за мету забезпечити проектування та будівництво центрів обробки даних з урахуванням довгострокової перспективи їх експлуатації. Основні розділи документа:

• Планування ЦОД
• Вибір майданчика
• архітектурні рішення
• Будівельні конструкції
• Електротехнічні системи
• Механічні системи
• Пожежногасіння
• Безпека
• Системи автоматизації будівлі
• Телекомунікації
• Інформаційні технології
• Введення в дію
• Експлуатація та технічне обслуговування
• Процес проектування
• Надійність

Тому щодо стандартів для побудов ЦОД необхідно помітити, що всі розробники загальних стандартів для ЦОД не суперечать один одному в частині вимог та посилань на Стандарти при побудові базових рівнів ЦОД. Комерційні ЦОД в силу своєї специфіки повинні задовольняти (і бажано бути сертифіковані) всім вимогам стандарту, який вони взяли за основу. Не всі рекомендації впливають основне якість ЦОД — забезпечення заданого рівня доступності. Тому некомерційні ЦОД часом можуть деякі вимоги і ігнорувати. Тим паче що сертифікація річ не тільки дорога, а й прямо не впливає на рівень працездатності ЦОД. Після реалізації ЦОД все ж таки можна вносити деякі зміни не тільки до рівня підтримки, але й до інших рівнів, намагаючись задовольнити вимоги якогось із стандартів для отримання сертифікації.

Uptime Institute свого часу визначив чотири рівні, пов'язані з різним ступенем готовності інфраструктури обладнання дата-центру (ЦОД). Насправді хоч вони пов'язані з рівнем доступності, але напевно більш правильно говорити про рівні TIER, хоча термін «TIER» і перекладається як — «Рівень». Вище я, недаремно розкриваючи поняття «Рівень», не наводив цифрових характеристик рівня доступності ЦОД. Цифрові висловлювання були отримані лише з аналізу реалізованих проектів. Наводжу деякі дані з документа, розробленого Інститутом проблем працездатності (The Uptime Institute) у виданому ними бюлетені "Класифікація рівнів за галузевим стандартом, що визначає якість роботи інфраструктури об'єкта" (Industry Standard Tier Classifications Define Site Infrastructure Performance).

Загальний висновок щодо використання стандартів:

• Основним варто вважати використання стандарту TIA - 942 з останніми доповненнями (наприклад зі стандартом "Operational Sustainability (Операційної стійкості)";
• Новий стандарт TIA-942-A (схвалений 24 квітня 2012 року) стосується лише теми кабельних систем і вже не буде таким всеосяжним, яким був стандарт TIA-942;
• При побудові ЦОД слід користуватися не лише стандартами, а й здоровим глуздом, що дозволяє суттєво заощадити, не погіршуючи найбільш затребуваних його якостей;
• Сертифікація найбільш потрібна комерційному ЦОД, а ЦОД організації може цим займатися. Звичайно якщо ЦОД все, що створювався на основі стандартів, то всі відступи від рекомендацій повинні бути обґрунтованими;
• Прочитати, і, головне, зрозуміти який Стандарт взяти за основу і на які вимоги його необхідно буде наголосити на майбутній розробці, не можна вважати, що роботу зі стандартами ви закінчили. Перед тим, як переходити до наступного етапу, необхідно в обов'язковому порядку перечитати старі, добрі, щоправда, зараз переважно забуті ГОСТи – серії 34. І нічого, що вони вже багато років не оновлювалися, але там є докладний розгляд передпроектних стадій. У них немає слів «бізнес-процеси», «процесорний підхід», що є на слуху, але є поняття «інформаційна модель» цілком коректно їх замінює. Тому особливо на стадії ТЗ ці документи вам допоможуть. Звичайно, підходити потрібно творчо і не слідувати буквально всім рекомендаціям, але уважно їх прочитати необхідно.

Порядок побудови ЦОД

Як не дивно, найбільший внесок у успішність або не успішність майбутнього проекту вносять початкові стадії. Загалом за світовою статистикою в IT індустрії успішним стає тільки один проект з 3-х. Якщо підійти жорсткіше, і оцінювати успішність проекту як:

• можливість виконувати заявлені функції з необхідною якістю
• виконати роботу за планований час
• невиході за межі первісного бюджету проекту
• відсутність авральних робіт на різних етапах проекту
• відсутність необхідності одразу розпочинати роботу з модернізації проекту.

Все буде ще гірше. Напевно, під визначення «успішний» потрапить не більше 20% проектів.

Причин для провалу проекту чимало. Тут і неправильна політика (саме політика, тому що вирішення спірних питань це найчастіше знаходження компромісів) керівництва проекту, відсутність належної підтримки у керівника організації, слабке опрацювання ТЗ і як результат велика кількість незапланованих робіт, слабка участь фахівців організації, для якої проект виконується і будь-які форс-мажорні обставини.

Якщо практично над кожним проектом ймовірність провалу, то, як бути з бадьорими заявами про десятки успішних проектів у безлічі фірм? Спочатку потрібно відразу поставити все на свої місця, визначивши термін « Проект».

Проект(якщо звернутися до Вікіпедії) - це унікальна (на відміну від операцій) діяльність, що має початок і кінець у часі, спрямована на досягнення заздалегідь визначеного результату/мети, створення певного, унікального продукту або послуги, при заданих обмеженнях за ресурсами та термінами, а також вимогам до якості та допустимого рівня ризику. Напевно, це визначення можна для більшої конкретики спростити. Проект— це сукупність завдань, заходів або виконаних робіт, пов'язаних з досягненням запланованої мети, яка зазвичай має унікальний та неповторний характер . Основне це те, що проект завжди унікальний (хоча б для осіб, які його виконують). Тому все те, про що виконавці кажуть, як про успішний проект насправді є успішним використанням,тобто. реалізацією вже готового рішення. Відсоток реалізації успішних впроваджень значно вищий, ніж успішних проектів. І якщо у програмістів написання будь-якої складної програми завжди є проектом, то у сфері побудови інфраструктури можливі і впровадження. Досить складно провести межу, коли використання переростає в проект. Наприклад, якщо створюється невеликий програмно-апаратний комплекс для автоматизації, якогось віддаленого майданчика і робиться це розробником не вперше, та й кількість відмінностей від раніше створених як в апаратній частині, так і в наборі програм, що встановлюються мінімально, то це впровадження. І воно має чималі шанси на успіх. Якщо ж з'явилися відмінності в частині значної кількості нових апаратних засобів, встановлення нового складного ПЗ або появи нових вимог, які не виконати в рамках реалізації попередніх рішень, створення такого апаратно-програмного комплексу буде проектом . Тобто. виконавець проекту завжди на початку своєї роботи перебуває у стані, коли цілі визначені, шляхи вирішення невизначені, успішне вирішення задачі під питанням. Пояснюю, чому я докладно зупинився на, начебто, термінологічному питанні.

Справа в тому, що існують 2 підходи до виконання робіт та їх оцінки. Це підхід Розробника та підхід Замовника.

Розробник, намагається під час реалізації завдання від Замовника:

1. Намагатися застосувати вже реалізоване раніше Розробником рішення;
2. У разі неможливості цього, намагається застосувати апробоване іншими фірмами рішення (найчастіше рішення, рекомендоване виробником обладнання або ПЗ);
3. Спробувати знизити вимоги Замовника та по можливості звести їх до тих самих типових рішень;
4. У разі невдачі попереднього пункту Розробник намагається збільшити час виконання робіт або зробити м'якшими вимоги щодо прийняття своєї роботи;
5. Спробувати на етапі приймання сконцентруватися на сильних сторонах виконаного проекту та приховати свої помилки та недоопрацювання;
6. Спробувати якнайшвидше здати проект і почати новий, або, у крайньому випадку, забезпечити собі аутсорсинг.

Підхід Замовника насамперед характеризується:

1. Спробою отримати якнайбільше від Розробника і за менші гроші;
2. Спробами у процесі розробки проекту змінити чи уточнити пункти початкового ТЗ;
3. Під час приймання спробувати отримати якомога більше документації та знайти помилки розробника;
4. Постаратися рахунок Замовника не тільки виправити виявлені в процесі прийому помилки, але і внести чергові зміни в проект.

Тому використання впровадження, замість розробки проекту, що має значно менше шансів на успіх, завжди бажано для Виконавця. Вищезазначений варіант звичайно найбільш актуальний, якщо розробку проекту веде стороння організація. Насправді при замовленні дійсно складного проекту (а побудова ЦОД саме до таких проектів і належить) у сторонньої фірми, необхідна участь фахівців Замовника, як мінімум на початкових стадіях проекту. Дійсно ніхто не знає так вимоги до ЦОДу, як фахівці Замовника. Звичайно, Замовник, як мінімум повинен мати можливість контролювати виконання проекту, точніше мати інформацію про терміни кожного з етапів, хід його виконання, а також не просто брати участь у прийманні проекту, а й брати участь у написанні програми випробувань. Тільки в цьому випадку можливе досить точне формулювання Тех. завдання, оперативне вирішення питань, всеосяжна перевірка отриманого результату.

Існують два варіанти рішень виконання проекту щодо побудови ЦОД. Перший передбачає виконання проекту самотужки, а другий покладає ці обов'язки на стороннього виконавця. У чистому вигляді такі схеми трапляються рідко. Практично завжди побудова таких систем має спільну роботу Виконавця (або кількох Виконавців) та Замовника. Але все впирається у питання, хто керуватиме проектом. Здавалося б, кому, як не Виконавцю давати такі права, але… Участь у написанні ТЗ одночасно Замовника (оскільки він знає всі вимоги до свого ЦОД) і Виконавця (бо якщо не залучати Виконавця, то Замовник цілком може написати таке ТЗ, яке взагалі ніхто не зможе реалізувати) дозволяє виробити в процесі обговорення досить точне уявлення про систему, яка створюватиметься, та про програмні засоби, які повинні застосовуватися. Тобто. спеціалісти, які беруть участь у написанні ТЗ стають на момент закінчення його написання найкомпетентнішимиу частині конкретних вимог для проекту, який виконується для конкретного замовника. Відразу відповідаю на можливі запитання щодо спільного написання ТЗ. Замовник розробки великих проектів може поодинці написати лише Попереднє ТЗ, придатне максимально лише для проведення конкурсупід час пошуку Виконавця. А спільно написане ТЗ із струсовими між Виконавцем та Замовником спірними питаннями буде основним документом при прийманні ЦОД, оскільки на основі ТЗ писатиметься «Програма та методика випробувань».

Тому однією з основних помилок у Замовника є усунення від роботи фахівців що беруть участь у написанні ТЗ та епізодична участь в ескізному та робочому проекті тільки вузьких фахівців при вирішенні приватних питань. Фахівці, які беруть участь у роботі з реалізації великих проектів повинні у Замовника перебувати у відділі комплексних робіт. І саме вони мають залучати у разі потреби всіх спеціалістів з окремих напрямків. В цьому випадку фахівці комплексного відділу будуть в курсі всіх «тонких» місць проекту і сам проект отримає великі шанси на успішне завершення. Також фахівці комплексного відділу повинні брати участь у прийманні роботи Замовника, т.к. постійно стежачи за перебігом робіт, вони знатимуть всіх його проблем.

Зауваження щодо робіт, що відносяться до компетенції комплексного відділу.

Невірно думати, що завантаження комплексного відділу обмежиться лише участю у великих проектах, яких у Замовника зазвичай не дуже багато. Великі проекти існують не самі собою. Зазвичай кожен проект вимагає свого розширення, стикування з різними підсистемами, внесення змін у зв'язку з завданнями, що знову з'явилися. Саме у вирішенні цих питань і знадобляться фахівці-комплексники. Попереднє стосувалося не лише великих проектів, адже слід зрозуміти, що Тільки застосування окремих товарівщо не зачіпають велику кількість співробітників Замовника, можна впроваджувати, минаючи комплексний відділ.

Якщо ми звернемося до досвіду реалізації великих проектів, то зауважимо, що великі організації (наприклад, банки) або ті, спеціалізація яких пов'язана з IT, самі керують проектами зі створення своїх ЦОД.

Підбиття підсумків за етапами обґрунтування та складання ТЗ

З викладеного вище можна дійти невтішного висновку:

1. Говорячи про створення ЦОДу потрібно в першу чергу розставити пріоритет вимог, яким він повинен буде задовольняти.
2. Після встановлення пріоритетів необхідно взяти за основу один із стандартів, вимогам якого ви будете дотримуватися. (Я б радив використовувати TIA-942, але не можна забувати, що він не розглядає питань експлуатації.)
3. Усі відступи від стандарту на краще чи гірший бік мають бути обгрунтовані.
4. Для складання ТЗ необхідно задіяти відділ комплексних робіт (або створити його), т.к. з вашого боку потрібні люди персонально зацікавлені в успішній реалізації проекту і які займатимуться всіма роботами з Виконавцем.

Якщо ви помітили, що у цій частині я розглянув питання до початку написання ТЗ, наголосив, що писати ТЗ потрібно обов'язково з Виконавцем, а про вибір виконавця нічого не написав. Справа в тому, що вибір Виконавця окреме та відповідальне завдання. І якщо дуже коротко про це згадати, то зазвичай вибір розбивається на 2 етапи:

1. Визначення кола претендентів на вирішення завдання побудови вашого конкретного ЦОД.
2. Аналіз представленого фірмами матеріалу та уточнення питань при особистих зустрічах.

Зазвичай простіше обравши кілька фірм, що реалізують успішні проекти в цій галузі, надати їм попереднє ТЗ (таке ТЗ можливо скласти фахівцям Виконавця). Потім кандидатів на побудови ЦОД просять скласти невеликий документ, який коротко описує всі підсистеми ЦОД та процес його експлуатації. Зазвичай за повнотою питань, обґрунтованості рішень та результатами особистого спілкування вибір Виконавця стає очевидним. І ще від себе додам: якщо вам при особистій зустрічі обіцяють все і за дешево (принаймні, значно дешевше, ніж в інших) це привід не повірити і ще раз перевірити реальність та якість виконаних фірмою проектів. Крім того, часто в дійсно складних проектах побудови ЦОД виконання якихось його підсистем вимагає залучення інших фірм. У цьому випадку відразу потрібно домовлятися про те, що одна з фірм є для цього проекту системним інтегратором, і всі технічні та інші питання ви вирішуєте з нею. Нічого немає гіршого за «шматочну» реалізацію проекту. А то за будь-якої неприємності все буде як безсмертний монолог Райкіна «До ґудзиків претензії є?».

Центр обробки даних (ЦОД)- Єдина багатокомпонентна система, яка покликана забезпечувати безперебійну автоматизовану роботу бізнес-процесів. Центри обробки даних створюються в першу чергу для збільшення продуктивності компаній, що активно використовують у своїй діяльності інформаційні технології, а також підвищення якості послуг.

Для зберігання та обробки великої кількості інформації використовуються спеціалізовані технічні рішення, потужні сервери, дискові сховища. Створювати та обслуговувати такі технічні системи самостійно досить складно та дорого: утримання серверів потребує спеціальних технічних умов, окремих приміщень та кваліфікованого персоналу. Одним із основних призначень дата центрів якраз і є створення відповідних умов розміщення таких технічних рішень.

Переваги для бізнесу

Створення багатокомпонентних систем, які вирішують більшість проблем у бізнесі, набагато скорочують витрати підприємств. Зокрема, для компаній з територіально-розподіленою інфраструктурою це незамінне рішення, оскільки 1–2 співробітники, які обслуговують ЦОД, успішно замінюють безліч осіб, які працюють в офісах у регіонах. Згодом багато підприємців замислилися над придбанням центрів обробки даних у зв'язку з тим, що потрібно було інтегрувати багато інформації. Ризик втратити певні відомості безповоротно став дуже великий і зумовив певні витрати на відновлення інформації. Крім того, виникли ризики позбавлення частини доходів у зв'язку з простоями з різних причин. Тобто завдяки своїм унікальним особливостям ЦОД забезпечує ефективну безперебійну роботу будь-якої організації.

Перевага дата-центру в тому, що людина або компанія, може, з будь-якої точки планети, використовуючи будь-який пристрій доступу в мережу, працювати з необхідною та достатньою обчислювальною потужністю, необхідним обсягом пам'яті, усім необхідним програмним забезпеченням, яке працюватиме та зберігатиметься на серверах у дата-центрі.

Традиційні послуги в дата-центрах: оренда стійки, розміщення серверів, підключення до Інтернету, оренда каналів зв'язку, встановлення, настроювання програмного забезпечення, адміністрування. Нині до них додалися надання у найм обчислювальних потужностей, віртуальних серверів, дискового простору для резервного копіювання даних, оренди додатків.

• Надійність збереження інформації. Причому ця надійність підтверджується як закладеної на етапі проектування архітектурою, і подальшою експлуатацією. Цікавий факт, що при детальному порівнянні вартості володіння інформаційною системою, розташованої на території замовника (як правило, це бізнес-центр) та в дата центрі, виходять цілком порівняні цифри, чого не можна сказати про порівняння надійності цих способів.

• Зменшення тимчасових витрат за реалізацію нових проектів у сфері IT. Під час роботи у дата-центрі компанії самостійно обирають послуги, які вони хочуть отримувати. Найзатребуванішими залишаються оренда стійки, юніта, готового сервера, віртуального сервера та резервне копіювання даних. Але, крім цього, існує низка інших послуг, якими компанії-орендарі можуть при необхідності скористатися, що значно заощадить час на запуск нового IT-проекту. Наприклад, це оренда додатків, що дозволяє уникнути масштабних інвестицій на початковому етапі роботи. Як приклад можна навести оренду 1С бухгалтерії – для розгортання готової системи, придатної для роботи, достатньо замовити та сплатити таку послугу в дата центрі. При цьому часто в офісі замовника не потрібно нічого купувати, встановлювати або налаштовувати, крім доступу в Інтернет.

• Скорочення витрат за оренду приміщення. Сюди можна віднести витрати на електрику, офісні площі, що використовуються під «серверні», та обслуговування власних систем охолодження та безперебійного живлення. До речі, куплена в офіс техніка стає основними засобами підприємства, ними нараховується податок на майно.

• Організація безперервної роботи головного офісу із філіями компанії по всій країні. доступ до робочої інформації незалежно від місця перебування працівника. Наприклад, керівник компанії може, перебуваючи у відпустці, перевіряти робочу пошту, зв'язуватися зі своїми співробітниками через IP-телефонію.

• Можливість створення резервного офісу організації, якщо з якихось причин робота в основному офісі неможлива, а необхідно отримати важливу інформацію, доробити проект

скорочення витрат на придбання додатків. Для посилення конкурентних позицій власники датацентрів розробляють новий спектр послуг, який можна пропонувати орендарям.

Першими, хто почав використовувати у роботі центри обробки даних, були великі зарубіжні компанії. За ними були і російські підприємці. У РФ у 2000-2001 роках з'явилися перші власники ЦОДу. Піонером виступив Ощадбанк Росії. Саме вона є найбільш територіально-розподіленою організацією. Тобто потреба у створенні інтеграції численних даних була високою. Надалі власними ЦОД були і великі нафтові компанії.

Типи центрів обробки даних

Залежно від призначення розрізняють три різні типи дата-центрів, кожен з яких розрахований на певну модель підприємства та має власні оперативні завдання та проблеми:

• корпоративні дата-центри;
• хостингові дата-центри, що надають комп'ютерну інфраструктуру як послугу (IaaS);
• дата-центри, які використовують технологію Web 2.0

Нижче наведено параметри, які можуть відрізнятися в різних типах дата-центрів:

• тип трафіку (внутрішній, зовнішній чи змішаний);
• використання Layer 2 (L2) та/або Layer 3 (L3) для управління трафіком у центрі або на периферії (Top of Rack);
• технологія зберігання даних;
• рівень серверної віртуалізації;
• загальний розмір центру обробки даних (за кількістю серверів).

Створення та модернізація ЦОД

Компоненти ЦОД

Традиційний ЦОД

Обов'язкові компоненти, що входять до складу ЦОД, можна поділити на три основні групи:

1. Технічні компоненти. Вони створюють умови ефективної роботи центру. До таких відносяться:

• серверний комплекс, що включає сервери інформаційних ресурсів, додатків, представлення інформації, а також службові сервери
• система зберігання даних та резервного копіювання – ядро ​​ЦОД. Вона складається з консолідованих дискових масивів, мережі зберігання даних, системи резервного копіювання та аварійного відновлення даних.
• мережна інфраструктура забезпечує взаємодію між серверами, поєднує логічні рівні та організує канали зв'язку. Вона включає магістралі для зв'язку з операторами загального доступу, телекомунікації, що забезпечують зв'язок користувачів із ЦОД
• інженерна система експлуатації ЦОД підтримує умови нормального функціонування центру. До її складу входять підсистеми енергозабезпечення, кліматконтролю, пожежної сигналізації та пожежогасіння, передачі даних, а також автоматизовані системи диспетчеризації, управління інформаційними ресурсами.
• система безпеки запобігає несанкціонованому вторгненню в зони конфіденційної інформації. Вона складається із засобів захисту, системи оповіщення та системи контролю доступу

2. Програмне забезпечення. Це фактично послуги інфраструктури ЦОД і ПЗ для коректної роботи бізнес-процесів, необхідні конкретної організації. До компонентів інфраструктури відносяться:

• операційні системи серверів;
• програмне забезпечення баз даних;
• операційні системи робочих станцій;
• засоби кластеризації;
• засоби резервного копіювання;
• програми пристроїв зберігання даних;
• засоби адміністрування серверів та робочих станцій;
• засоби інвентаризації;
• офісне програмне забезпечення;
• електронна пошта;
• Інтернет-браузери.

До програм, що відповідають за функціонування бізнес-процесів, відносяться:

• ділові програми;
• базові корпоративні інформаційні послуги;
• додатки для колективної роботи;
• галузеві компоненти;
• програмне забезпечення для вирішення завдань конструкторсько-технологічного плану системи електронного архіву та управління проектами;
• програми, що забезпечують послуги файлів, друку, служби каталогів та інших прикладних завдань.

3. Організаційне середовищевирішує питання, пов'язані із наданням IT-послуг. Вона повинна відповідати вимогам IT-послуг, таким як ISO/IEC 20000. Тут представлені:

• процеси надання послуг, тобто якість та доступність послуг;
• процеси взаємовідносин між постачальником та клієнтом, а також з підрядними організаціями;
• процеси вирішення проблем, що виникають під час функціонування будь-якого з компонентів системи;
• процеси управління конфігураціями, моніторинг та контроль статусу IT-інфраструктури, інвентаризація, верифікація та реєстрація конфігураційних одиниць, збирання та управління документацією, надання інформації про IT-інфраструктуру для всіх інших процесів;
• процеси управління змінами, тобто визначення необхідних змін та способів їх проведення з найменшим ризиком для ІТ-послуг, а також проведення консультацій та координації дій з організацією загалом;
• процеси релізу, тобто спільного тестування та введення в активну діяльність організації низки конфігураційних одиниць.

Програмний ЦОД

У програмному ЦОД ми всі оточення реалізуємо у вигляді програмних модулів у віртуальних машинах – virtual appliance. Ідея полягає в тому, що фізично використовуються тільки сервери та комутатори. Решта реалізується як віртуальних машин – virtual appliance.

У світі сервіс-провайдерів ця технологія відома і навіть стандартизована під назвою NFV – Network Function Virtualization – віртуалізація мережевих функцій. Тільки там це використовується для надання сервісів і відповідно багато уваги приділяється засобам оркестрації та управління, інтеграції з OSS системами, що дозволяє автоматизувати процес створення послуг для кожного з абонентів. У корпоративному ЦОДу так часто склад послуг міняти не треба, рівень автоматизації може бути суттєво нижчим, але перенесення всіх мережевих функцій у віртуальні машини все одно дає істотні переваги.

- У вас є ЦОД?
- Так, будуємо на 100 стійок.
– А ми будуємо на 200.
- А ми на 400 із незалежною газовою електростанцією.
- А ми на 500 з водяним охолодженням та можливістю відводити до 10 кВт тепла з однієї стійки.
- А ми спостерігаємо за ринком і дивуємось.

Ситуація на московському (та й російському загалом) ринку ЦОДу ще два роки тому виглядала плачевно. Тотальна нестача дата-центрів як таких і місць у центрах, що вже існували, призвела до того, що стійка на 3-4 кВт, що коштувала в 2004-2005 роках. близько 700 у.о., у 2007-му почала коштувати 1500-2000 у.о. Намагаючись задовольнити зростаючий попит, багато операторів і системних інтеграторів організували «будівлі віку» з метою створення найкращих і найбільших ЦОД. Ці чудові прагнення призвели до того, що на даний момент у Москві є близько 10 дата-центрів у стадії відкриття та первинного заповнення, і ще дещо перебуває у проекті. Компанії «Теленет», i-Teco, Dataline, «Хостерів», «Агава», «Майстерхост», Oversun, «Сінтерра» та ціла низка інших відкрили власні дата-центри на рубежі 2008 та 2009 років.

Бажання вкладати гроші в масштабні телекомунікаційні проекти пояснювалося не лише даниною моді, а й низкою економічних причин. Для багатьох компаній будівництво власного ЦОД було вимушеним заходом: стимулом до цього, зокрема, для хостинг-провайдерів або великих Інтернет-ресурсів стали витрати на інфраструктуру, що постійно зростають. Проте чи всі компанії правильно розрахували свої сили; наприклад, дата-центр одного великого хостинг-провайдера перетворився на довгобуд, який триває вже два роки. Інший хостинг-провайдер, який побудував дата-центр за МКАД, ось уже півроку намагається розпродати його хоч якимось великим клієнтам.

Інвестиційні проекти, запущені у розпал кризи, теж не можуть похвалитися стабільним припливом клієнтів. Часто вартість за стійку, закладена в бізнес-плані на рівні 2000 у.о., в нинішніх економічних умовах знижується до 1500-1400 у.о., на роки відкладаючи вихід проекту на самоокупність.

Залишилися нереалізованими кілька грандіозних проектів будівництва дата-центрів на тисячі стійок із газовими електростанціями за МКАД. Один із таких проектів, зокрема, був «похований» оператором фіксованого зв'язку (у зв'язку з поглинанням компанії більшим гравцем).

Таким чином, на сьогоднішній день окупилися лише ті дата-центри, які були збудовані більше трьох років тому і заповнення яких припало якраз на дефіцитні 2004-2007 роки. У кризу ж - в умовах надлишку вільних площ у дата-центрах - будівництво все нових і нових ЦОД, здавалося б, виглядає справжнім безумством.

Однак не все так погано: навіть в умовах кризи, за дотримання певних умов, можна і потрібно створювати власний ЦОД. Головне – зрозуміти низку нюансів.

Що змушує компанію створювати власний ЦОД

Мотив один – безпека бізнесу та мінімізація ризиків. Ризики ж такі. По-перше, клас комерційних ЦОД у Москві відповідає 1-2 рівню, що означає перманентні проблеми з електроживленням та охолодженням. По-друге, комерційні ЦОД категорично не згодні покривати збитки від простою та недоотриману вигоду. Уточніть максимальний розмір штрафу чи неустойки, який ви можете розраховувати у разі простою, - він, зазвичай, не перевищує 1/30 від орендної плати протягом дня простою.

І по-третє, ви не в змозі контролювати реальний стан справ у комерційному ЦОД:

• це комерційна організація, яка має отримувати прибуток зі своєї діяльності і часом заощаджує навіть на шкоду якості своїх послуг;
• ви приймаєте він всі ризики сторонньої компанії, наприклад - відключення харчування (нехай і короткочасне) за непогашену заборгованість;
• комерційний ЦОД може розірвати договір із вами у час.

Економіка ЦОД

Дуже важливо заздалегідь, правильно і повністю оцінити витрати на будівництво та експлуатацію, а для цього необхідно визначити клас ЦОД, який ви будуватимете. Нижче наведено орієнтовну вартість будівництва майданчика «під ключ» на 5 кВт стійку (без урахування вартості електрики).

Вартість експлуатації ЦОД залежить від багатьох факторів. Перелічимо основні.

1. Вартість електрики = кількість споживаної електроенергії + 30% на відведення тепла + втрати при передачі та перетворенні (від 2 до 8%). І це за умови виконання всіх заходів щодо зниження витрат - таких, як скорочення втрат та пропорційне охолодження (що в деяких випадках, на жаль, неможливе).
2. Вартість оренди приміщення – від 10 тис. рублів за кв. м.
3. Вартість обслуговування систем кондиціювання - приблизно 15-20% вартості системи кондиціювання на рік.
4. Вартість обслуговування енергосистем (ДБЖ, ДДУ) – від 5 до 9% від вартості.
5. Оренда каналів зв'язку.
6. ФОП служби експлуатації.

З чого складається ЦОД

Існує ціла низка формалізованих вимог та стандартів, які мають бути дотримані при будівництві ЦОД: адже надійність його роботи є критично важливою.

Зараз широко використовується міжнародна класифікація рівнів (від 1 до 4) готовності (надійності) ЦОД ()див. таблицю). Кожен рівень передбачає певний ступінь доступності сервісів ЦОД, який забезпечується різними підходами до резервування харчування, охолодження та канальної інфраструктури. Найнижчий (перший) рівень передбачає доступність 99,671% часу на рік (або можливість 28 год простою), а найвищий (четвертий) рівень – доступність 99,995%, тобто. не більше 25 хв простою на рік.

Параметри рівнів надійності ЦОД

Ця класифікація за рівнями була запропонована Кеном Бріллом (Ken Brill) ще в 1990-х роках. Вважається, що перший ЦОД найвищого рівня готовності було побудовано 1995 р. компанією IBM для UPS у межах проекту Windward.

У США та Європі існує певний набір вимог та стандартів, що регламентують будівництво ЦОД. Наприклад, американський стандарт TIA-942 та його європейський аналог -EN 50173-5 фіксують такі вимоги:

• до місця розташування дата-центру та його структури;
• до кабельної інфраструктури;
• до надійності, специфіковані за рівнями інфраструктури;
• до зовнішнього середовища.

У Росії її на даний час не розроблено актуальних вимог до організації ЦОД, тому вважатимуться, що вони задаються стандартами для будівництва машинних залів і СНиПами для будівництва технологічних приміщень, більшість положень яких було написано ще наприкінці 1980-х гг.

Отже, зупинимося на трьох «китах» будівництва ЦОД, які є найбільш значущими.

живлення

Як побудувати надійну та стабільну систему електропостачання, уникнути надалі збоїв у роботі та не допустити простоїв обладнання? Завдання не з простих, що вимагає ретельного та скрупульозного вивчення.

Основні помилки зазвичай припускають ще етапі проектування систем електроживлення ЦОД. Вони (у перспективі) можуть викликати відмову системи електропостачання з наступних причин:

• перевантаження ліній електроживлення, як наслідок - вихід із ладу електрообладнання та санкції енергонаглядових органів за перевищення ліміту споживання;
• серйозні енерговтрати, що знижує економічну ефективність ЦОДу;
• обмеження в масштабності та гнучкості систем електроживлення, пов'язані з навантажувальною здатністю ліній електропередач та електрообладнання.

Система електроживлення у дата-центрі має відповідати сучасним потребам технічних майданчиків. У класифікації ЦОД, запропонованої Кеном Бріллом, стосовно електроживлення ці вимоги виглядатимуть так:

• Рівень 1 - достатньо забезпечити захист від стрибків струму та стабілізацію напруги, це вирішується установкою фільтрів (без встановлення ДБЖ);
• Рівень 2 - вимагає встановлення ДБЖ з байпасом із резервуванням N+1;
• Рівень 3 - необхідні паралельно працюючі ДБЖ, з резервуванням N + 1;
• Рівень 4 - системи ДБЖ, з резервуванням 2 (N+1).

Сьогодні на ринку найчастіше можна зустріти ЦОД з електроживленням другого рівня, рідше – третього (але в цьому випадку вартість розміщення зазвичай різко зростає, причому далеко не завжди обґрунтовано).

За нашими оцінками, дата-центр з повним резервуванням зазвичай обходиться в 2,5 рази дорожче за простий ЦОД, тому вкрай важливо ще на рівні передпроектної підготовки визначитися, якій категорії має відповідати майданчик. Як недооцінка, і переоцінка важливості параметра допустимого часу простою однаково негативно позначаються бюджеті підприємства. Адже фінансові втрати можливі в обох випадках - або простою і збоями в роботі критично важливих систем, або через викидання грошей на вітер.

Дуже важливо також простежити, як вестиметься облік споживання електрики.

Охолодження

Правильно організоване відведення тепла - не менш складне і важливе завдання. Дуже часто береться загальне тепловиділення залу і вже тому розраховується потужність претензійних кондиціонерів та їх кількість. Такий підхід, хоч і дуже часто зустрічається, не можна назвати правильним, оскільки він веде до додаткових витрат і втрат у ефективності систем охолодження. Помилки в розрахунках систем охолодження - найпоширеніші, і свідчення тому - служба експлуатації майже кожного ЦОД у Москві, що поливає літнім літнім днем ​​теплообмінники з пожежних шлангів.

На якість відведення тепла впливають такі моменти.

Архітектурні особливості будівлі.На жаль, не всі будівлі мають правильну прямокутну форму із постійною висотою стель. Перепади висоти, стіни та перегородки, конструктивні особливості будови та вплив сонячної радіації – все це може призвести до додаткових труднощів при охолодженні окремих ділянок ЦОД. Тому розрахунок систем охолодження має проводитися з урахуванням особливостей приміщення.

Висота стель та фальшпідлоги.Тут все дуже просто: якщо висотою фальшпідлоги справа не зіпсуєш, то надто високі стелі ведуть до застою гарячого повітря (отже, його треба відводити додатковими засобами), а надто низькі стелі ускладнюють рух гарячого повітря до кондиціонера. У разі низького фальшполу (> 500 мм) різко падає ефективність охолодження.

Показники температури та вологості повітря у ЦОД.Як правило, для нормальної роботи обладнання потрібно дотримуватись температурного режиму в діапазоні 18-25 градусів Цельсія та відносну вологість повітря від 45 до 60%. У цьому випадку ви убезпечите своє обладнання від зупинки через переохолодження, виходу з ладу у разі випадання конденсату при високій вологості, статичної електрики (у випадку з низькою вологістю) або через перегрівання.

Канали зв'язку

Здавалося б, така «незначна» складова, як канали зв'язку, не може викликати жодних труднощів. Саме тому на неї і не звертають уваги ні ті, хто орендує ЦОД, ні ті, хто його будує. Але що користь від бездоганної та безперебійної роботи ЦОД, якщо обладнання недоступне, тобто. його практично немає? Обов'язково зверніть увагу: ВОЛЗ мають повністю дублюватися, причому багаторазово. Під «дублюються» мається на увазі не тільки наявність двох волоконно-оптичних кабелів від різних операторів, але й те, що вони не повинні лежати в одному колекторі.

Важливо розуміти, що справді розвинена комунікаційна інфраструктура потребує значних разових витрат і не дешева в експлуатації. Слід розцінювати її як одну з вельми відчутних складових вартості ЦОД.

Власний ЦОД на «раз-два-три»

Тут варто зробити невеликий відступ та розповісти про альтернативний метод створення власного ЦОД. Йдеться про BlackBox - мобільний центр обробки даних, вбудований у транспортний контейнер. Простіше кажучи, BlackBox - це дата-центр, розміщений не в окремій кімнаті всередині приміщення, а в певному вигляді автотрейлера (див. малюнок).

BlackBox можна привести у повністю робочий стан протягом місяця, тобто. у 6-8 разів швидше, ніж традиційні ЦОД. При цьому не потрібно пристосовувати під BlackBox інфраструктуру будівлі компанії (створювати особливу систему протипожежної безпеки, охолодження, охорони тощо). А найголовніше – для нього не потрібно окремого приміщення (можна розмістити його на даху, у дворі…). Все, що дійсно необхідно – організувати подачу води для охолодження, систему безперебійного електроживлення та налагодити підключення до Інтернету.

Вартість власне BlackBox – близько півмільйона доларів. І тут треба зазначити, що BlackBox - це повністю налаштований (проте з можливістю кастомізації) віртуалізаційний центр обробки даних, розміщений у стандартному транспортному контейнері.

Дві компанії вже отримали контейнер для попереднього тестування. Це Linear Accelerator Center (Стенфорд, США) та... російська компанія «Мобільні ТелеСистеми». Найцікавіше, що МТС запустила BlackBox швидше за американців.

Загалом BlackBox справляє враження дуже добре продуманої та надійної конструкції, хоча, звичайно, варто згадати і її недоліки.

Необхідне зовнішнє джерело енергії мінімум у 300 Вт. Тут ми упираємося у будівництво або реконструкцію ТП, монтаж ГРЩ, прокладання кабельної траси. Це не так просто – проектні роботи, погодження та затвердження проекту у всіх інстанціях, монтаж обладнання…

ДБЖ у комплект постачання не входять. Знову упираємося в проектні роботи, вибір постачальника, обладнання приміщення під монтаж ДБЖ з кліматичною установкою (батареї дуже примхливі до температурного режиму).

Потрібна також покупка та монтаж ДГУ. Без нього не вирішити проблему з резервуванням, а це ще одне коло погоджень та дозволів (середній термін постачання таких агрегатів – від 6 до 8 місяців).

Охолодження - необхідне зовнішнє джерело холодної води. Доведеться спроектувати, замовити, дочекатися, змонтувати та запустити систему чилерів із резервуванням.

Резюме: ви по суті збудуєте невеликий дата-центр протягом півроку, але замість ангару (приміщення) купіть контейнер із серверами, причому збалансований і серйозно продуманий до дрібниць, з комплектом зручних опцій та ПЗ для управління всім цим господарством, та змонтуєте його за місяць .

Чим більше ЦОД, тим..?

На даний момент найбільший ЦОД, про який є інформація у відкритих джерелах, - об'єкт Microsoft в Ірландії, в який корпорація планує інвестувати понад 500 млн дол. Фахівці стверджують, що ці гроші будуть витрачені на створення першого в Європі обчислювального центру для підтримки різноманітних мережевих сервісів та програм Microsoft.

Будівництво у Дубліні конструкції загальною площею 51,09 тис. кв. м, на території якої розмістяться десятки тисяч серверів, розпочалося у серпні 2007 р. і має завершитися (за прогнозами самої компанії) у середині 2009 р.

На жаль, наявна інформація про проект мало що дає, адже важлива не площа, а енергоспоживання. Виходячи з цього параметра ми пропонуємо класифікувати ЦОД наступним чином.

• «Домашній ЦОД» – ЦОД рівня підприємства, якому потрібні серйозні обчислювальні потужності. Потужність – до 100 кВт, що дозволяє розмістити у ньому до 400 серверів.
• "Комерційний ЦОД". До цього класу належать операторські ЦОД, стійки у яких здаються у найм. Потужність – до 1500 кВт. Вміщує до 6500 серверів.
• "Інтернет-ЦОД" - ЦОД для Інтернет-компанії. Потужність – від 1,5 МВт, вміщує 6500 серверів та більше.

Візьму він сміливість припустити, що з будівництві ЦОД потужністю понад 15 МВт неминуче виникне «ефект масштабу». Помилка на 1,5-2 кВт у «сімейному» ЦОД на 40 кВт, швидше за все, залишиться непоміченою. Помилка розміром у мегават буде фатальною для бізнесу.

Крім того, можна з повною підставою припустити в цій ситуації дію закону спадної віддачі (як наслідок ефекту масштабу). Він проявляється у необхідності поєднання великих площ, величезної електричної потужності, близькості до основних транспортних магістралей та прокладання залізничних колій (це буде економічно доцільніше, ніж доставка величезної кількості вантажів автотранспортом). Вартість освоєння всього цього в перерахунку на 1 стійку або юніт буде серйозно вищою за середню з наступних причин: по-перше, відсутністю підведеної потужності в 10 МВт і більше в одній точці (доведеться штучно вирощувати такий «алмаз»); по-друге, необхідністю зводити будівлю або групу будівель, достатніх для розміщення ЦОД.

Але якщо раптом вдалося знайти потужність, скажімо, близько 5 МВт (а це вже велике везіння), із двома резервованими введеннями від різних підстанцій до будівлі, яка має правильну прямокутну форму з висотою стелі 5 м та загальною площею 3,5 тис. кв. м, та ще й у ньому немає перепадів висоти, стін та перегородок, а поряд є близько 500 кв. м прилеглої території ... Тоді, звичайно, можна досягти мінімальної собівартості за одну стійку, яких буде приблизно 650.

Цифри тут названі з розрахунку споживання 5 КВт на стійку, що є на сьогоднішній день стандартом «де факто», оскільки збільшення споживання у стійці невідворотно призведе до складнощів із відведенням тепла, а як наслідок – до серйозного збільшення собівартості рішення. Так само як і зменшення споживання не принесе необхідної економії, а лише збільшить орендну складову і вимагатиме освоєння більших площ, ніж це насправді потрібно (що теж сумно позначиться на бюджеті проекту).

Але не слід забувати, що головне - це відповідність ЦОД поставленим завданням. У кожному окремому випадку необхідно шукати баланс, спираючись на ті вступні дані, які ми маємо. Іншими словами, доведеться шукати компроміс між віддаленістю від основних магістралей та наявністю вільної електричної потужності, висотою стелі та площею приміщення, повним резервуванням та бюджетом проекту.

Де зводити?

Вважається, що ЦОД повинен розміщуватися в окремій будівлі, як правило, без вікон, оснащеному найсучаснішими системами відеоспостереження та контролю доступу. До будівлі має бути підведено два незалежні електричні введення (від двох різних підстанцій). Якщо ЦОД має кілька поверхів, то перекриття мають витримувати високі навантаження (від 1000 кг/кв. м). Внутрішня частина має бути розділена на герметичні відсіки з власним мікрокліматом (температурою 18-25 градусів Цельсія та вологістю 45-60%). Охолодження серверного обладнання має забезпечуватися за допомогою прецизійних систем кондиціонування, а резервування живлення - як пристроями безперебійного живлення, так і дизель-генераторними установками, які зазвичай знаходяться поруч із будинком та забезпечують у разі аварії функціонування всіх електричних систем ЦОД.

Особливу увагу слід приділити системі автоматичного пожежогасіння, яка зобов'язана, з одного боку, виключати помилкові спрацьовування, з другого - реагувати на найменші ознаки задимлення чи появи відкритого полум'я. Серйозний крок уперед у галузі пожежної безпеки ЦОД - застосування азотних систем пожежогасіння та створення пожежної атмосфери.

Мережева інфраструктура також має передбачати максимальне резервування всіх важливих вузлів.

Як заощаджувати?

Можна почати економити з якості харчування в ЦОД та закінчити економією на оздоблювальних матеріалах. Але якщо ви будуєте такий «бюджетний» ЦОД, це виглядає, принаймні, дивно. Який сенс інвестувати у ризикований проект та ставити під загрозу ядро ​​свого бізнесу?! Одним словом, економія потребує дуже виваженого підходу.

Проте є кілька вельми витратних статей бюджету, які оптимізувати не лише можна, а й потрібно.

1. Телекомунікаційні шафи (стійки).Встановлювати в ЦОД шафи, тобто стійки, де кожна має бічні стінки плюс задні та передні двері, не має жодного сенсу з трьох причин:

• вартість може відрізнятись на порядок;
• навантаження на перекриття вище загалом на 25-30%;
• охолодна здатність нижче (навіть з урахуванням установки перфорованих дверей).

2. СКС.Знов-таки немає жодного сенсу обплутувати весь ЦОД оптичними патчкордами і купувати найдорожчі і найпотужніші комутатори, якщо ви не маєте наміру встановлювати обладнання на всі стійки разом. У середньому термін заповнюваності комерційного ЦОД – півтора-два роки. За поточних темпів розвитку мікроелектроніки це ціла епоха. Та й усе розведення так чи інакше доведеться переробляти - або не розрахуєте необхідного обсягу портів, або в процесі експлуатації лінії зв'язку буде пошкоджено.

У жодному разі не будуйте «мідний» крос в одному місці – розоріться на кабелі. Набагато дешевше та грамотніше ставити поряд з кожним рядом телекомунікаційну стійку та розводити від неї на кожну стійку по 1-2 патч-панелі міддю. Якщо необхідно підключити стійку, то прокинути оптичний патч-корд до потрібного ряду - хвилинна справа. При цьому ще не знадобляться серйозні інвестиції на початковому етапі; нарешті, принагідно буде забезпечена необхідна масштабованість.

3. Живлення.Так, не повірите, але в харчуванні ЦОД найважливіше – ККД. Ретельно вибирайте електрообладнання та системи безперебійного живлення! Від 5 до 12% вартості володіння ЦОД можна заощадити на мінімізації втрат, таких як втрати на перетворенні (2-8%) в ДБЖ (у старих поколінь ДБЖ ККД нижче) та втрати при згладжуванні гармонійних спотворень фільтром гармонік (4–8%). Зменшити втрати можна за рахунок встановлення «компенсаторів реактивної потужності» та за рахунок скорочення довжини силової кабельної траси.

Висновок

Які ж висновки можна зробити? Як вибрати з усього різноманіття те рішення, яке підходить саме вам? Це, безумовно, складне та нетривіальне питання. Повторимося: у кожному конкретному випадку необхідно ретельно зважувати всі «за» та «проти», уникаючи безглуздих компромісів, - вчіться правильно оцінювати власні ризики.

З одного боку, при скороченні витрат одним із варіантів економії може стати аутсорсинг ІТ-послуг. І тут оптимальне використання комерційних ЦОД, з отриманням повного комплексу телекомунікаційних сервісів за відсутності інвестицій у будівництво. Проте для великих профільних компаній та банківського сектора з настанням періоду нестабільності та заморожування будівництва комерційних ЦОД гостро постає питання про будівництво власного дата-центру.

З іншого боку, кризові явища, які ми спостерігаємо протягом останнього року, сумно позначилися на економіці в цілому, але водночас є акселератором для розвитку успішніших компаній. Орендна плата за приміщення значно зменшилася. Спад ажіотажу навколо електричних потужностей звільнив місце найефективнішим споживачам. Виробники обладнання готові на безпрецедентні знижки, а робоча сила впала в ціні більш ніж на третину.

Одним словом, якщо ви планували будувати власний дата-центр, то зараз, на наш погляд, саме час.

До написання даного матеріалу про центри обробки даних ми підійшли нестандартно. З одного боку стаття носить інформаційно-пізнавальний характер, а з іншого - як приклад ми будемо наводити справжній московський - TEL Hosting.

Центр обробки даних (ЦОД) - високотехнологічна споруда для розміщення обчислювального обладнання. Спочатку ЦОДи використовувалися, переважно, для потреб підприємств і закупівельних організацій. Останнім часом цей термін набув широкого поширення у комерційній сфері, з огляду на зростання інтересу до послуг приватних ЦОДів та попиту на них серед клієнтів.

Послуги ЦОД

Центри обробки даних пропонують своїм клієнтам цілий комплекс телекомунікаційних послуг, пов'язаних із зберіганням та обробкою інформації. Крім стандартних рішень деякі ДЦ пропонують додаткові сервіси.

Стандартні послуги центрів обробки даних:

Додаткові послуги центрів обробки даних:

• Бекап
• Хмарні рішення
• Адміністративний сервер
• Видаленний робочий стіл

Технології, що застосовуються у ЦОДах

Високорозвинена технічна інфраструктура, що дозволяє підтримувати оптимальні умови для клієнтського обладнання – ключова характеристика сучасного дата-центру. ЦОД TEL є наочним прикладом такої споруди.

Детальна розповідь про технічну складову нашого дата-центру (за ним можна отримати загальне уявлення про ЦОД) викладена в корпоративному блозі на Хабрі.

Нині Москві функціонує понад 80 комерційних ЦОДов Висока конкуренція і близькість до каналів магістральних операторів роблять московські ціни найбільш конкурентоспроможними російському ринку. У регіонах Росії розцінки послуги центрів обробки даних у кілька разів вище, ніж у Москві.

Відмінності центрів обробки даних

Стандарт TIA-942

За цим стандартом всі ДЦ отримують певний рівень – від tier1 до tier4.

Дата-центр TEL формально відповідає стандарту tier2+.

Формат

За цим критерієм виділяють:

А) автономні центри обробки даних
б) дата-центри, що орендують площі у більших провайдерів
в) серверні, які зазвичай використовуються під потреби конкретного підприємства
г) "треш" дата-центри (що не мають належної інфраструктури).

ЦОД TEL Hosting знаходиться у власності телекомунікаційної компанії TEL і належить до споруд першого типу.

Стрімкий розвиток сучасних технологій призводить до неминучого зростання автоматизації більшості процесів як на підприємствах різного рівня, а й у побуті.

З підвищенням рівня технологій прискорюються процеси обміну даними між різними суб'єктами. З'являється необхідність у спеціальних автоматизованих центрах, де вся інформація буде надійно та впорядковано зберігатись та оброблятися.

Найкращим рішенням у цьому питанні є ЦОДи (центри обробки даних), які поступово стають невід'ємною частиною інфраструктури будь-якого підприємства.

Призначення та види ЦОД

Центри обробки даних – це складна система, яка включає цілий комплекс IT рішень, високотехнологічного обладнання та інженерних конструкцій.

Основне завдання ЦОД полягає у швидкій обробці будь-якого обсягу даних, зберіганні інформації та її видачі у стандартизованому вигляді користувачеві. Фактично ядром центру є потужні серверні станції, забезпечені необхідним програмним забезпеченням, системами охолодження та безпеки.

Існують два основні різновиди таких центрів:

• комерційного типу.Це цілі комплекси, які споруджують для подальшої оренди обчислювальних потужностей. Вони відрізняються високою продуктивністю та максимальною швидкістю обміну даними. Користувач, скориставшись такою послугою, отримує віртуальний ЦОД, який фактично може бути в іншому місті або навіть країні. Переваги такого варіанту очевидні – користувач може самостійно налаштувати конфігурацію системи за певними параметрами, управління відбувається дистанційно, не потрібно витрачати кошти на будівництво та обслуговування власного ЦОД;


• внутрішні (корпоративні).Центри, що встановлюються у межах конкретного підприємства. Вони призначені лише для внутрішнього корпоративного користування. Незважаючи на витрати, пов'язані зі створенням та введенням в експлуатацію такого центру, головна його перевага полягає у прямому управлінні всією системою. Компанія не залежить від стороннього власника обладнання (постачальника послуг) і зможе більш ефективно забезпечити безпеку даних та безпеку комерційної таємниці. У разі виходу з ладу певних систем процес їх відновлення пройде набагато швидше. Не слід забувати, що підприємство, яке має власний ЦОД, може забезпечити автономну роботу обладнання на випадок з перебоями в мережі електропостачання та максимально швидко реагувати на різні позаштатні ситуації.

Мобільний та модульні ЦОД

Окремо варто розглянути мобільний ЦОД, який є готовим рішенням для невеликих компаній. Переваги очевидні – не потрібно проектувати спеціальне приміщення для стаціонарного дата-центру, враховувати специфіку обладнання, температурний режим та інші фактори. Деякі виробники світового рівня зайнялися розробкою таких центрів та досягли великого успіху.

Конструктивно система є певною кількістю уніфікованих модулів, які легко об'єднуються у повноцінний автономний комплекс і швидко налаштовуються.

Модульний ЦОД – це найраціональніший і найпростіший спосіб для багатьох компаній середнього рівня. Ще одна перевага такого центру – на його створення та введення в експлуатацію йде значно менше часу, ніж на стаціонарну конструкцію.

Такі комплексні рішення набули широкого поширення на підприємствах різної сфери діяльності. Насамперед йдеться про організації та компанії, для яких ключовим полем діяльності є швидкий обмін даними. Це різні банківські системи, державні та комерційні телекомунікаційні організації, IT компанії, call-центри, аварійно-диспетчерські служби.

Правильно оброблена інформація, яка оперативно подана, грає першорядну роль роботі таких компаній. Важливим критерієм є також можливі втрати прибутку у разі неправильної або надто повільної обробки даних. Тож великих організацій такі центри забезпечуються новітнім технологічним устаткуванням і програмним забезпеченням.

Що важливо знати під час виборів ЦОД?

Від надійності та швидкості обробки інформації в багатьох компаніях залежить побудова робочого процесу та рівень надання послуг клієнтам.

Ключові вимоги до ЦОД такі:

• автономна робота;


• високий рівень надійності;


• захист даних;


• безвідмовність;


• висока продуктивність, незалежно від того, це буде хмарний ЦОД (віртуальний) або внутрішній корпоративний варіант;
• великий обсяг зберігання інформації;


• можливість розширення та модернізації (закладається на найближчі 5-7 років з урахуванням прогнозованого зростання компанії та розвитку технологій).

Центри обробки даних у Росії, що відповідає цим критеріям, – найкраще рішення для вітчизняних компаній профільної сфери діяльності. Для більшості замовників дуже важливим є сукупне співвідношення вимог до вартості.

Сьогодні Центри даних у РФ у зв'язку з кризою в економіці вже не настільки потрібні, як 10 років тому, і така тенденція простежується у всьому світі.

Великі компанії розуміють важливість таких центрів, але за виборі устаткування орієнтуються насамперед вартість, а чи не на новітні технології та розширені можливості.

Ключові елементи центрів даних

Структура центрів обробки даних включає цілий ряд компонентів і підсистем, без яких оперативна обробка інформації та зберігання даних неможливі.

Система включає наступні блоки:

• IT-інфраструктура ЦД;


• інженерні системи різного рівня складності;


• комплексний підхід до безпеки;


• управління та моніторинг.

Щоб докладніше розібратися у структурі, слід розглянути основні блоки уважніше.

ІТ складова ЦОД;

Перший блок є комплексом високотехнологічного обладнання, який об'єднаний у загальну систему.

Це своєрідне ядро ​​будь-якого сучасного ЦОДу, яке складається з:

• серверного обладнання;


• системи передачі, обробки та зберігання даних.

Щоб підвищити ефективність сервера, багато відомих компаній розробляють нові продукти: програмне забезпечення, технології віртуальної реальності та готові комплексні рішення на основі використання блейд-серверів. Це один із найбільш затребуваних напрямків у спеціалізованій IT сфері.

Нові розробки дозволяють суттєво збільшити продуктивність обладнання, покращити енергоефективність, зменшити витрати на утримання та максимально оптимізувати робочі процеси.

Інженерні рішення у ЦОД

Щоб забезпечити безперебійну роботу потужного високотехнологічного обладнання необхідно створити ефективну інженерну систему.

Основні інженерні системи ЦОД належать до двох категорій:

• електропостачання.Спеціальне обладнання має забезпечувати не лише безперебійне подання електрики до обладнання, але й у разі аварій на ЛЕП перейти на автономне живлення. Для здійснення цього використовують різні джерела безперебійного живлення та додаткові генератори. Дуже важливо, щоб напруга та частота струму відповідали необхідним параметрам і в мережі не було перебоїв та різких стрибків. Такі перепади негативно впливають на серверне обладнання і можуть призвести до його виходу з експлуатації;


• охолодження.Потужні сервери під час роботи виділяють безліч тепла, яке відводиться за допомогою спеціальних вбудованих радіаторів. Не вирішує проблему цілком, оскільки серверні станції перебувають у окремих закритих приміщеннях. Щоб забезпечити надійне охолодження, використовують різні системи кондиціювання, які працюють в автоматичному режимі, забезпечуючи оптимальну температуру у приміщенні та перешкоджаючи перегріву обладнання. Використовуючи нові технології в області кондиціонування (інверторні компресори, високоточні теплові датчики), можна домогтися зменшення витрат електроенергії, що споживається, на 10-15%.

Безпека центрів обробки даних

Одна з найважливіших складових працездатності будь-якого ЦОДу – це правильно розроблена система безпеки. Для того щоб забезпечити збереження даних та запобігти доступу до них сторонніх осіб через Інтернет, компанії використовують новітнє антивірусне ПЗ та інші програми захисту даних.

Щоб запобігти проникненню сторонніх осіб, розробляється та впроваджується система допуску певної категорії працівників, методи протидії злому та фізичному проникненню до обладнання, відеоспостереження, протипожежна система. Комплексний підхід до безпеки забезпечує збереження важливої ​​інформації.

Моніторинг ЦОД

Комплексний підхід до управління та моніторингу є важливою складовою будь-якого сучасного ЦОДу. Такі системи в автоматичному режимі контролюють працездатність всього обладнання та параметри навколишнього середовища (температура, вологість, напруга та частота струму).

Невід'ємною частиною моніторингу є системи прогнозування можливої ​​відмови обладнання та раннього оповіщення.

Окреме місце займає диспетчеризація – це важлива складова робочого процесу, яка дозволяє організувати інформування персоналу про позаштатну ситуацію за допомогою сучасних технологій зв'язку (надсилання даних на електронну адресу, можливість автоматичного дозвону абонентам певної групи або короткі СМС повідомлення).

Комплексний підхід суттєво знижує ризик виникнення аварійних ситуацій, а у разі настання форс-мажору забезпечує максимально ефективну методику боротьби та відновлення пошкоджених ділянок системи.

Центри обробки даних на виставці

На території ЦВК «Експоцентр» пройде важливий захід – виставка «Зв'язок». Велика експозиція буде присвячена питанням оперативної обробки даних та безпечного зберігання інформації. Ця подія міжнародного рівня, де провідні світові виробники спеціалізованого обладнання та програмного забезпечення продемонструють свої останні розробки у цій сфері.

Усі бажаючі можуть дізнатися найактуальніші новини про ЦОД, ознайомитись із системами проектування, новими мобільними та стаціонарними комплексами.

Окрема увага буде приділена безпеці та необхідному обладнанню для забезпечення охолодження, вентиляції та безперебійного електропостачання центрів обробки даних. Це важлива подія для всіх фахівців у даній галузі та керівників компаній, які хочуть модернізувати своє підприємство, використовуючи сучасні технології та новітнє обладнання для зберігання, передачі та обробки даних.