Що таке ЦОД на реальному прикладі? Як побудувати власний цод Коли використовується ЦОД

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

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

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

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

Типи дата-центрів

Всі дата-центри можна умовно поділити на кілька типів:

1. Великі дата-центри мають свою будівлю, спеціально сконструйовану для забезпечення найкращих умов розміщення. Зазвичай вони мають канали зв'язку, яких підключають сервери.
2. Середні дата-центри зазвичай орендують майданчик певного розміру та канали певної ширини (ширина каналу вимірюється його пропускною здатністю Mbps).
3. Дрібні дата-центри розміщуються у непристосованих приміщеннях. У загальних випадках використовується обладнання поганої якості, а також надається мінімум послуг.

Структура та опис дата-центру

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

Деякі дата-центри пропонують клієнтам додаткові послуги з використання обладнання з автоматичного уникнення різних видів атак. Команди кваліфікованих фахівців цілодобово проводять моніторинг усіх серверів. Необхідно відзначити, що послуги датацентрів дуже відрізняються в ціні та кількості послуг. Для збереження даних використовуються резервні системи копіювання. Для запобігання крадіжці даних у дата-центрах використовуються різні системи обмеження фізичного доступу, системи відеоспостереження. У корпоративних (відомчих) дата-центрах зазвичай зосереджено більшість серверів відповідної організації. Обладнання кріпиться у спеціалізованих стійках. Як правило, в дата-центр приймають для розміщення лише обладнання стійковомувиконанні, тобто в корпусах стандартних розмірів, пристосованих для кріплення у стійку. Комп'ютери в корпусах настільного виконання не зручні для дата-центрів і розміщуються у них рідко. Датацентр являє собою кімнату, поверх або цілу будівлю, які зазвичай розташовані в межах або в безпосередній близькості від вузла зв'язку або точки присутності будь-якого одного або декількох операторів. Системи електроживлення, вентиляції та пожежогасіння дата-центру відрізняються підвищеною надійністю та резервуванням. Зрозуміло, має бути передбачений фізичний захист та особливий режим допуску до технологічних приміщень. У деяких країнах є спеціальні стандарти на обладнання приміщень датацентрів. У Росії поки такого стандарту немає, дата-центри оснащуються відповідно до вимог споруд зв'язку. Існує американський (ANSI) стандарт TIA-942, що несе у собі рекомендації щодо створення дата-центрів, і ділить дата-центри на типи за ступенем надійності. Фактично TIA-942 сприймається у всьому світі як єдиний стандарт для дата-центрів.

Послуги дата-центрів

1. Віртуальний хостинг. Надання лімітованої частини дискового місця, процесорного часу, оперативної пам'яті для використання клієнту. Великі датацентри зазвичай не надають подібну масову послугу через необхідність забезпечення технічно-консультаційної підтримки. При використанні віртуального хостингу один фізичний сервер ділиться між безліччю клієнтів (сотні чи тисячі). Кожному клієнту не гарантується виділення ресурсу, але суворо лімітується максимальне. Клієнти не можуть більшою мірою конфігурувати сервер. Віртуальний хостинг має дві основні переваги: ​​малу вартість та легкість управління сайтами. З цих причин віртуальний хостинг переважно використовують приватні особи.
2. VDS)-хостинг - Надання гарантованої та лімітованої частини сервера (частини всіх ресурсів). Важлива особливість цього виду хостингу - поділ сервера на кілька віртуальних незалежних серверів, що реалізуються програмним способом.
3. хостинг – Оренда сервера (Dedicated). Дата-центр надає клієнту в оренду сервер різної конфігурації. Великі дата-центри переважно спеціалізуються саме на подібних типах послуг. Залежно від країни розташування дата-центру, є різні обмеження на трафік.
4. Розміщення сервера (Colocation). Розміщення сервера клієнта на майданчику датацентру за певну плату. Вартість залежить від енергоспоживання і тепловиділення обладнання, що розміщується, пропускної спроможності підключається до обладнання каналу передачі даних, а також розміру і ваги стійки.
5. Виділена зона (Dedicated area). У деяких випадках власники дата-центру виділяють частину технологічних площ для спеціальних клієнтів, як правило, фінансових компаній, які мають суворі норми безпеки. У цьому випадку дата-центр надає певну виділену зону, забезпечену каналами зв'язку, електропостачанням, холодопостачанням та системами безпеки, а клієнт сам створює свій ЦОД усередині цього простору.

Мережева інфраструктура

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

Деякі сервери в дата-центрі служать для роботи базових інтернет та інтранет служб, які використовуються всередині організації: поштові сервери, проксі, DNS тощо.

Мережевий рівень безпеки підтримують: міжмережеві екрани, IDS-системи тощо. Також використовуються системи моніторингу трафіку та деяких програм.

Примітки

Посилання

• Опис та фотографії одного з дата-центрів компанії Яндекс
• Project Blackbox (рус.), SUN.com (англ.)
• Колекція корисних нормативів з будівництва та експлуатації дата-центрів
• Аркуш російських топ-гравців бізнесу комерційних дата-центрів

Див. також

Wikimedia Foundation. 2010 .

Дивитись що таке "Центр обробки даних" в інших словниках:

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

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

модульний центр обробки даних (ЦОД)- [Інтент] Паралельні тексти EN UA Data Centers є hot topic these days. No… … Довідник технічного перекладача

Зв'язати? Підземний центр обробки даних розташований у парку Грізінькалнс у Ризі (Латвія), і належить оператору … Вікіпедія

- (мобільний ЦОД) або контейнерний центр обробки даних (контейнерний ЦОД) (від англ. Container Data Center), центр обробки даних, розміщений у спеціалізованому транспортному контейнері з розміщеним усередині нього комплексом інформаційної ... Вікіпедія

динамічний центр обробки даних- Динамічні центри обробки даних – це концепція апаратної та програмної архітектури нового покоління. Її основні принципи – надання сервісів для кінцевих користувачів та гарантоване виконання угод про рівень… Довідник технічного перекладача

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

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

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

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

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

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

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

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

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

Що це?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Види

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

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

Цілі

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

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

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

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

Сервер

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

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

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

Як сервіс

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

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

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

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

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

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

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

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

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

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

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

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

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