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

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

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

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

Мал. Центр обробки даних: принципова схема


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

Сервери та мережеве обладнання: ресурсні сервери, сервери додатків, сервери подання інформації.

Система інофрмаціонной безпеки: антивірусний захист, спам-фільтр, захист від вторгнень.

Яким компаніям необхідний ЦОД

Для зростаючого бізнесу рано чи пізно стають характерними:

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

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

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

Мал. Яким компаніям необхідний ЦОД


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

ПОТРЕБИ В ЦОД ПО ГАЛУЗЯМ

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

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

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


джерело: IT Manager

Переваги впровадження ЦОД

На відміну від децентралізованого підходу до організації ІТ-інфраструктури компанії, наявність ЦОД економить фінанси і підвищує:

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

Крім того, ЦОД забезпечує можливості:

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

Корпоративні та хостингові ЦОД

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


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


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

Основний і резервний ЦОД

Основний ЦОД- ядро \u200b\u200bінформаційної та телекомунікаційної системи. Він приймає на себе все навантаження в штатному режимі.


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

Місце ЦОД в ІТ-інфраструктурі компанії

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

ЦОД забезпечує:

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

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

За даними Meta Group, фінансові витрати в разі відмови систем і устаткування становлять:

  • $ 6,5 млн на годину в разі відмови систем, що забезпечують брокерські операції
  • $ 2,6 млн на годину в разі відмови систем авторизації кредитних карт
  • $ 14,500 за годину в разі відмови банкомату
  • $ 330 000 в середньому витрати за годину простою дата-центру.

АНОНСИ

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

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

Відмінність від бази даних

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

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

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

види

Центри обробки даних бувають двох видів.

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

цілі

Крім безперервної роботи обладнання, центр обробки даних повинен дозволяти:

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

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

Що таке дата центр при обробці анкетних даних?

сервер

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

Крім того, важливими функціями Цода як сервера вважають:

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

як сервіс

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

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

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

Завдяки вищевказаним чинникам, ЦОД як сервіс можна вважати високоефективним і надійним, що має отказоустойчивую інфраструктуру.

Що таке повідомлення про місце знаходження і як вказати адресу?

Компанія повинна направити, в якому необхідно вказати відомості про місце знаходження бази даних інформації, що містить громадян Російської Федерації (Відповідно до зміни 152-Ф3 від 21.07.2014 N 242-Ф3).

Направити документ в структуру можна як на папері, так і в електронному вигляді. Обов'язкова підпис уповноваженої особи. У повідомленні має міститися такі відомості:

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

Заповнення останнього пункту повинно містити відомості про місцезнаходження БД інформації з персональними даними громадян РФ. Необхідно вказати країну та точну адресу Цода, якщо він локальний, або надати відомості про власника центру, якщо він комерційний. У другому випадку потрібно надати наступну інформацію:

  1. тип організації (фізична або юридична особа, індивідуальний підприємець або іноземна організація);
  2. організаційно-правова форма;
  3. найменування організації;
  4. свідоцтво про Державну;
  5. країна і адресу місцезнаходження організації.

Важливо! Вказувати необхідно місця зберігання персональних даних громадян РФ і тільки.

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

Чи не знайшли відповіді на своє питання? Дізнайтеся, як вирішити саме Вашу проблему - зателефонуйте прямо зараз:

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

Що це?

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

Де вони можуть застосовуватися?

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

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

Коли використовується ЦОД?

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

Серверні кімнати і їх особливості

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

Чим відрізняється ЦОД від серверної?

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

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

Де використовується таке обладнання?

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

Також одним з перших великих Цодов стало обладнання, яке використовувалося в центрі Ощадбанку. У 2003 році, за підтримки компанії «Ростелеком», в Чувашії організували перший республіканський центр обробки даних, що застосовується для того, щоб систематизувати архівні дані. Такі пристрої забезпечували різні органи місцевої влади, а в 2006 році також відкрився центр, в якому здійснювалася обробка даних центру «Курчатовський інститут». У наступному році компанії ВТБ-24 і Yandex також почали використовувати власний центр обробки даних. Москва, таким чином, досить швидко прийшла до використання такого обладнання, так само як і інші великі міста Росії.

Де варто встановити ЦОД?

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

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

Запорука успішності ЦОД - це грамотне проектування

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

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

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

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

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

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

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

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

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

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

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

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

Якщо звернутися до Вікіпедіїто ЦОДабо центр зберігання і обробки даних (ЦОД/ЦХОД) - це спеціалізоване будівлю для розміщення (хостингу) серверного та комунікаційного обладнання і підключення абонентів до каналів мережі Інтернет. Інша назва ЦОД - Дата центр (Від англ. 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) ЦОД. але цифрове їх вираження для різних рівнів не коректно, Тому що розкид показників відмовостійкості у ЦОД одного рівня може бути великий. У відповідному місці документа буде показано, що всі цифри характеризують період простою у різних рівнів ЦОД від лукавого і реально спиратися на них не можна. Якщо говорити коротко, то перелік найбільш характерних рис різних рівнів ЦОД можна звести в просту таблицю.

Клас ЦОД (рівень)
Найбільш характерна риса Базовий уровеньнізкая відмовостійкість З резервуванням З можливістю паралельного проведення профілактичних робіт висока відмовостійкість
Схильний до порушень нормального ходу роботи як від планових, так і від позапланових дій. Він має системи розподілу електропітаніяі охолодження комп'ютерів, але може мати або не мати фальшполов, ДБЖ або генератора. Якщо навіть є ДБЖ або генератори, то вони являють собою Одномодульні системи і мають багато одиночних точок відмови. Щорічно інфраструктуру доводиться повністю вимикати для виконання робіт по планово-предупредітельномуобслужіванію і профілактичному ремонту. Термінова необхідність може зажадати більш частих відключень. Помилки при експлуатації або мимовільні відмови компонентів інфраструктури об'єкта будуть викликати перерви нормального ходу роботи дата-центру. Є надлишкові компоненти, дещо менше подверженнарушеніям нормального ходу роботи від планових і від позапланових дій, ніж базовий дата-центр. В даному випадку, є фальшпол, ІБП і генератори, однакопроект має оцінку N + 1 (Need plus One), що означає однопотоковий шлях розподілу по всій площі. Технічне обслуговування та ремонт критичного шляху електропостачання та інших елементів інфраструктури об'єкта потребують зупинки процесу обробки даних. Дозволяє здійснювати будь-яку планову діяльність інфраструктури об'єкта без будь-якого порушення нормального ходу роботи технічних засобів машинного залу. До планової діяльності відноситься профілактичне іпрограмміруемое технічне обслуговування, ремонт і заміна компонентів, додавання або видалення компонентів, що впливають на продуктивність, тестування компонентів і систем та ін. Необхідно мати в наявності достатню потужність і розподільні можливості, щоб одночасно нестінагрузку на одному шляху і в той же час виконувати ремонт або тестування на іншому шляху. Позапланові дії, наприклад помилки при експлуатації або мимовільні відмови компонентів інфраструктури об'єкта, все ж будуть викликати перерви нормального ходу роботи дата-центру. Об'єкти Рівня III часто проектують з перспективою нарощування ресурсів до Рівня IV. Має кілька активних шляхів розподілу електроживлення іохлажденія. Забезпечує підвищену ступінь відмовостійкості через наявність 2-х путей.Обеспечівает кілька шляхів підведення електроживлення до всемвідам обчислювального і телекомунікаційного устаткування. Вимагає, щоб все комп'ютерне та телекомунікаційне обладнання мало кілька силових входів. Устаткування продовжує функціонувати, коли один силових входів отключён.Предусматрівается можливість і здатність інфраструктури об'єкта дозволяти будь-яку планову діяльність без порушення нормального ходу роботи критично важливою навантаження. Відмовостійка функціональність також забезпечує здатність інфраструктури дата-центру витримати принаймні один позаплановий відмову (або подія) найгіршого властивості без наслідків для критично важливою навантаження. Має в наявності двох окремих систем ДБЖ, в яких кожна система має резервування N + 1.
Тип компанії-споживача ресурсів Середній та малий бізнес. ЦОД для обслуговування внутрішніх процесів компанії Середній та малий бізнес. ЦОД функціонує в режимі "5х8" Компанії, які обслуговують як внутрішніх, так і зовнішніх замовників в режимі «7х24» Глобальні компанії, що надають свої послуги в режимі «24 × 365»
Тип будівлі C сусідами окремо розташована
кількість енерговводов 1 Один активний, другий резервний два активних

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

Доступність,%
(% UP TIME)

Час простою в рік, годину.
(DOWNTIMEв рік), годину

Рішення, що забезпечують надійність
Без резервування, генератора, і резервного введення
Без резервування, генератора, але є резервний ввід
З частковим «холодним» резервуванням, без генератора але є резервний ввід
З «гарячим» резервуванням найбільш важливих частин і «холодним» практично всього іншого, наявність генератора і резервного введення
З «гарячим» резервуванням найбільш важливих частин і «холодним» практично всього іншого, з генератором в «гарячому» резерві і резервному вводі в «гарячому» резерві.
99,999 5,26 хв. Повний резервування за все, завжди наявність 2-х шляхів (зв'язків) часто з дублюванням.

Запис виду «Без резервування» не говорить про те, що в разі виходу зі строю буде очікуватися замовлення і отримання від постачальника відмовив блоку. Наявність прорахованих запасів ЗІП і зниження значення показника 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 так само не дуже багато. забезпечують повне виконання вимог для 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).

Параметр / Клас
ЦОД (рівень)

1
низька відмовостійкість

4
висока відмовостійкість
Тип будівлі C сусідами З сусідами окремо розташована окремо розташована
кількість енерговводов 1 1 Один активний,
другий резервний		 два активних
Початкова потужність Вт на м 2 215 - 323 430 - 537 430 — 645 537 - 860
Максимальна потужність Вт на м 2 215 - 323 430 - 537 1075- 1615 1615+
безперебійне кондиціонування немає немає можливо є
Висота фальшпідлоги в метрах 0.3 0.45 0.75 - 0.9 0.75 - 0.9
415 488 732 732+
(По Страндарт 2005р 1000+)
Загальна тривалість відмов за рік 28,8 ч 22 ч 1,6 ч 0,4 ч
доступність ЦОД 99,671 % 99,749 % 99,982 % 99,995%
Термін введення в експлуатацію (міс.) 3 3 - 6 15 - 20 15 - 20
Типовий проект вперше реалізований в 1965 р 1970 р 1985 р 1995 р

Загальний висновок про візуальні стандарти:

  • Основоположним варто вважати використання стандарту 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. Аналіз поданого фірмами матеріалу і уточнення питань при особистих зустрічах.

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

»

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

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

Революція відбулася в 90-х роках, після поширення клієнт-серверної моделі. Ті комп'ютери, які стали вважати серверами, почали розміщувати в окремих приміщеннях з підготовленою інфраструктурою. Назви цих приміщень англійською звучали як Computer room, Server room, Data Center, в той час як в Радянському Союзі ми називали їх «Машина залами» або «обчислювальний центр». Після розпаду СРСР і популяризації англійської термінології наші ВЦ перетворилися в «серверні» і «Центри Обробки Даних» (ЦОД). Чи є принципові відмінності між цими поняттями, або це всього лише питання термінології?

Перше, що спадає на думку, це масштаб: якщо маленька, то серверна, а якщо великий - то ЦОД. Або: якщо всередині тільки свої сервера, то це серверна; а якщо надаються послуги розміщення серверів стороннім компаніям - то дата-центр. Чи так це? За відповіддю звернемося до стандартів.

Стандарти та критерії

Найпоширеніший в даний час стандарт, що описує пристрій дата-центрів, це американський TIA 942. Російського аналога, на жаль, немає, радянський СН 512-78 давно і безнадійно застарів (хоч і була редакція від 2000), його можна розглядати тільки з точки зору загальних підходів.

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

Отже, стандарт TIA 942 класифікує 4 рівня (TIERs) ЦОД і називає ряд параметрів, за якими можна провести цю класифікацію. Для прикладу я вирішив перевірити, чи є моя серверна, побудована разом з заводом три роки тому, справжнім дата-центром.

Як невеликого відступу вкажу, що завод займається виготовленням штампованих деталей для автомобільної промисловості. Ми випускаємо кузовні деталі для таких компаній, як Ford і GM. Підприємство само по собі невелике (загальний штат близько 150 чоловік), але з дуже високим рівнем автоматизації: число роботів можна порівняти з кількістю робітників у цеху. Основною відмінністю нашого виробництва можна назвати ритм роботи Just-In-Time, тобто ми не можемо собі дозволити затримку, в тому числі з вини ІТ-систем. ІТ є критичними для бізнесу.

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

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

Основні параметри класифікації ЦОД

Стандарт встановлює критерії двох категорій - обов'язкові та рекомендовані. Обов'язкові позначаються словом «повинні» (shall), рекомендовані - словами «слід», «можуть», «бажано» (should, may, desirable).
Перший і найважливіший критерій - рівень експлуатаційної готовності. Згідно TIA 942, ЦОД вищого - четвертого - рівня повинен володіти 99,995% готовності (тобто не більше 15 хв простою в рік). Далі, по низхідній, 99,982%, 99,749% і 99,671% для першого рівня, що відповідає вже 28 ч простою в рік. Критерії досить жорсткі, проте що з себе представляє експлуатаційна готовність ЦОД? Тут вважається тільки простий всього ЦОД з вини однієї з систем життєзабезпечення, і простий окремих серверів на експлуатаційну готовність ЦОД не впливає. А раз так, то найімовірнішою причиною відмови справедливо вважати перебої в системі енергопостачання.

В нашій серверної встановлений потужний ДБЖ APC з резервуванням N + 1 і додатковим шафою батарей, який здатний підтримувати працездатність не тільки серверів, але і всіх комп'ютерів на підприємстві до 7 ч (а навіщо нам працюють сервера, якщо до них нікому підключатися). За три роки експлуатації збоїв ні разу не було, так що за цим параметром ми можемо претендувати на найвищий TIER 4.

До слова про енергопостачанні, третій і четвертий класи ЦОД вимагають другого енерговвода. У нас його немає, так що максимум - другий клас. Ще стандарт класифікує споживання потужності на квадратний метр площі. Дивний параметр, ніколи про це не замислювався. Померял: у мене 6 кВт на 20 м кв., Тобто 300 Вт на квадратний метр (тільки перший рівень). Хоча можливо, що я неправильно вважаю: в стандарті зазначено, що хороший ЦОД повинен мати вільні площі для масштабування. Тобто виходить, чим більше «запас масштабування», тим нижче рівень Цода, а повинно бути навпаки. Тут у нас найнижча оцінка, але все ж стандарту відповідаємо.

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

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

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

Окрема частина присвячена фальш-полам. Стандарт регламентує і висоту, і навантаження на них. Причому, чим вище клас датацентру, тим вище і потужніше повинні бути фальш-підлоги. У нас вони є, і по висоті і навантажень відповідають другому класу ЦОД. Але моя думка, що наявність фальш-підлог не повинно бути критерієм, а тим більше характеристикою Цода. Я був в датацентрі компанії «ВестКолл», де від фальш-підлог вони спочатку відмовилися, розмістивши всі лотки під стелею. Кондиціонування зроблено з холодними і гарячими коридорами. Будівля отдельностоящєє, приміщення велике, надають специфічні послуги. Тобто хороший, «справжній» ЦОД, а виходить, що без фальш-підлог формально стандарту не відповідає.
наступний важливий момент - система безпеки. Великі дата-центри охороняються майже як сейфи в банку, і потрапити туди - ціла процедура, починаючи від узгодження на різних рівнях і закінчуючи перевдяганням і бахилами. У нас з цим простіше, але все присутнє: фізичну охорону забезпечує ЧОП, який охороняє і сам завод, а система контролю доступу гарантує, що в приміщення потрапляють тільки авторизовані співробітники. Ставимо плюсик.

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

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

Знайшов я таки параметр, за яким моя серверна на ЦОД не тягне: розмір вхідних дверей. За стандартом має бути мінімум 1,0 × 2,13 м, а краще 1,2 × 2,13 м. А у нас двері звичайна: 0,9 × 2,0 м. Це мінус, але вважати критерієм відмінності Цода від серверної розмір вхідних дверей - це несерйозно.

Майже справжній ЦОД!

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

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

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