Коли ЦОД (центр обробки даних) стає потребою. Що таке Дата-центр і навіщо він такий потрібен? Де знаходиться цод

/ ЦОД: будувати чи орендувати?

Вконтакте

Однокласники

Михайло Поляков, заступник генерального директора «ІНСІСТЕМС» (група компаній ланіт)

ЦОД: будувати чи орендувати?

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

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

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

Напрямок бізнесу та його масштаби

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

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

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

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

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

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

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

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

Наразі слід задуматися саме про оренду послуг ЦОД. У зв'язку з розвитком віртуалізації та хмарних технологій оренда серверного обладнання (dedicated server) та розміщення власних серверіву наданих стійках (colocation) – лише частина послуг, зазвичай наданих ЦОД. Крім перелічених, ЦОД надають послуги IaaS (Infrastructure as a Service), SaaS (Software as a Service) та PaaS (Platform as a Service).

Останнім часом розвиток хмарних технологій викликало появу навіть такого поняття як XaaS (Anything as a Service), тобто можливість надання будь-яких послуг через Інтернет. Все це не лише розширює список споживачів послуг ЦОДу, а й створює нові типи провайдерів цих послуг. У свою чергу провайдери послуг ЦОД вищого рівня одночасно є споживачами послуг нижчого рівня. Наприклад, провайдер SaaS може бути споживачем IaaS, colocation або dedicated server. Важливим суб'єктивним моментом, що впливає на вибір рішення про власний ЦОД або оренду, може стати й поінформованість споживача про послуги, які йому пропонують.

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

Зростання на тлі нестабільності

У 2014 році російський ринок дата-центрів зріс майже на 30% і склав 11900000000 руб. (9,3 млрд. у 2013 році).

Такі дані наводяться у дослідженні компанії iKS-Consulting "Російський ринок комерційних дата-центрів 2014-2018", опублікованому в грудні 2014 року. Одним із ключових факторів зростання ринку стало введення нових потужностей ЦОД у РФ. У 2014-му площа машинних залів збільшилася на 17,5 тис. кв.м, а кількість стійок – на 3,5 тис. Таким чином, на кінець 2014 року сумарна площа машинних залів комерційних ЦОД у РФ досягне 86 тис. кв.м. (зріст 36,5%), стійок – 25,5 тис. (зріст 28%) (див. рис. 1).

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

За даними річного звіту «Російський ринок центрів обробки даних 2014» РБК.Research, прибутковість від послуг ЦОД у 2014-му зросла у 60% компаній, знизилася у 10%, залишилася на колишньому рівні у 30% компаній, у той час як у 2013 року збільшення показника прибутковості відзначили 71% гравців ринку.

Підвищення енергоефективності ЦОД на понад 5% у 2013 році відзначили 71% опитаних компаній, у 2014-му – вже 78%. У решти учасників дослідження цей показник залишився на колишньому рівні.

Кордон мінімальної вартості послуги ЦОД у 2014 році збільшився у 11% учасників дослідження. При цьому у 78% компаній цей показник залишився на рівні минулого року.

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

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

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

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

• Проблеми, що з'являються на етапах проектування, будівництва та експлуатації ЦОД, а також можливі рішенняцих проблем
• Наводяться рекомендації щодо використання сучасних стандартів, а також дається коротка їх характеристика
• Наводяться основні помилки при проектуванні, і проблеми, що з'являються при експлуатації, показуються їх наслідки, а також можливі шляхиусунення помилок та вирішення проблем
• Окремо наводяться правила створення успішних 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. Аналіз представленого фірмами матеріалу та уточнення питань при особистих зустрічах.

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

Міжнародний магістральний оператор зв'язку

Один із ключових постачальників послуг міжнародної передачі даних.
Надання послуг IP-транзиту та виділених каналів зв'язку міжнародним та локальним Інтернет-провайдерам.
Організація віртуальних приватних мереж (VPN), доступу до Інтернету та інших послуг зв'язку для великих та середніх підприємств з різних галузей промисловості; банківських структур та фінансових інститутів, а також державних організацій
Широке покриття мережі - 28 країн, 3 континенти - і значну присутність у Східній Європі та Росії.
Висока пропускна спроможність мережі, якою проходять великі обсяги міжнародного трафіку.
Висока зв'язність за рахунок прямих підключень до численних ЦОДів та міжнародних точок обміну трафіком.

Найбільший інтернет-провайдер Москви

Широка зона покриття – близько 70 районів для корпоративних клієнтів та 27 районів для фізичних осіб.
Інноваційні технології — постійно вдосконалює якість своїх послуг, збільшуючи потужність серверів та пропускних здібностейканалів, сміливо впроваджуючи інноваційні технології, надаючи своїм абонентам користуватися новими можливостями для роботи, відпочинку, спілкування та розвитку.
Starlink дбає про своїх абонентів, надаючи їм Інтернет нового покоління. Компанія перша в Росії стала активно підключати своїх користувачів до Мережі, використовуючи IPv6 - протокол нового покоління.

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

Що це?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На відміну від бази даних

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

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

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

Види

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

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

Цілі

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

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

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

Що таке дата-центр при обробці особистих відомостей?

Сервер

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

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

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

Як сервіс

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

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

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

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

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

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

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

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

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

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

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

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

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