Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 615 сообщений
Cообщения с меткой

цод - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Повесть «НИИЧОСИ. S.A.Day»

Воскресенье, 14 Августа 2016 г. 20:06 (ссылка)

image


Опубликовав повесть «НИИЧОСИ. Дежурная ночь», решил не останавливаться. Я все так же продолжаю работать в крупной IT-компании дежурным админом. В дневных дежурствах родилось продолжение повести.



НИИЧОСИ. S.A.Day

(System Administrator Day – День Системного Администратора)



— Да отстань уже! — кот настырно тыкался своей мордой мне в лицо. Будильник ещё не прозвонил. Я приоткрыл один глаз. На часах было 6:55. Вот зараза! Я мог еще пять минут находиться в спящем режиме. Увидев мой приоткрытый глаз кот, прибавил к своим активным действиям еще и звуковые сигналы.

— Да чтоб тебя! — еще секунда и черная пушистая кричащая масса оказалась на полу. Я встал и направился в ванную. Кот Байт (или Байт кот) следовал за мной, не упуская из вида. По дороге я убрал пару бит из его лотка. В ванной, посмотрев на себя в зеркало, я с гордостью расчесал свою трехсантиметровую сисадминскую бороду. Уже больше года я работаю дежурным в НИИЧОСИ (Научно-Исследовательский Институт Частных Объектов Систем Информации) в отделе администрирования ЦОДа. Похоже, мой опыт растет вместе с бородой, пожалуй, не буду ее сбри…

— Мяу, мя… кх, пхе. — кажется, кот охрип и теперь начал издавать звуки похожие на коннект dial-up модема.

— Сейчас, сейчас. Подожди ты. — я насыпал ему корма. Странные звуки, исходившие от кота, затихли и он приконнектился к миске. Я тоже перекусил на скорую руку, оделся и двинул на работу.



Сегодня была последняя пятница июля. Сегодня был день Системного Администратора. Сегодня я снова был дежурным.

Так получалось за прошедший год, что мне постоянно выпадали дежурства на праздники. Новый год, 23 февраля, 8 марта, 1 и 9 мая и вот сегодня. Бывалые админы из нашего отдела говорят, этот день всегда проходит гладко и на расслабоне. Ничего серьезного никогда не планируется. Окрыленный чувством беззаботности я зашел в НИИЧОСИ. Поздоровался с охранником. Странно, что-то уж больно парадно он одет — неужели в честь праздника? Я посмотрел на часы, у меня было еще полчаса до начала дежурства. Решил забежать в отдел техподдержки к моему другу Павлу. Познакомились мы с ним в ту роковую новогоднюю ночь, когда у меня было первое боевое ночное дежурство. Тогда он неудачно начал праздновать Новый год. К счастью, удар током не нанес серьезных повреждений, скорее наоборот — легкая картавость прошла без следа, а вставшие колом волосы так ему понравились, что Пашка решил сделать себе ирокез и ходит с ним, по сей день.

Я нашел его в комнате отдыха на пятом этаже.

— Привет. Почему не за «станком»? — спросил я Павла, наливающего себе кофе.

— Здорово, Сань! Да вот в сон клонит, я же с ночной. Еще полчаса и все. На минутку оторвался. И клиент какой-то нервный с утра пошел. Вроде пятница… Ну, пошли ко мне.

Мы добрались до его рабочего места. Павел сел, надел гарнитуру и отметил готовность к приему звонков в системе. Стол его был совсем узкий, там помещался только монитор, клавиатура и мышь. Справа и слева его отделяли стенки от других столов, за которыми так же находились рабочие места сотрудников техподдержки. За его монитором висел тот злополучный «трофейный» сетевой фильтр со следами его зубов на проводе.

— О, смотри, точнее, слушай, как я с ним разберусь! — в наушниках Павла раздавался звонок входящего вызова. — НИИЧОСИ, техподдержка Павел, слушаю. Здравствуйте. Да. Да. Нет. Не сможете. Я могу еще чем то помочь? Хорошо. И вас так же. И вас туда же. До свидания.

Павел нажал кнопку завершения вызова.

— М-да. Я говорил какие-то они нервные. Ну ладно, со следующим точно повезет. А вот и звонок. НИИЧОСИ, техподдержка Павел, слушаю. Да откуда мне знать есть ли в вашем городе покемоны? Давайте я лучше…

Я не стал ему мешать и отправился на свое рабочее место. К тому же скоро уже заступать на дежурство. Только я дошел до лифта, как у меня в кармане зажужжал телефон.

— Где тебя носит? – голос начальника был не по-детски суров. – Ты мне это брось, почему еще не на месте?

Хм, я прям, словил чувство дежавю. Немного напряглись нервы при воспоминании о том ночном дежурстве.

— Евгений Палыч, сейчас буду, уже спускаюсь!



Я спустился на второй этаж и подошел к стеклянной двери нашего кабинета. Что-то подозрительно. Наш отдел был почти в полном составе. Неужели все собрались к празднику? Антон — он сегодня дежурил ночью, и я его должен был сменить — сидел за своим компом, положив голову на руки. Да, он уже работает здесь более десяти лет, и в качестве бонуса ему позволено на дежурствах подремать десять минут. Миха, Макс и Мозг расположились возле стола Евгения Павловича и что-то обсуждали. Даже сисадмины Костя, Потап и Кирилл сидели неподалеку и усердно «препарировали» какой-то сервак.

Я зашел в кабинет. На звук пикнувшей от моего пропуска двери, все (кроме ночного дежурного) синхронно повернули голову и уставились на меня. Мне стало не по себе…

— А вот и наш дежурный пришел. До начала твоего дежурства есть еще пять минут. Проведем небольшую планерку. Садись. — Евгений Павлович указал на свободный стул у его стола. — Костя, Потап, Кирилл тоже давайте сюда.

Сисадмины дружно подхватили распотрошённый ими сервак, подтащили поближе и продолжили свое дело.

— Во-первых, поздравляю, коллеги, с праздником. Во-вторых, собственно, почему я вас всех собрал. К нам едет…

Его слова прервал легкий храп ночного дежурного.

— Антон, а у тебя сервак упал! — слегка крикнул Макс. Дежурный резко поднял голову и начал судорожно вглядываться в окно системы мониторинга.

— Да ну вас. Все нормально работает. О, Саша, привет. Давай, принимай дежурство. Спать хочется.

У него снова начали слипаться глаза.

— Так, Антон! Тебе еще пять минут дежурить, потерпи. — Евгений Павлович укоризненно посмотрел на дежурного. — Так вот, к нам сегодня приедет проверка. Как вы знаете, а кто не знает — минус ему за не любознательность — у нас есть крупный инвестор из Китая. В свое время они прилично вложились в создание нашего НИИЧОСИ. Зачем им это — не понятно. Доход с нашей организации для них небольшой. Но кто их поймет. И сегодня приезжает представитель из их компании «Ху Ва Пин» инженер Ли Хуа.

— Ага, не буди Ли Хуа, пока оно тихуа! — подал голос Потап не отрываясь от ковыряния в материнке сервака.

— Да и все слова названия их компании какие-то не законченные… — поддержал его Костя.

— А ну-ка, прекратить разговорчики. Тут все серьезно. Он хоть вас и не поймет — по-русски он вообще не говорит, но к счастью с ним будет переводчик. Переводчик наш — русский, юмор понимает. А теперь, собственно переходим к причине его приезда. Появились у них идея проверить, все ли корректно у нас работает. Если в результате проверки их инженер уедет с положительным отчетом и настроением — то все хорошо. Если ему что-то не понравится, он находит какие-то недочеты — то ВСЕХ НАС УВОЛЬНЯЮТ, НАХРЕН, И ПРИСЫЛАЮТ СЮДА СВОИХ СОТРУДНИКОВ НА ОБСЛУЖИВАНИЕ ЦОДА!!! — было заметно, как нервничает Евгений Павлович. Да, похоже, все было очень даже серьезно.

— Сегодня ночью Борис Михалыч собрал экстренное совещание по этому поводу. Было решено: сегодня выходим полным составом. С утра подчищаем все косячки в системе. Проверка начнется с нашего отдела, потом этот китаец плавно переключится на программистов. На всякий случай Роберта Михайловича, от греха подальше, отправили в срочную «командировку». В Норильск, предположим. Большинство программистов отправили в отпуск на пару дней. Оставили только самых «пряморуких». Так что Александр — на тебе образцовое дежурство. В случае даже самых мелких проблем — поднимаешь всех. Все остальные исправляем косяки, проверяем актуальность документации и прочее, прочее, прочее… Костя, Потап, Кирилл подключайте Мозг, эээ, то есть Антона, и разберитесь уже с этими двадцатью красными триггерами в мониторинге, к приезду проверки.

— Но Евгений Павлович! Откуда же мы возьмем еще места для разделов, да и десяток боевых серваков всегда плющит от нагрузки — это их нормальное состояние в рабочее время!?

— Значит, задачи поставлены, решайте. Я на совещание! — сказал Евгений Павлович и ушел. В кабинете повисла тишина. Только слышно было шум компов и попискивание бесперебойника где-то за стенкой.

— Вот хитрый! Нам разгребать, а сам по совещаниям разным бегает. Знаем мы эти совещания. В свой праздник и не отдохнуть по нормальному! — возмутился Костя.

— Вот блин! Походу сейчас уже батарея сдохнет на бесперебойнике. А к нему подсоединены тестовые стенды. Ща как вырубится всё — разрабы взвоют. — сказал Потап и рванул к себе в кабинет.

— А почему бесперебойник сработал? Вроде электричество не отключалось? — спросил я.

— Да он тестит, сколько эта батарея продержится при такой нагрузке. Странно конечно, но ему вчера скучно совсем было. — пояснил Кирилл.

— Эй, дежурный. Давай уже дежурство принимай! — сонный Антон уже собирался к выходу.



Я сел за свой рабочий комп. Отписался в общем чате, что дежурство принял. Антон со спокойной душой «уполз» из офиса. Сейчас было спокойно. Все работало исправно, только на сервисе корпоративных сообщений были какие-то очереди. Я посмотрел в админке — по этой проблеме уже Антон писал разработчикам, где доступно и популярно объяснил им, откуда у них растут руки и какие параметры должны быть в настройках задержки отправки. Те обещали исправить в следующем билде.

В кабинете витал легкий запах кофе. Все были чем-то заняты. Костя с Кириллом продолжали ковырять сервак, почему-то у нас в кабинете. Что-то у них не получалось впихнуть в новую материнку.

— Кость, что ковыряете-то? Для чего будет эта железяка? — спросил я.

— Да есть идея у нас, на время проверки пристроить эту фуфлыжку вместо…

Его слова прервал звонок рабочего телефона на моем столе.

— НИИЧОСИ, дежурный администратор Александр, слушаю. — как всегда по правилам ответил я.

— Здравствуйте. Это Ольга Борисовна, ваш главный бухгалтер. Вы не знаете где наши доблестные системные администраторы? У них никто не берет трубку, дозвонилась только вам. А вопрос жизни или смерти… их зарплаты!

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

— Мне сейчас никак не оторваться. Спроси, что там у нее. Опять наверно своими кривыми руками, куда-то не туда полезла. Вечно с ней проблемы! — ответил Костя, вытирая пот со лба своими, измазанными в термопасте руками и оставляя на лице полосы боевой сисадминской раскраски.

— Ольга Борисовна. Константин подойти сейчас не может, но спрашивает: что у вас случилось? Он с радостью вам поможет!

— Знаете, Александр, как-то случайно сами удалились данные о зарплате отдела администрирования. Я не знаю, что мне делать! Константин как-то говорил, что у них есть какие-то «капы» и они могут вернуть все.

— Наверно он имел в виду бэкапы. Сейчас я уточню у него! — мне снова пришлось отключать микрофон. – Слушай, Костя, походу эта курица потерла из базы всю инфу о зарплате нашего отдела. Говорит, чтобы вы бросили все, разбились в лепешку, но развернули старый бэкап и вернули все!

Костя разразился такими эпитетами в адрес главбуха, умело сочетая матерные слова с описанием общей физиологии, что даже, казалось-бы всезнающий, Мозг (Антон) что-то записал себе в блокнот.

— Хорошо, что у нас бэкапы утренние. Скажи этой ***, что если она еще раз сунет *** в *** базу я буду долго и медленно… — кажется, у Кости закончилась фантазия. Он почесал планкой оперативы в затылке и продолжил. — Короче пусть все там, в бухгалтерии, выходят из *** 1С-ки, и если еще раз хоть одна…

Наш старший сисадмин скрылся у себя в кабинете, нервно бурча что-то себе под нос.

— Ольга Борисовна, Константин просил передать вам, что сейчас все сделает в лучшем виде, только всем бухгалтерам нужно выйти из 1С, он будет восстанавливать информацию. Удачного вам дня.

Я положил трубку. Я молодец. Сегодня праздник, а в этот день не надо злиться на пользователей. Тем более если это касается зарплаты.

Еще час пролетел незаметно. За это время я успел прочитать пару глав из книги «Изучаем Python » периодически поглядывая на окно мониторинга. Кирилл, бросив ковыряния с серваком, сел за чей-то комп. Ему явно не хотелось возвращаться к себе в кабинет, там Костя периодически громко выкрикивая нецензурные слова, разворачивал бэкап и явно мог его привлечь к этой работе. Я задумался: интересно, если бы можно было делать бэкап жизни, то наверно не осталось бы врачей? Типа заболел – опа, и откатил на вчерашний день здоровье, пока еще не кашлял.

Мои размышления снова прервал телефонный звонок.

— Алло, это Александр? — я снова узнал голос Ольги Борисовны. — Вы знаете, я тут отчет создавала и вдруг все зависло. Я перезагрузила компьютер и меня теперь не пускает в 1С.

— Стоп, Ольга Борисовна. Так я же говорил, что всем нужно выйти из 1С, сейчас Костя восстанавливает данные.

— Так все и вышли. А я не могу, мне там надо отчеты доделать!

У меня сами по себе руки сжались в кулаки, и я услышал скрежет своих стиснутых зубов. Спокойно, спокойно. Сегодня праздник, зачем нам проблемы? Я отключил микрофон.

— Кирилл, пожалуйста, перехвати звонок. Это из бухгалтерии. А то я боюсь, что начну давать советы, которые навредят здоровью наших пользователей…

— Эх, вот так всегда! Только одно дело начнешь и нате вам. — Кирилл ушел к себе в кабинет и через пару минут в моем телефоне зазвучали короткие гудки — он перевел вызов на свой телефон.

Я с облегчением положил трубку. Да, это вам не ночью дежурить. Днем можно на других такие задачи спихнуть. Интересно, как можно оставаться таким спокойным с такими-то пользователями? Железные нервы.



Только я собрался дойти до комнаты отдыха, чтобы налить себе чая, как сквозь прозрачную дверь из кабинета заметил приближающуюся делегацию. Через пару минут к нам в кабинет вошел Евгений Павлович с ним был наш гендиректор, а так же парень лет двадцати пяти (ну понятно — переводчик) и, собственно, сам китаец-проверяющий. На вид ему было лет пятьдесят, хоть он и был одет достаточно молодежно, но его седоватая голова выдавала в нем бывалого инженера. В руках он держал увесистый пакетик с нарисованными иероглифами и каким-то знакомым логотипом.

— А это, так сказать, мозг нашего НИИ. Отдел администрирования ЦОДа. — сказал Борис Михайлович, пропуская инженера Ли вперед. — Здесь круглосуточно дежурят наши сотрудники, следят за всеми сервисами и серверами, используя разработанную нами систему мониторинга.

Парень что-то прощебетал китайцу и тот радостно закивал.

— Сейчас дежурит наш самый молодой сотрудник Александр. Евгений Павлович, вы продолжайте, а я пойду. Дела. — сказал наш генеральный и практически исчез из кабинета.

Наш руководитель заметно волновался и явно хотел, чтобы проверка поскорее свалила из нашего отдела.

— В общем, про этот отдел Борис Михайлович вам уже рассказывал, давайте пройдем в кабинет системных администраторов, и вы начнете проверку? — предложил Евгений Павлович и быстрым шагом двинулся к соседнему кабинету. За ним «хвостом» рванули наши гости.

Проходя мимо меня, он яростным шепотом прошипел:

— Какого хрена триггеры красные еще висят. Быстро зови Костю, и делайте что-то с этим — это не должно попасть в его отчет!

— Костя занят сейчас, он пляшет вокруг бухгалтерского бэкапа! Сейчас Потапа позову, он вроде свободный.

Я быстренько звякнул Потапу, тот особо и не был против свалить оттуда, так как к ним направлялась проверка.

— Короче мы тут с этим вопросом еще с утра ковырялись. Это все бухгалтерия сбила! — Потап потирал руки от нетерпения. — Мы собрали сервачок. Сейчас я туда линуху накачу, подниму систему мониторинга в тестовом режиме, но со всеми теми же триггерами, пусть они зеленым все горят. Ты переключайся на фейковую страницу и типа мониторь ее. А сам периодически все же поглядывай на реальную картину, вдруг там что…

— Фига вы хитрые, а если он проверит?

— Да ты думаешь, он поймет, как там все работает? Я-то половины понять не могу, как это наши разрабы сделали, более того они сами уже не понимают! Работает и все тут. Magic! Вот только это когда-то был сервак из тестового стенда и на нем постоянно работал Столлов. Когда-то он что-то запустил на нем, сервак крякнул, пыхнул и больше не оживал. Вот сегодня с утра мы искали, в чем проблема. В общем, все норм теперь. Ща систему накачу.

Потап схватил чей-то монитор с соседнего стола, дернул клаву и мышь и пошел настраивать фейк-сервак. Сделал это он мастерски минут за двадцать.

— Все, давай заходи на страницу fig-proverka.niichosi.

— Слушай, а может хотя бы убрать «фиг» из адреса, а то палевно как-то?

— Эх, нет в тебе чувства авантюризма. Проверяй, давай!

Я открыл эту страничку, и передо мной открылась идеальная картина системы мониторинга, ни одного красного триггера. Статусы всех серваков подсвечивались приятным зеленым цветом.

— О, вообще круто! Всегда бы так. Все, давай этот сервак прячь где-нибудь.

— Да, где его спрячешь? Он конечно не большой, но у нас тут места не так и много.

— А давай в тумбочку к Палычу? Он туда все равно ничего не убирает и места хватит. На ключ закроем. Он вроде не сильно гудит, да и там никто проверять не будет.

— Хм, идея конечно. Только не сгорит ли он там? Ну, да и пофиг — сгорит еще раз — снова оживим и назовем Фениксом.

Потап пошел к столу нашего руководителя, отрыл тумбочку и начал работы по «ныканью» сервака. Только он закончил в кабинет зашел Евгений Павлович из кабинета админов. Я едва успел переключить окно мониторинга на фейковую страницу. Он мельком пробежался взглядом по моему монитору, и на лице расплылась нервная улыбка.

— О, да неужели сделали! Уже третье поколение наших сисадминов и программистов не могли решить проблему нагрузки на этих серваках! Как сделали?

— Знаете, Евгений Павлович, — начал Потап. — наше поколение самое прогрессивное. Уровень интеллекта самых молодых сотрудников ит отдела, во много раз превосходит все поколения…

— Короче они пока «запилили» временный сервак с фейковой системой мониторинга.- прервал я Потапа. Он с досадой зыркнул на меня.

— Халтурщики! Сервак-то сам где?

— Его мы спрятали в самом надежном месте, у вас в столе.

— Хм, идея неожиданная. Ладно, на время проверки прокатит, но чтобы потом взялись за это дело! У нас тут проблема нарисовалась пострашнее. Китаец привез с собой какую-то софтину. Сейчас они с Костей ставят ее, она соберет инфу со всех компов, начиная от железной начинки и заканчивая списком всего ПО. Если учитывать, сколько у программеров стоит левого ПО. Да и вас, охламонов, взять: у вас у каждого контра стоит, в которую вы по ночам шпиляете. Знаю я всё! Но сейчас не об этом. После такой статистики о софте нам тут точно не продержаться. Есть одно но! Сейчас вы будете ржать. Этот «инженер» для сбора инфы привез килограмм дискет!

— Эээ. А их еще используют? — удивился Миха.

— Я последний раз флопик видел пять лет назад! — подал голос Мозг.

— Не поверите, он привез свой, переносной, USB-шный. Админы там, в шоке, но молодцы, вида не подают. Короче пока они там инфу на дискеты заливают, давайте думать, как выкручиваться?

Макс, до этого момента остававшийся молчаливым, выдвинул ящик своего стола и вытащил оттуда магнитик с логотипом нашего НИИЧОСИ. Повернулся к нам и с улыбкой сказал:

— А давайте ему подарок сделаем на память. У меня еще три таких есть.

Все немного помолчали в замешательстве. Затем Евгений Павлович хмыкнул и сказал:

— Это диверсия, блин! Но в нашем положении это выход. Проследи, чтобы все три попали ему в пакет с дискетами.

— Будет сделано! — с радостью откликнулся Потап, схватил сувениры и рванул на помощь к админам.

Через пару минут из их кабинета прилетел Кирилл. Был он запыхавшийся хоть, и бежать ему было всего десять метров. Левый глаз его немного подергивался.

— Евгений Палыч, они уже заканчивают заливку инфы на дискеты, там половина размагниченных оказалось. Но это еще не вся беда! Во-первых, переводчик не может объяснить проверяющему, почему Костя периодически ржать начинает. И во-вторых, этот Ли сообщил, что хочет проверить автоматизацию наших систем на примере перехода на резервный интернет-канал! А мы еще не доделали, вот буквально вчера собирались тестить.

— Твою дивизию! — наш руководитель был в ярости. – Прошло уже больше полугода как вы эту проблему мусолите! То есть показывать там нечего? Сейчас тестировать уже поздно. Костю сюда быстро, а ты иди ему на замену. С дискетами-то уж справишься?

Кирилл убежал к своим. Прошло минут пять, и вошел улыбающийся Костя.

— Палыч, не психуй! Все норм. Ща я в серверную сбегаю. Вы как будете проверять переход на резервный канал, так я вручную провода переткну, он вообще ничего не заметит. Вы только звякните мне, когда начнется. И это… — Костя немного наморщил лоб и почесал затылок. — Там в серверной, короче, мы с парнями на прошлой неделе серваки двигали. Ну не по фен-шую они стояли. Мы их выставили в кружок, они так работают лучше, им так веселее и видно друг друга. Боюсь, нашему Хуа, это нихуа не понравится. Так что мне бы парней минут на десять, мы все поправим.

Евгений Павлович сидел у себя за столом, молча смотрел на Костю и нервно крутил ключ от тумбочки, где посвистывал своими кулерами фейк-сервак.

— Ну я вижу ты не против. — обрадовался сисадмин. — Миха, Макс пошли, поможете не умственно, а физически. Мозг — ты же мозг, подежурь за Саню немного. Он тоже поможет.

Мы вчетвером дружно двинули в серверную.

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

— Так, Макс, Миха вы вон ту стойку двигайте, там поболе серваков будет. — начал командовать Костя. — Я вот эту сдвину. А ты, Саня, вон ту подвинь на место, как раньше была, там всего один одноюнитовый — сдвинешь.

И правда это была самая новая стойка. Ее еще не успели заполнить. Я взялся поудобнее и начал пятиться вместе со стойкой к месту, где она раньше стояла. Это было совсем не сложно. Но нужно было делать аккуратно. Я уже почти дотащил ее до нужного места, как моя правая нога за что-то зацепилась, и я, от неожиданности, повалился на спину. Отпустить стойку я не успел, и она полетела на меня сверху.

— Ух, блин! — хотел вскрикнуть я, но стойка лежала серваком прямо у меня на груди, поэтому крика не получилось, а вырвалось какое-то шипение.

— Упс. Кажется, у нас сервак упал! — услышал я возглас Макса из другого конца серверной.

Вот ведь ирония! Сервак упал… на сисадмина. В моей голове пронеслась мысль: «Наверно, это самый почетный конец жизни сисадмина. Умер от упавшего сервака»!

Перед моими глазами начали проноситься сотни строк кода написанных скриптов. Я почти перестал слышать шум серваков в серверной и возгласы парней спешащих на помощь. Сервак сдавливал грудь все сильнее и сильнее. Воздуха почти не осталось. Я закрыл глаза и…



Я открыл глаза и увидел, что на груди у меня лежит мой кот Байт.

— Мяу! — обрадованно вскочил он, увидев, что я проснулся.

Я посмотрел на стену. На часах было 6:55. Начиналась последняя пятница июля. Сегодня день Системного Администратора! Сегодня я дежурный.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307710/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Когда стоит задуматься об оптимизации ИТ-инфраструктуры?

Среда, 10 Августа 2016 г. 17:10 (ссылка)

image

Думать об оптимизации никогда не рано и не поздно. Даже самая современная IT-инфраструктура уже завтра может не справиться со всеми возложенными на неё задачами. К тому же, оптимизация – это далеко не всегда приобретение новых активов, это в том числе и перевод части сервисов в публичные облака, и оптимизация IT-процессов, и тонкая настройка производительности существующих компонентов.



Задачи оптимизации



Главная задача оптимизации – обеспечение качественной и непрерывной работы бизнес-процессов с минимальными затратами на поддержку IT-инфраструктуры. Однако хотелось бы провести декомпозицию данной цели, чтобы можно было понять, за счёт чего могут быть достигнуты требуемые результаты.

Прежде всего, IT-инфраструктуру модернизируют для решения четырёх основных задач:



• непрерывность обслуживания;

• наращивание производительности (вычислительных мощностей);

• снижение стоимости поддержки;

• обеспечение информационной безопасности компании.



Данные задачи решаются за счёт достаточно широкого набора методов, которые можно условно объединить в группы:



image



Однако, прежде чем перейти к более детальному анализу вышеуказанных подходов, необходимо сделать одно важное замечание.



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

Возможно, с точки зрения именно Вашего бизнеса и именно Ваших реалий, какие-то компоненты имеет смысл оставить неизменными, просто приняв риски возможного выхода их из строя на некоторое время. Обычно такой подход используют в отношении различного «поддерживающего» оборудования и программного обеспечения, у которых даже относительно длительные простои (вплоть до нескольких дней) не принесут каких-либо значимых потерь для основного бизнеса.



Зачем нужно обследование?



На рисунке ниже изображена классическая схема зависимости бизнес-процессов от IT-инфраструктуры.



image

Как вы можете видеть, прямой зависимости нет, поскольку автоматизируются бизнес-процессы за счёт различных программных управляющих комплексов (например, различные ERP-, CRM-системы). А вот уже сами программные комплексы зависят от существующей инфраструктуры напрямую.



Для одной системы наиболее критичными могут являться, к примеру, сети передачи данных, для другой – количество выделенных виртуальному серверу объёмов памяти и дискового пространства, для третьей – не столько объёмы выделенной памяти, сколько её быстродействие.



То есть для каждой автоматизированной системы механизм зависимости от используемого «железа» будет свой. Поэтому в первую очередь ключевой задачей оптимизации IT-инфраструктуры является понимание существующих взаимосвязей между конкретными компонентами вычислительных систем и обслуживаемых ими бизнес-приложений.



Прекрасно, когда эти взаимосвязи известны и постоянно поддерживаются в актуальном состоянии, но в большинстве случаев ситуация всё-таки далека от идеала. Часто решения об автоматизации того или иного бизнес-процесса принимаются в разное время и разными людьми, причём, как правило, при этом не проводится никакого анализа (или проводится минимальный) на соответствие существующей IT-инфраструктуры новым требованиям.



В конкретный момент времени может стоять задача по оптимизации производительности какой-то одной из используемых автоматизированных систем и, соответственно, будут предъявляться повышенные требования только к некоторым компонентам вычислительных мощностей предприятия.

Теперь, когда мы выяснили основные взаимосвязи и наметили пути для максимально эффективной оптимизации, давайте вернёмся к обсуждению подходов, позволяющих добиться поставленных перед нами задач.



Подходы для решения задач оптимизации ИТ-инфраструктуры



Отказоустойчивость



Поддержание непрерывности работы всех автоматизированных бизнес-процессов, а значит, выход из строя какого-либо компонента IT-инфраструктуры не должен приводить к их деградации или же полной остановке. Это, в свою очередь, значит, что в IT-инфраструктуре не должно присутствовать единичных точек отказа (англ. SPOF – Single Point Of Failure).



image

В большинстве случаев отказоустойчивость достигается за счёт избыточности. Мы, по сути, дублируем какой-то компонент запасным на случай выхода из строя основного, а значит, требуются дополнительные капитальные затраты на приобретение нового оборудования (или на расширение функционала оборудования существующего за счёт приобретения лицензий с расширенной работоспособностью).



Таким образом, решать задачи повышения отказоустойчивости каждого компонента необходимо исходя из критичности их воздействия на работу автоматизированных систем и, соответственно, самих бизнес-процессов.



Если, к примеру, львиная доля ваших продаж совершается через web-сайт, расположенный на вашей собственной вычислительной площадке, а соединение с сетью Интернет у вас не зарезервировано, то неполадки на линии приведут к серьёзным потерям для вашего бизнеса, следовательно, повышение отказоустойчивости интернет-соединения будет являться для вас высокоприоритетной задачей.



Если же ваш сайт носит исключительно информативный характер, на нём не завязаны никакие финансовые операции, а электронная корреспонденция не предполагает необходимости мгновенного ответа на входящие письма, необходимость создания резервной линии в Интернет выглядит весьма сомнительной. И даже если в будущем вы планируете использовать глобальные сети более полно, на текущий момент тратить ресурсы на создание избыточности в данной точке не требуется.



Катастрофоустойчивость



Часто бывает так, что отказоустойчивой инфраструктуры недостаточно для непрерывной работы бизнеса. Если, к примеру, ваш основной вычислительный кластер расположен в сейсмоопасном регионе, а построенный на нём программно-аппаратный комплекс управляет географически распределённым производством, то сам ЦОД (центр обработки данных) целиком становится единичной точкой отказа.



Таким образом, у вас появляется необходимость в создании резервной площадки, которая, в случае форс-мажора на первичном объекте, замкнёт на себя все необходимые бизнес-процессы.



image

Создание запасного ЦОДа всегда связано с серьёзными вложениями и высокими операционными расходами, поэтому необходимо чётко понимать, насколько данные инвестиции будут соизмеримы с возможными потерями, связанными с простоем в работе программно-аппаратного комплекса (ПАК) на основном объекте. По этой причине в качестве резервного ЦОДа очень часто используются арендованные вычислительные мощности специализированных сервис-провайдеров, а реально защищаются от возможных катастроф только самые необходимые сервисы и приложения.



Виртуализация IT-инфраструктуры



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



image

И если ранее распределение задач по серверам могло быть весьма дорогостоящим (выделение отдельного физического сервера под каждую задачу), то с помощью технологий виртуализации эта проблема решается гораздо легче и изящнее. Современное серверное оборудование позволяет запустить десятки (а иногда и сотни) виртуальных машин с достаточной производительностью для работы каких-либо не слишком ресурсоёмких приложений (контроллеры доменов, WSUS, серверы мониторинговых систем и т.д.). Помимо уменьшения стоимости наращивания требуемых вычислительных ресурсов, технологии виртуализации обладают ещё целым рядом преимуществ:



• повышение отказоустойчивости и катастрофоустойчивости;

• изоляция служб;

• возможность гибкого распределения ресурсов между службами;

• использование операционных систем, которые наилучшим образом подходят для решения конкретных задач;

• экономия места в стойках;

• снижение энергопотребления и тепловыделения;

• упрощение администрирования;

• широкие возможности по автоматизации развертывания и управления серверами;

• снижение вынужденных и запланированных простоев системы за счет failover-кластеров и live migration.



Организация «частных облаков»



Дальнейшим развитием технологий виртуализации является концепция «частного облака» (англ. Private Cloud), когда серверы объединяются в пул, из которого на решение определённых задач выделяются вычислительные ресурсы, не привязанные к конкретным физическим серверам. Такие облака строятся на базе ЦОДа компании, что позволяет сделать IT-услуги ещё более «эластичными», при этом, в отличие от использования публичных облачных сервисов, остаются полностью закрытыми все вопросы безопасности и соблюдения конфиденциальности данных, расположенных в частных облаках.



image

Гибридная IT-инфраструктура



Можно по-прежнему полагаться на собственную инфраструктуру, однако ресурсы на базе публичных облаков становятся более привлекательными вне зависимости от того, кто их предоставляет. Перенос части вычислительных мощностей в «облако» или расширение локальных мощностей за счёт ресурсов «облачных» провайдеров перестало быть чем-то экзотическим и в настоящее время является совершенно стандартной практикой.



image

Главным преимуществом данного подхода является возможность сэкономить (причём иногда весьма существенно) на развитии собственной IT-инфраструктуры.



В современных реалиях порой бывает очень сложно спрогнозировать реально необходимое количество ресурсов, особенно, если ваш бизнес подчинён некоторым сезонным пикам активности. С одной стороны, можно докупить необходимое количество оборудования и покрыть все потребности собственными ресурсами, но, с другой стороны, Вы будете вынуждены отдавать себе отчёт в том, что некоторые из ваших ресурсов будут простаивать большую часть времени (от пика до пика), создавая тем самым дополнительную финансовую нагрузку на денежные потоки компании.



Использование же ресурсов публичного облака позволяет платить за так необходимые вам ресурсы исключительно по факту их реального использования, как, например, вы платите за воду или электроэнергию у себя в квартире.



Классическим примером удачного использования ресурсов публичного облака является, например, аренда дополнительных вычислительных мощностей компанией-ритейлером в период предновогодней потребительской суеты. Или, другой пример, – вместо покупки собственных вычислительных мощностей для организации antispam-решения можно воспользоваться уже готовым облачным сервисом.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307542/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Снижение эксплуатационных расходов ЦОД

Четверг, 21 Июля 2016 г. 19:03 (ссылка)

Владельцы серверных ферм заинтересованы в снижении расходов, связанных с эксплуатацией дата-центров. Они вкладывают деньги в развитие технологий, в системы электропитания, жидкостного охлаждения серверов, ИБП и тому подобного. В тоже время существуют менее дорогостоящие способы снизить затраты, связанные с использованием инфраструктуры ЦОД.



В статье описаны решения Microsoft и Minkels, при помощи которых компаниям удалось снизить эксплуатационные расходы дата-центров.







В Microsoft снижают расходы с помощью усовершенствования ОС



Специалисты компании Microsoft совместно с сотрудниками Австралийского национального университета (The Australian National University, ANU) провели исследование. В результате чего они пришли к выводу, что с помощью оптимизации механизма, через который серверные операционные системы используют простаивающие ресурсы вычислительных систем, можно снизить эксплуатационные расходы ЦОД на целых на 25%.



По мнению специалистов, очень сложно предугадать активность пользователей. Из-за чего интернет-компании пытаются ввести в эксплуатацию максимальное количество серверного оборудования, обычно простаивающего. С подобной проблемой можно справиться с помощью технологии «одновременная многопоточность». Правда большинство компаний сознательно исключает эту функцию. Причина заключается в том, что для эффективного использования данной технологии необходим именно тот подход, который был применен в исследовательском проекте. В противном случае «одновременная многопоточность» замедляет интерактивные сервисы, такие как предоставление результатов поиска в ответ на запрос пользователя и т.д.







Команда Microsoft доработала свою операционную систему ЦОД. В результате чего ОС изменила порядок обработки поисковых запросов — она начала расставлять приоритеты. В периоды самой высокой активности пользователей, система откладывала наименее важные задачи на более благоприятное время. Когда же нагрузка на серверы существенно снижалась, ОС снова брала их в работу.



Светодиодные лампы от Minkels



Нидерландская компания Minkels, которая занимается разработкой технологических решений для ЦОД, выпустила серию настенных светодиодных LED-ламп. Они созданы непосредственно под потребности дата-центров в инфраструктуре которых для изоляции воздушных потоков используются горячие и/или холодные коридоры. Лампы совместимы с различными решениями (включая Minkels Next Generation Corridors и Minkels Free Standing Corridors).







Специалисты компании выполнили модель в соответствии с европейским стандартом EN12464-1, с учетом всех основных требований дата-центров. LED-ламп имеют подходящие размеры для размещения в типичных горячих и холодных коридорах помещений ЦОД. У светодиодных ламп достаточно высокая яркость — до 335 LUX (оптимальный уровень видимости будет обеспечен даже в темных коридорах с черными стойками). Кроме того их можно дополнить инфракрасными датчиками движения, которые поспособствуют дальнейшей экономии электроэнергии. LED-лампы автоматически гаснут, когда человек покидает коридор. Также с помощью датчиков получится повысить безопасность оборудования в машзалах ЦОД.



LED-лампы укомплектованы надежными креплениями. Монтирование и установка светодиодных ламп Minkels не вызывает сложностей благодаря магнитным системам.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306160/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Новая инциатива Tropical Data Center (TDC)

Суббота, 16 Июля 2016 г. 16:13 (ссылка)

Город-государство на юго-востоке Азии — Сингапур в переводе с малайского означает «город льва», часто его называют «Диснейлэнд для взрослых», «Город запретов». Выгодное географическое положение, продуманная стратегия развития позволили Сингапуру стать одним из наиболее развитых государств мира. Интересный факт, что каждый 10-й житель этого государства — миллионер. Микрогосударство без ресурсов — экономический гигант с самыми современными технологиями. Сингапур лидирует в развитии бизнес-среды, легкости ведения бизнеса и работе электронного правительства; в развитии информационных технологий и общей конкурентоспособности; в конкурентоспособности IT.







Жесткое правление диктатора Ли Куан Ю на протяжении 30 лет привело к процветанию государства, не смотря на то, что изначально положение было плачевно: отсутствие ресурсов, зависимость от Малайзии в поставках питьевой воды, запредельной коррупция и прокоммунистическое настроения у 30% населения.



Более 4 миллионов жителей Сингапура пользуются интернетом — это 73%. Сингапур опережает своих соседей — Малайзию и Индонезию. По меркам Юго-Восточной Азии здесь довольно высокий уровень доступа к интернету. В 2006 году был запущен генеральный план “Интеллектуальная нация 2015”, его реализация позволила Сингапуру стать мировым лидером по проникновению ультраскоростного интернета. Сингапур и Корея могут похвастаться самым высоким процентом дата-центров со сверхбыстрым подключением, более чем 1 Гбит/с, которые готовы удовлетворить требования следующего поколения, такие как виртуализация и мобильность. Мировые корпорации такие как Google, Amazon, IBM и многие другие уже разместили свои серверные фермы на территории данного государства.



Tropical Data Center (TDC)



Остров находится у экватора, поэтому климат в Сингапуре ровный и очень влажный, государство находится в области тропического муссонного климата. Влажность достигает от 70 до 90%, днем воздух прогревается в среднем до 32 градусов, ночью охлаждается минимум до 20.



В планах сингапурских инженеров провести испытания первой в мире серверной фермы, которая будет разработана специально для тропического климата. Новая инициатива Tropical Data Center (TDC) направлена на воплощение данного плана, а также призванна стимулировать инновации и исследование возможностей для применения экологически чистых технологий в дата-центрах.



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



Для эксперимента был выбран кампус серверной фермы Keppel Keppel Data Centre, проект должен стартовать осенью 2016 года.







Такие компании и организации как Dell, Futjitsu, Hewlett Packard Enterprise, Huawei, Intel, The Green Grid и Наньянский технологический университет (NTU- Nanyang Technological University) решили принять непосредственное участие в эксперименте, предоставив необходимую технику, аппаратное обеспечение, ПО. В ходе эксперимента будет проверяться «поведение» серверов в различных «живых» ситуациях, таких, как скачки напряжения, отсутствие температурного контроля или контроля влажности.







Согласно заявлениям сингапурских инженеров, как правило серверные фермы охлаждаются до 20-25 градусов Цельсия, а относительная влажность окружающей среды внутри них удерживается в диапазоне от 50 до 60%. Экспериментальный ЦОД TDC (пока теоретически) будет функционировать при гораздо более сложных условиях окружающей среды без дополнительных энергозатрат, что в свою очередь снизит растраты на электроэнергию до 40%, значительно уменьшит выбросы углекислого газа. Снизить энергопотребление инфраструктурой серверных ферм — задача первостепенная, ведь если верить статистике, то на их долю потребления приходится 7% из общего потребления электроэнергии страной. Из-за постоянного роста количества хранилищ данных в Сингапуре к 2030 году ожидается, что этот процент возрастет до 12.



Еще в 2014 году были попытки разработки новых технологии для охлаждения серверов. Сингапурский Институт микроэлектроники (Institute of Microelectronics — IME) создал консорциум Silicon Micro Cooler (SMC), задачей членов консорциума была разработка комплексных решений для управления температурным режимом различных полупроводниковых чипов с крайне высокими термопакетами. На данный момент в электронной промышленности наблюдается тенденция к постоянному уменьшению форм-факторов продуктов, расширению их функционала и повышение скорости обработки данных, а это может привести к появлению на поверхности мощных CPU и других чипов с высоким термопакетом «горячих точек». Из-за этого возникает необходимость в интенсификации рассеяния выделяемого чипом тепла в условиях постоянного уменьшения площади его поверхности. А вот высокая концентрация таких «горячих точек» на небольших участках поверхности чипов может стать причиной резкого роста температуры перехода, что может привести к выходу из строя чипов и находящихся рядом с ними электронных устройств.



SMC используя возможности института IME проводил исследований и разработки в области проектного обеспечения теплогидравлических характеристик (thermal and fluidics design), глубокого щелевого травления (deep trench etching) и соединения компонентов на уровне подложки чипа (wafer level bonding). Были разработаны механизмы для организации теплоотвода, созданы теплораспределители из синтетического алмаза и графена, кремниевые чипы гибридные микро-кулеры, которые справляются с тепловыделением мощных процессоров, радиочастотных усилителей и лазерных диодов.



Источник
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305780/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] Повышение энергоэффективности дата-центров: советы от Apple, Google, Microsoft, Active Power и Burland Energy

Четверг, 14 Июля 2016 г. 13:57 (ссылка)

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



В посте описаны варианты повышения энергоэффективности дата-центров от ведущих корпораций.







Apple переходит на топливные элементы



Всем известная компания Apple использовала необычный подход к повышению энергоэффективности дата-центров. Специалисты компании заявили о создании еще одного массива топливных элементов рядом со своим новым главным офисом Campus 2, строящимся в городе Купертино (штат Калифорния, США). Упомянутые массивы помогут минимизировать потери, неизбежные при передаче электроэнергии. Кроме этого, подобный вариант решения существенно снизит углеродный след вычислительной инфраструктуры.







Проект Apple Campus 2, спроектированный британским архитектором Норманом Фостером



Компания Bloom Energy выступила в качестве поставщика топливных элементов. Данная компания уже сотрудничала с Apple в Северной Каролине, где развернула генерирующие блоки неподалеку от кампуса дата-центра.



Возле здания Campus 2 инженеры Bloom Energy планируют развернуть 4-мегаваттные блоки, дополняющиеся солнечными батареями и массивом аккумуляторов. Скорее всего это будет супер современное решение Bloom Energy Server 5 с эффективностью, доходящей до 65%. И с точки зрения плотности мощности новое решение обещает почти в два раза превзойти своих предшественников.



Практика повышения энергоэффективности и снижения углеродного следа ЦОД от Google



В 2015 году компания Google сделала заявление о намерении расширить кампус ЦОД в центральной части острова Тайвань. Это понадобилось для ускорения экспансии на быстрорастущем рынке интернет-услуг Азии. И поисковый гигант также выбрал локальные генерирующие мощности на базе возобновляемых источников энергии. Подобный подход позволяет минимизировать углеродный след дата-центров, одновременно повышая энергоэффективность их инфраструктуры путем снижения потерь при передаче электроэнергии.







ЦОД Google, город Чжанхуа, Тайвань



В отличии от Apple, в компании Google не собираются строить собственные электростанции. Электроэнергия будет приобретаться с уже построенных генерирующих мощностей на базе возобновляемых источников энергии, которые находятся рядом с серверными фермами.



Варианты повышения энергоэффективности ЦОД от Microsoft и Primus Power



Microsoft и Primus Power объединили усилия с целью найти оптимальный способ эффективного хранения электричества из возобновляемых источников энергии. Это даст возможность обеспечить дата-центры доступным и экологичным электричеством. Обе компании действуют в рамках международной программы продвижения специализированных систем хранения энергии для ЦОД. Также с Microsoft и Primus Power будут сотрудничать организация NRG Energy и техасский Университет в Сан-Антонио.







Центра обработки данных Microsoft



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



Бизнес-модель Active Power и Burland Energy



Еще один совместный проект компаний Active Power и Burland Energy направлен на повышение энергоэффективности. Специалисты компаний собираются предоставить владельцам ЦОД системы бесперебойного питания, использующие бизнес-модель, подобную облачным сервисам. Это поможет использовать сверхсовременные системы ИБП с повышенной энергоэффективностью и при этом не переплачивать, уменьшая эксплуатационные расходы, связанные с электрической инфраструктурой дата-центров.







Данная бизнес-модель называется UPSaaS (UPS-а-а-Service). Согласно намеченному плану, компания Burland Energy будет приобретать маховиковые системы ИБП у Active Power, после чего устанавливать их в дата-центрах клиентов. Это позволит владельцам ЦОД платить только за использование оборудования и по фиксированной ставке за кВт*ч.



Снижения энергопотребления можно добиться разными способами. Например, с помощью равномерной модернизации не только вспомогательного оборудования, но и всех IT-систем с инфраструктурой.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305666/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Виртуализация сетевой инфраструктуры и SDN Solution

Среда, 13 Июля 2016 г. 17:02 (ссылка)





Наш сегодняшний доклад стоит немножко особняком в ряде других материалов с форума Облачные технологии в России: часть I, часть II, часть III, часть IV. Говоря об облачных технологиях, все в первую очередь подразумевают, конечно же виртуализацию айтишного оборудования, такого как сервера СХД и тд. Тем не менее сеть передачи данных является тем неотъемлемым связующим элементом, который собственно позволяет нам с одной стороны предоставлять облачные технологии, то есть обеспечивать коннективити, с другой стороны он нам необходим для собственно реализации центров обработки данных, для организации связности между ЦОД-ами, и на самом деле практически в 90% в текущих организациях, именно сеть передачи данных на сегодняшний день становятся тем узким местом, тем бутылочным горлом, которое, собственно затрудняет внедрение новых сервисов, внедрение новых приложений.











Сергей Аксенов, старший менеджер по продукции Datacom, HUAWEI



Коллеги, добрый день еще раз, сегодня Сергей Аксенов, компания Huawei. Компания Huawei имеет новую концепцию, новое решение, которое называется Agile Network. На русский язык слово Agile можно перевести как гибкий, управляемый, быстрый интеллектуальный. Это те ценности, которые закладываются в концепцию сетей следующего поколения. И если так немножко пошире посмотреть в историю, то на протяжении, наверное, последних 10 лет ничего кардинально нового с точки зрения сетевых технологий, сетевых решений не появлялось. Появлялись какие-то улучшения, дополнительные нововведения, но кардинальных изменений, по сути не было. И сейчас мы как раз стоим на пороге сетей нового поколения, так называемых сети SDN, Software Defined Networking, то есть программно-определяемых сетей, и собственно Agile Network и есть та самая программно- определяемая сеть.



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



Кроме термина SDN, я дам вам сразу чтобы расставить все точки над и, скажу что есть термин NFV – Network Function Virtualization, то есть здесь основной целью этого термина заключается в том что мы по сути уходим от дорогих аппаратных сетевых специализированных устройств и эти функции мы перекладываем на вычислительную инфраструктуру по виртуализации на сервера, об этом мы тоже сейчас немножко поговорим.



Собственно, если посмотреть на актуальные тренды в области информационных технологий, они на этом слайде показаны, ни для кого не секрет, на протяжении последних лет 5- 6 мы о них разговариваем, ежегодный взрывной рост трафика, появление новых стандартов телевидения появления видео ультра высокой четкости UltraHD, взрывной рост количества терминалов: это и технологии мобильности, это и технологии интернета вещей. По оценкам к 2020 году, порядка 5 млрд устройств они уже будут подключены к глобальной сети, при этом порядка 70% всех устройств это устройства связанные с internet of things, то есть с интернетом вещей. Собственно, облачные вычисления и опять же социальные сети, которые создают огромные объемы трафика собственно обмен различным типом контента все вот эти тренды, все эти предпосылки стали отправной точкой для разработки сетей следующего поколения.







Ни для кого не секрет, что в центре обработки данных на сегодняшний день уже наступила эпоха виртуализации, то есть как аппаратные сервера используют все меньше организаций, наверное, совсем смол-бизнес, то есть эпоха виртуализации в ЦОД фактически наступила. Вот этот переход к новой модели ресурсов, с точки зрения серверов и СХД произошел 10 лет назад, с точки зрения сети это изменение происходит сейчас. Сеть становится узким местом для внедрения новых сервисов, для внедрения новых приложений. То есть если рассмотреть туже самую систему виртуализации, то там большинство рутинных задач автоматизированы, то есть если нам требуется развернуть новый виртуальный сервер под какой-то сервис, например, или скопировать этот сервер из одного ЦОДа в другой ЦОД — там все эти операции рутинные можно выполнить за 15 минут, ничего сложного в этом нет для администратора.







При этом сеть передачи данных зачастую требует manual configuration, ручного управления. То есть если мы хотим чтобы виртуальная машина или какая-то новая виртуальная среда у нас мигрировала, чтобы она развернулась там у нас в ЦОДе, для этого нам зачастую требуется вручную сделать все эти изменения, требуется привлекать сетевого администратора, который будет прописывать новые политики маршрутизации, политики коммутации, качество сервиса, безопасности и тем самым у нас затрудняется внедрение новых сервисов, то есть в данном сценарии это займет уже не 15 минут с точки зрения виртуализации вычислительной инфраструктуры, а займет уже до 2 дней.







Следующий негативный момент, который зачастую мы видим во многих организациях в том, что от нас до сих пор не зависимо управление компонентами и сложность в поиске неисправности. Если посмотреть на структуру какой-либо там крупной или средней организации то, как правило, там, в айтишной службе эксплуатации 2 типа инженеров. Первый тип инженеров – инженеры сетевики, которые отвечают именно за сеть передачи данных и собственно второй полк инженеров, это системные администраторы, которые отвечают за сервера, отвечают за СХД. Собственно, на слайдах показано, по сути у нас происходит водораздел. Как с точки зрения эксплуатации с точки зрения планирования, использования ресурсов у нас это разные компоненты так и сточки зрения их взаимодействия. Они до сих пор не смотря на то что взаимодействуют, тем не менее, разрозненные компоненты.







И здесь показан один из кейсов, который за счет разрозненности за счет того, что они плотно не интегрированы не взаимодействуют друг с другом, то есть они не видят, что со стороны одного из компонентов происходит какая-то проблема, на втором это не отражается. Здесь показан прямой кейс, простой, что кратковременная проблема на сетевой инфраструктуре, она влечет то, что все виртуальные машины у нас мигрируют в одной из областей на один из серверов, тем самым мы наблюдают перезагрузку, в то время как другой в это время простаивает. Это сетевая проблема, она была совсем кратковременна, она никоим образом не отразилась бы на качестве работы различных приложений и сервисов.







Все это и стало предпосылками для разработки и перехода к сетям нового поколения, к сетям с программно-определяемой архитектурой. Здесь написаны основные ценности, что сеть должна быть более гибкой и прозрачной для пользователей сервисов и приложений. Она должна стать гибкой, динамичной, быстрой и более интеллектуальной. Agile Network, как я сказал, это Software Defined Networking это программно-определяемая инфраструктура и, по сути, это целая концепция, которая существенно отличается от традиционных принципов построения и внедрения сети передачи данных. Если посмотреть на традиционный подход, на традиционные сети, которые долгое время у нас существовали, то там сетевой администратор оперировал физическими портами, физическими устройствами, топологией, то есть был жестко привязан к физическим устройствам. Говоря про концепцию Agile Network, про программно-определяемую сеть, мы здесь делаем фокус на пользователей сервисов и приложений. Мы определяем профили пользователей, определяем качество работы того или иного сервиса и, по сути, мы можем забыть про нашу топологию, про физические устройства. В традиционных сетях мы наблюдали такую ручную конфигурацию и раздельный подход, то есть какая-то, например, есть инфраструктура, состоящая из 50 сетевых устройств и раздельный подход подразумевал, что каждое из устройств требовало отдельной ручной конфигурации, т.е нужно было зайти на каждую их этих железок, подключиться через вэб-интерфейс или через командную строку и, собственно, в отдельности сконфигурить каждое из этих устройств. Сложность эксплуатации, сложность настройки, сложность управления такой сети она ощутимо сложная. В новой концепции мы приходим к всеобщему взаимодействию и к динамическому управлению всей инфраструктурой, то есть мы не просто настроили инфраструктуру с помощью командной строки, но и например там эта конфигурация живёт, в данном сценарии SDN, у нас все меняется на лету, то есть это не статическая сеть какой мы ее настроили, она, собственно, реагирует на все эти изменения которые происходят, эти изменения могут быть с точки зрения внедрения новых сервисов, появления новых пользователей, либо внедрения каких то новых политик безопасности, то есть это у нас теперь такой живой организм, и сточки зрения интеллектуального управления у нас здесь опять же появляется интеллект, но про это чуть дальше. И собственно здесь появляется такое нововведение как постоянный контроль и управление качеством. Мы не просто на авось конфигурируем нашу сеть, прописываем правила маршрутизации, политики коммутации. Мы в реальном времени теперь можем контролировать, как работает то или иное приложение, как работает тот или иной сервис. То есть, по сути, мы можем задать параметры SLA для работы того или иного приложения и собственно контролировать и обеспечивать выполнение этого SLA внутри нашей инфраструктуры.







Концепция Agile Network подойдет практически любой организации, любому предприятию и состоит она из 4 основных блоков. Первый блок это кампусная сеть, то есть это та корпоративная сеть, которая используется вашей организацией. Даже несмотря на то, что вы будете пользоваться облачными услугами, будете пользоваться услугами сервис провайдеров внешних, ваша внутренняя кампусная сеть необходима для подключения пользователей, их терминалов, теперь эти терминалы могут быть беспроводными, но тем не менее кампусная сеть у вас там присутствуют. Второй компонент — это компонент Agile Network для центров обработки данных. Про ЦОДы будут отдельные слайды, про них я расскажу как там что реализуется. Большинство заказчиков, которые с нами взаимодействуют, например ритейл, у них имеется такая распределенная архитектура, например распределенная сеть магазинов несколько сотен или тысяч объектов и централизованный ЦОД, собственно здесь проблемные задачи точно такие же, это разрозненная архитектура, которая управляется централизованно, собственно решение от Huawei позволяет это реализовать. И наконец, 4 компонент Agile Wan это компонент для управления внешним каналом связи. На сегодняшний день все больше заказчиков заинтересованы в использовании облачных технологий, заинтересованы в том, чтобы иметь несколько ЦОДов географически разнесенных, и как раз управление качеством через внешние каналы, через каналы сервис провайдеров, это тоже видите такой актуализатор актуальной проблемы. ну давайте по порядку, сначала поговорим про кампусные сети.







Ядром и сердцем кампусной инфраструктуры является 2 компонента в решении Agile Network. Первый компонент – специализированное программное обеспечение называемое SDN контролллер, у нас называется Agile campus controller, собственно это программное обеспечение которое позволяет централизованно управлять политиками, профилями подключения пользователей, позволяет управлять конфигурациями сетевых элементов и собственно управлять путями передачи трафика, теперь мы по сути переходим к такой модели что не 50 разрозненных устройств, а 50 устройств которые занимаются просто подключением, то есть занимаются передачей данных и одна точка то есть это централизованный интеллект, мозг системы который управляет за абсолютно всю логику по передаче трафика, по политике безопасности, по качествам сервиса. И собственно второй компонент это сеть передачи данных, здесь необходим специализированный коммутатор нового поколения, они уже называются Agile коммутаторы, то есть это сетевые элементы которые могут взаимодействовать с централизованным интеллектом, с централизованным SDN контроллером и собственно по протоколу OpenFlow, или про протоколам NETCONF, они понимают каким образом передавать трафик, каким образом подключать того или иного пользователя, каким образом реагировать на ту или иную угрозу, то есть теперь это такие по сути управляемые устройства. Кроме управляемости с помощью централизованного интеллекта здесь появляется еще 5 нововведений, о которых говорит Huawei, это конвергенция проводных и беспроводных элементов сети. Под конвергенцией здесь понимается, что мы приводим нашу сеть к единому знаменателю. Зачастую сеть Wi-Fi в организациях рассматривалась как дополнительная к проводной, потому что Wi-Fi долгое время не мог обеспечить ни достаточного качества, ни достаточной пропускной способности, сегодня с появлением стандартной 802.11ac с гигабитами пропускной способности через радио интерфейсы с полноценной реализацией кос мы можем говорить о том, что беспроводная сеть у нас становится частью нашей проводной сети. По сути это действительно единый знаменатель, нам необходимо централизованно управлять обоими компонентами нашей инфраструктуры. Второе нововведение это абсолютная мобильность, контроль управления качеством, единая безопасность и программируемость. На каждом элементе мы сейчас остановимся подробнее, проговорим в деталях.







Конвергенция проводных и беспроводных элементов сети. Многие центры обработки данных долгое время использовали архитектуру, когда стоит какой-то главный коммутатор, стоят top-of-rack коммутаторы для непосредственного подключения серверов и, собственно, вот эти top-of-rack коммутаторы выступают как фабрики коммутации, как выносные линейные карты, какой бы у нас не был ЦОД, сколько бы у нас там не было коммутаторов доступа, для подключения серверов, всем этим можно было управлять централизованно с помощью этих больших виртуальных коммутаторов. Собственно говоря, про решение Agile Campus мы приходим ровно к той же самой модели, вся наша сетевая инфраструктура состоящая ранее их 50 элементов, приходит к модели что это по сути один большой виртуальный коммутатор, который состоит из 50 виртуальных плат, т.е из одной точки с помощью единого унифицированного централизованного управления мы можем управлять всей нашей сетевой инфраструктурой. Здесь собственно это и нарисовано. Тут у нас была какая-то кампусная инфраструктура, состоящая из уровней ядра, теперь все это превращается в единый виртуальный коммутатор, в котором появляется N-ое количество виртуальных плат. При этом точки доступа Wi-Fi которые у нас там все время выглядели как такой отдельный элемент, требовали установки специализированного контроллера BLDC, теперь все это опять же сводится к одной точке, то есть точки доступа у нас будут выглядеть как порты доступа.







Второе. Долгое время беспроводная сеть рассматривалась наложенной на проводную и требовала отдельного управления. Мы строили специализированную беспроводную сеть, мы там строили CAPWAP туннели, ставили беспроводные контроллеры, нам надо было задуматься каким образом сделать аутентификацию и подключение пользователей, с помощью пароля или через эктив директори их авторизовывать или там все-таки радиус сервер, с другой стороны у нас была вторая часть инфраструктуры, проводная в которой там были свои правила политики безопасности, свои правила аутентификации пользователя. Собственно, в решении Agile Network мы приходим к тому что независимо от того где и каким образом подключен пользователь мы можем его в единой точке аутентифицировать и подгружать его профиль. Например, у нас сидит бухгалтер в каком-то учреждении на 2 этаже, в какой-то момент вся бухгалтерия переезжает на 4 этаж. В традиционном подходе это требовало бы от сетевых инженеров чтобы те настройки, которые были на коммутаторе 2 этажа, они там собственно все удалили, и перенесли на коммутатор доступа на 4 этаже. То есть здесь должность такого перегруза 1-2 дня заняло бы. В сценарии Agile Network поскольку у нас появляется здесь единый интеллект, который сохранит все профили пользователей вне зависимости от того на каком они этаже, подключаются они с помощью ноутбука либо подключаются с помощью вайфая, мы просто подгружаем их профиль с помощью механизма идентификации, будь это радиус, будь это веб портал с каким-то логином и паролем и собственно все эти политики все эти правила загружаются на порты доступа. То есть здесь у нас сложность по эксплуатации сети резко снижается.







То же самое происходит с точки зрения технологии абсолютной мобильности, на сегодня рамки рабочего времени они, наверное, уже стерты практически, мы работаем не только с 9 до 6 как привыкли раньше, теперь у нас у всех есть смартфон, есть планшет, есть возможность удаленного доступа, я за собой зачастую наблюдаю, что я в офисе провожу намного меньше времени, чем собственно в командировках, на мероприятиях, и возможность получения единого пользовательского опыта она очень важна. Вне зависимости от того откуда и каким образом подключен пользователь, он везде получит свою пропускную способность, получит свои правила и политики безопасности. При этом мы можем в нескольких плоскостях управлять этими политиками, для того чтобы обеспечить внутреннюю информационную безопасность. Опять же пример. Например, я прихожу в офис и со своего ноутбука подключаюсь к корпоративной сети со своим логином и паролем. Собственно, я получаю доступ к абсолютно всем внутренним ресурсам, почтовый сервер, система ERP система CRM, то есть у меня здесь никаких ограничений нету. При этом работодатель хочет, чтобы, например, когда я вечером работаю из дома я не мог любую информацию скопировать, чтобы я имел доступ только к корпоративной почте. Собственно, я прихожу домой, ввожу тот-же логин и пароль и теперь система определяет, что это мой профиль, но мое местоположение вне офиса. Собственно, автоматически загружаются новые политики, которые не позволят мне теперь получить доступ к внутренним ресурсам. Тоже самое можно делать, привязываясь к типу терминала. Например, в офисе со своим ноутбуком, со своим логином и паролем я получаю опять же доступ ко всем внутренним корпоративным ресурсам из того же офиса со своим смартфоном или айпэдом, вводя ровно тот же самый логин и пароль я получаю доступ только к интернету, то есть мы теперь в нескольких плоскостях можем и аутентифицировать пользователя, идентифицировать его принадлежность по типу терминала, по признаку сетевому, мак адресу, айпи адресу, по времени доступа, его местоположению, мы теперь весьма гибко можем управлять и нагружать политики безопасности. При этом с точки зрения сетевого администратора не требуется делать ничего, один раз настроить сетевые политики, и они просто соблюдаются. Здесь мы получаем опережено-личное управление сетью.







Еще она концепция та которая уже, тем не менее, работает — это идентифицированная безопасность. С точки зрения корпоративной сети либо центра обработки данных всегда рассматривалось какое-то сетевое устройство, как правило, фаерволл, который стоял по периметру сети и собственно он обеспечивал фильтрацию трафика. Фильтрация могла быть по access control листам или какой-то DPI, мы глубоко разбирали этот трафик, понимали какое приложение работает, что за уязвимость там может быть, есть ли там вирусы и так далее. Но это подход статический. Мы один раз настроили и надеемся на то что ничего там не произойдет, что те настроенные один раз политики они будут эффективны, будут защищать нашу сетевую инфраструктуру. Но на самом деле если изменится тип угрозы, появится какой-то новый тип угрозы, то можно просто не отследить этот момент. Поэтому собственно в реализации Huawei каждый сетевой элемент может собирать и передавать информацию обо всем проходящем через него трафике, и передавать это в единую точку в центр обеспечения безопасности. То есть теперь мы в реальном времени на реальных потоках трафика можем собирать информацию абсолютно обо всех событиях, которые происходят внутри сетевой инфраструктуры, и если в какой-то момент там происходят изменения, происходит какой-то резкий всплеск трафика, то мы в реальном времени можем отследить ситуацию, уведомить администратора, и система автоматически примет действие для защиты от различных типов атак даже новых, которые только появляются.







Собственно, технология iPCA для контроля и управления качеством. Здесь опять же проще на примере, что у нас есть какая-то инфраструктура, пусть это кампусная инфраструктура будет, инфраструктура ЦОДа, и если нам требовалось проверить как работает наша сеть, с каким качеством будет работать то или иное приложение, то для этого требуется стимулировать дополнительный поток трафика из точки А в точку Б и по прохождению этого трафика могли сравнить, понять какая задержка какая потеря, и собственно определяли, как может работать наша сеть, то или иное приложение. Опять же для этого требовалось создавать дополнительную нагрузку на сети, аккумулировать потоки трафика и по сути реальную картину мы не получали. Собственно, технология iPCA это технология сквозного контроля и обеспечения качества, она позволяет на реальных потоках трафика, не создавая никакую нагрузку определять SLA, заданный параметр качества и соблюдать. Если в какой-то момент заданные параметры начинают ухудшаться, то система автоматически позволяет перестроить пути передачи трафика таким образом, чтобы SLA выполнялся.







Собственно, в заключение про кампусное решение, оно тоже называется SDN, программно-определяемая инфраструктура, но с точки зрения Huawei переход к сетям следующего поколения не должен быть революционным, который требует полной замены всех сетевых элементов, он должен быть эволюционным. То есть те сетевые решения, приложения, сервисы, которые уже работали на инфраструктуре у заказчика они должны сохраниться, они должны продолжить работать так как и работают. Та сетевая инфраструктура, которая была построена, она тоже должна продолжать работать. Но при этом наши коммутаторы могут параллельно работать как в программно-определяемой инфраструктуре, так в уже устаревающих на сегодняшний день традиционных сетях с коммутацией, с маршрутизацией. С точки зрения аппаратной реализации, по сути на сегодняшний день это уже 5 поколение коммутаторов, которые выпускают Huawei, начиная с 1989 года, когда были выпущены первые хабы, они так еще назывались, потом у нас появлялись коммутаторы, которые умеют делать маршрутизацию, после этого 4 поколение это были специализированные построенные уже на ASIC, специализированных сетевых процессорах, которые были жестко привязаны к обработке тех или иных алгоритмов.







Теперь мы говорим о 5 поколении коммутаторов, в которых используются новые чипсеты, это не традиционные ASIC, которые жестко привязаны к обработке по определенному алгоритму, различных протоколов. ENP процессоры они полностью программируемые. Если у нас появляется какой-то новый протокол, какой-то нестандартный сервис, который требует какие-то изменения в протоколе то ENP процессоры позволяют довольно гибко реагировать на эту проблему, достаточно изменить прошивку этого микропроцессора и он так же на лету сможет обрабатывать новые типы трафика. Для чего это нужно? Поскольку SDN на сегодняшний день де факто не стандартизирован, существует протокол OpenFlow в разных версиях, но он до сих пор дорабатывается, у многих вендеров у многих производителей существуют свои какие-то проприетарные вещи, свои доработки. Заказчик на сегодняшний день покупает это оборудование, предназначенное для сетей следующего поколения, он хочет быть уверен, что купленное оборудование оно будет актуально и через 5-6 лет, когда SDN будет окончательно стандартизирован. Собственно, гибкие программируемые сетевые процессоры позволяют решить эту задачу.







На сегодняшний день у нас уже выпущено несколько моделей гибких коммутаторов, первым таким флагманом это была линейка S12700, собственно традиционные там модульные коммутаторы, которые допустим на 8, на 12 интерфейсных платах ну ничего удивительного, то есть оборудование которое можно использовать на уровне ядра сети и на уровне агрегации, но они уже построены на этой гибкой архитектуре с ENP процессором.



У нас уже реализовано N-ое количество различных проектов, и глобальный проект, по сути архитектура Agile Network это концепция, она присутствует 1,5 года на рынке, но уже удалось реализовать много разных проектов. В том числе в России в прошлом году у нас были уже первые ласточки, вот интересный проект мы сделали в МГПУ (Московский государственный педагогический университет), но в вузах в России сейчас проходит реструктуризация, т.е выбирается главный вуз и вузы поменьше, колледжи, они цепляются к этой головной организации, головному вузу. И там собственно такая же проблема была, там была внутренняя инфраструктура сетевая МГПУ плюс там цеплялись вузы поменьше, цеплялись колледжи, при чем там абсолютно разрозненность наблюдалась, то есть у кого-то свежее оборудование Cisco было у кого-то Huawei стояло, у кого-то стояли оборудования D-Link, MikroTik, и всем этим было трудно управлять, абсолютно разрозненная инфраструктура, разный синтаксис, разные сетевые инженеры с разной квалификацией и так далее. Собственно, решение Agile Network позволяет привести все это к единому знаменателю, мы можем поставить централизованный контроллер, абсолютно все оборудование нам не требуется менять, нам требуется заменить лишь некоторые узлы и мы с помощью единой системы мониторинга, с помощью единой системы управления можем за всей этой инфраструктурой наблюдать. Можем вносить изменения, получать информацию о каких-то проблемах, неисправностях, строить отчеты и так далее.







Второй компонент- это решение Agile Branch, которое когда у нас инфраструктура не просто замкнутая, кампусная, наша корпоративная сеть, а когда у нас собственно разрозненная инфраструктура, то есть у нас есть несколько удаленных офисов, есть какая-то центральная точка, и опять бы мы хотели чтобы мы централизованно из этой точки могли управлять абсолютно разными политиками. Для этого Huawei выпускает новую линейку маршрутизаторов, они называются у нас Agile Gateways, гибкие шлюзы можем перевести, и раньше такие устройства по сути были, это были такие мультисервисные маршрутизаторы все в одном, они обеспечивали доступ в интернет примерно, проводку голоса, имели встроенный фаерволл и встроенную точку доступа.



Теперь говоря про мультисервисные маршрутизаторы, они стали еще более мультисервисными, еще более гибкими, если так можно сказать.



Теперь они построены по архитектуре X86, по сути, это такой мини сервер, там есть встроенный SSD накопитель, куда можно поставить полноценную операционную систему: Windows. Linux. Android, то есть абсолютно все, что угодно. Это дает нам возможность предлагать не просто традиционные коммуникационные решения, когда нам требуется объединить несколько точек, это дает возможность создавать абсолютно новые бизнес приложения. Как пример, с одним из системных интеграторов мы сейчас прорабатываем решения, они хотят в общественном транспорте, в торговых центрах поставить экраны, телевизоры, в которых встроена веб-камера и есть выход HDMI. Туда ставятся наши интеллектуальные маршрутизаторы с операционной системой на Windows и написанное приложение. Человек подходит к этому экрану, встроенная веб-камера позволяет проанализировать, кто подошел: мужчина/женщина, и какого возраста: ребенок или пенсионер. После того, как мы определили принадлежность половозрастную этого человека, мы можем показывать ему таргетированную рекламу. Ребенку показывают рекламу подгузников, чупа-чупсов, пенсионеру показывать рекламу лекарств или подгузников. Тоже актуально.

Теперь у нас появляется дополнительная гибкость, мы не просто строим коммуникационную сеть, мы строим сеть, на которую можно разворачивать такие value-added services. Зачем там нужны маршрутизаторы? В принципе это все можно было реализовать с помощью обычных серверов, с помощью каких-то PC, подключить те же самые экраны. Маршрутизаторы тут нужны с той точки зрения, что на всех тех объектах надо обеспечить коннективити, где-то это проводное подключение, где-то DSL, где-то 3G, где-то 4G. Нам надо управлять информационной безопасностью, нам надо управлять политикой подключения, политикой обновления этих устройств. Раньше если эта разрозненная инфраструктура была представлена – 100 магазинов + головной ЦОД, то теперь это 10 тыс. экранов + 1 главный ЦОД. То есть этими 10 тыс. устройств надо так же централизованно управлять. Наше решение Agile Network нацелено на решение этой задачи в том числе.







Еще один кейс, что когда у нас существует такая разрозненная инфраструктура, состоящая из сотен, тысяч удаленных точек, большой проблемой является внедрение и развертывание новых объектов. Для этого нам в эти 10 тыс. точек надо отправить инженера, какого-то специализированного, который понимает и имеет достаточную квалификацию для настройки этого устройства. Это проблемно, это затруднительно. Поэтому в концепции Agile Network мы полностью от этого уходим, мы просто отправляем эту коробку на объект, обеспечиваем для нее подключение к интернету, USB-свисток вставляем LTE-шный, все, после этого устройство автоматически подгружает конфигурацию, подгружает все свои настройки с помощью централизованного SDN-контроллера. То есть развертывание этой инфраструктуры, развертывание объектов получается очень простой и доступный для большинства заказчиков.







Ну и, с точки зрения аппаратных моделей, здесь у нас есть большая продуктовая линейка: для стационарного использования, для мобильного использования, для использования в сценариях интернет вещей, когда нам надо подключить n-ое количество смарт-сенсоров, каких-то датчиков, все это можно реализовать в подобных шлюзах. Еще одна вещь – виртуализация и облака присутствуют и здесь. На вот этом обычном маленьком маршрутизаторе можно сделать виртуализацию, там есть KVM, то есть на одну виртуальную среду вы можете поставить Linux, на другую Windows или еще что-то. Виртуализация дошла до совсем простых коробок, абонентских устройств, абонентских девайсов.







Третий компонент решения Agile Network, он наиболее близкий к тематике сегодняшнего мероприятия, это Cloud Network, это решение Agile Network для облачной инфраструктуры, для инфраструктуры центров обработки данных. С одной стороны, здесь главными требованиями является, во-первых, эластичность. Эластичность – под ней понимается и производительность аппаратная устройств, эластичность с точки зрения функционала, эти устройства должны обеспечивать нам связность между разными ЦОДами, либо должны обеспечивать связность внутри нашего ЦОДа. Вторая основная ценность для сетевого оборудования ЦОДа – это открытость. В ЦОДах не должна быть моновендерная инфраструктура, зачастую она мультивендерная, мы должны обеспечивать взаимодействие, мы должны обеспечивать API для взаимодействия различных компонентов, для их плотной интеграции.

Третий Кит – это виртуализация. С одной стороны, для вычислительных ресурсов, с другой стороны для сетевых элементов в том числе.







Здесь у нас тоже выделена линейка оборудования, коммутаторы из серии Cloud Engine, они представлены в фойе, можно подробнее ознакомиться, и с модульными решениями – 12800 и с top-of-rack коммутаторами. Широкая линейка оборудования, они предлагают с одной стороны уникальную, с точки зрения производительности архитектуры, если посмотреть на те значения емкости коммутации, пропускной способности, плотности портов, то Huawei уверенно опережает всех производителей по тем же даташитам можно убедиться в технологичности нашего оборудования. С другой стороны, здесь присутствует полный пул технологий, для виртуализации.

Если кратко по ним пройтись, первая технология у нас называется Virtual Switch (VS). Представьте, что существует какой-то крупный коммерческий ЦОД и несколько арендаторов. При этом каждый из арендаторов хочет самостоятельно управлять не только вычислительной инфраструктурой, серверами и сервисами, но хочет управлять и сетевой инфраструктурой, самостоятельно прописывать политику маршрутизации, политику качества сервиса, политику безопасности. Технология VS позволяет нам один физический коммутатор представить в виде 16 виртуальных. Мы можем сказать, что у нас стоит такой большой коммутатор, интерфейсная плата первая, порты с 1-7, 23, 25 – это арендатор №1, интерфейсная плата 7, порты с 17 по 25 – это арендатор №2. Мы закрепляем за ними вычислительные ресурсы, и после этого эти арендаторы работают независимо друг от друга. На одного из арендаторов может начаться DDOS-атака, на другом это никоим образом не отразится. Они будут работать абсолютно изолированно друг от друга.



Следующая технология: SVF – Super Virtual Fabric, Виртуальная фабрика. Может быть сколь угодно большой центр обработки данных, состоящий из 100 стоек, при это мы можем централизованно из одной точки, с помощью единого коммутатора управлять абсолютно всей нашей сетевой инфраструктурой. Все эти 40, 50, 100 стоек будут выглядеть просто как дополнительные виртуальные платы, дополнительные выносы этого нашего головного коммутатора. И еще одной актуальной проблемой, актуальным трендом для центров обработки данных является обеспечение связности между несколькими ЦОДами. Так называемое решение disaster recovery, решение active-active. Когда у нас есть несколько ЦОДов, географически разнесенные. Если там в какой-то момент наблюдаются программные или аппаратные сбои в одном из ЦОДов, то для сервисов, для приложений, для пользователей это должно быть абсолютно незаметным. Все должно работать безшовно. В этом случае нам требуется такая плавная миграция виртуальных машин из одного ЦОДа в другой ЦОД. Для этого надо обеспечить так называемую L2 связность. Для этого у нас тоже существует целый ряд технологий, есть проприетарная технология, которая называется EVN, то, что у CISCO называется OTV. Но на сегодняшний день все вендеры приходят к единому знаменателю, технология EVPN, которая позволит работать разным вендерам, позволит взаимодействовать им между собой и обеспечивать L2-связность. Наше оборудование уже поддерживает такую мейнтстримную технологию, то есть все это заложено.



Говоря про ЦОДы, еще одной актуальной задачей и проблемой является увеличение количества VLAN, то есть увеличение количества пользователей сетевых ресурсов, которые мы предоставляем. Для этого наше оборудование поддерживает такую мейнстримную технологию, которая называется VXLAN, и он позволяет нам с 4000 VLAN увеличить это количество до 16 миллионов VLAN. Оборудование Huawei на линейке Cloud Engine это все тоже заложено.







Опять же оборудование ЦОДовское, оно конвергентное, там может быть не только ethernet, там может быть FCoE, это может быть просто fiber channel, различные варианты реализации сетевой инфраструктуры у нас тоже присутствуют. И тот компонент, про который мы уже говорили, Agile Controller, то есть централизованный интеллект, с точки зрения ЦОДа нам приносит тоже много value. С одной стороны, он будет иметь южный интерфейс к системе виртуализации, в настоящий момент система виртуализации может быть виртуализация от Huawei, которая называется Fusion Sphere, наш гипервизор. Это может быть широко используемый VMware, опять же это может быть виртуализация от Microsoft (HYPER-V). С другой стороны, контроллер имеет интерфейс для взаимодействия с низшим уровнем, то есть с уровнем сетевых элементов, сетевых устройств. То есть теперь все те изменения, которые происходят в вычислительной инфраструктуре, они не проходят незаметно для сетевой части инфраструктуры, она реагирует на все те изменения, которые произошли, соответствующим образом.







И мы приходим к модели всеобщего взаимодействия, мы получаем возможность быстрого внедрения сервисов. Теперь те задачи по рутинному разворачиванию каких-то образов, по рутинному разворачиванию новых сервисов, виртуальных машин, мы можем реализовать благодаря сетевой инфраструктуре. Теперь у нас service provisioning model, теперь нам не надо привлекать отдельно айтишного администратора, не надо привлекать сетевого администратора, теперь просто человек, которому требуется развертывание нового сервиса, он заказывает это в портале самообслуживания, и система там автоматически разворачивает виртуальные машины, и автоматически производит необходимые изменения в сетевой инфраструктуре.



На этом все. Вот те основные ценности, которые я хотел вам рассказать про Agile Network. С одной стороны, с точки зрения ЦОДов, у нас есть технологии, которые обеспечивают связность, обеспечивают решения active-active. С другой стороны, мы обеспечиваем работу кампусных сетей, которые приводим к единому знаменателю. Мы можем управлять профилями пользователей, политиками безопасности, политиками качества сервиса, конфигурациями устройств с помощью единой точки, то есть мы уходим от раздельного статического подхода. И если нам требуется построить такую распределенную инфраструктуру, состоящую из n-го количества элементов, то здесь мы можем все это привести к единой точке и централизованно управлять всей сетью.



Вопрос из зала: Если используется в одном месте коммутатор от Cisco, в другом Huawei или еще какая-то другая фирма, то cloud engine способен конфигурировать их, для того, чтобы вносить изменения?

— На самом деле все производители сей к этому идут, open flow как раз и создан этот протокол взаимодействия, он создан для того, чтобы SDN контроллер централизованный был от одного вендера, устройство от какого-то другого вендера, и все это прекрасно взаимодействовало. И на сегодняшний день такого нет. Все-таки step by step мы к этому идем, мы идем к стандартизации. Все эти красивости и плюшки можно реализовать только на нашем оборудовании в полном объеме.



Вопрос из зала: То есть нельзя подружить iOS и что-то ваше?

— Здесь вопрос в том, что надо дружить и какую задачу мы решаем. На сегодня 90% заказчиков интересует насколько возможно интегрировать оборудование Huawei, Cisco, при том, что у Cisco энное количество своих проприетарных закрытых технологий. Huawei это прекрасно понимает. У 95% заказчиков инфраструктура уже построена, то есть мы приходим на все готовое. И если мы хотим, чтобы наше оборудование у заказчика заработало, то мы должны обеспечить полную совместимость. Мы должны обеспечить сохранение тех сетевых сервисов, которые у него были в полном объеме. Если говорить про традиционные решения, не SDN-овские, то там мы можем обеспечить полноценную интеграцию. Cisco с Huawei прекрасно будут работать. Но с точки зрения SDN с контроллером, пока у всех производителей это пока проприетарно. Это уже не просто концепция на будущее, это реально работающий сценарий, но пока полной интеграции, к сожалению, нет.








Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305610/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Безопасность в облаке: Juniper vSRX и cSRX

Вторник, 12 Июля 2016 г. 15:16 (ссылка)

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











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



Это толкает ИТ-департаменты компаний на внедрение межсетевых экранов, что позволяет обеспечить гибкость, адаптивность и снижение затрат. Видение компании Juniper Networks относительно безопасной программно-конфигурируемой сети (SDSN), включает сквозную наблюдаемость сети, которая обеспечивает ее безопасность как с физической, так и с виртуальной точки зрения, повышая эффективность использования облачной среды для обнаружения и предупреждения угроз в реальном времени. В рамках этой концепции Juniper анонсировала две новинки – первый в отрасли виртуальный межсетевой экраном с пропускной способностью в 100 Гб/с и сервисный шлюз серии SRX, на базе Docker (cSRX), предоставляющий усовершенствованные службы уровней приложений L4-L7 (защита контента Content Security, унифицированная защита от угроз UTM).



vSRX



Juniper vSRX представляет собой полное решение с виртуальным межсетевым экраном. Как самая быстрая в отрасли виртуальная платформа безопасности, vSRX предлагает пропускную способность до 100 Гб/с, обеспечивая масштабируемую и надежную защиту для высокопроизводительных приложений.



Решение vSRX предназначено для предприятий, нуждающихся в обеспечении безопасности виртуальных центров обработки данных, расположенных в облачной среде частного и гибридного типа. Такие организации имеют потребность в сегментации политики безопасности, а также в одновременном управлении политикой безопасности и конфигурации на физических и виртуальных платформах из единого центра управления (средством управления в данном случае выступает Junos Space Security Director.



vSRX отлично подойдет и поставщикам услуг хостинга, предлагающим услуги по обеспечению безопасности и возможности подключения виртуальных машин, размещаемых клиентами. Каждому из клиентов предоставляется отдельный межсетевой экран vSRX для хранения его ресурсов в безопасности. Также решение станет хорошим выбором для поставщиков управляемых услуг защиты (MSSP). В данном случае ключевым требованиями, выдвигаемые к запросам на услуги, будут гибкость и способность быстро адаптироваться, что позволит, в зависимости от требований клиента, расширять и сужать спектр предоставляемых услуг безопасности. Благодаря автоматическому предоставлению услуг в соответствии с требованиями, решение vSRX обеспечивает нужный охват и адаптивность.



Juniper vSRX обеспечивает самую высокую в отрасли производительность межсетевого экрана на ядро – 17 Гбит/с и 4 Гбит/с для IMIX-трафика для больших пакетов. Масштабируемость производительности составляет до 100 Гбит/с и 25 Гбит/с для IMIX-трафика с 12 виртуальными ЦП. Решение имеет широкий функционал по обеспечению безопасности: унифицированная защита от угроз UTM, специализированные аппаратные средства IPS, полноценный антивирус, антиспам, фильтрация контента и службы AppSecure (видимость и управление приложениями). vSRX управляется централизованно (как уже упоминалось выше, с помощью Junos Space Security Director), а также автоматизированную инициализацию и управление жизненным циклом посредством Junos Space Virtual Director. Есть возможность подключения к виртуальным частным сетям и функции маршрутизации в формате адаптивной виртуальной машины на основе ОС Junos. Стоит отметить и Full HA – сохранение сессий при переключении на standby-устройство.



Основные конкурентные преимущества Juniper vSRX



— Самый производительный виртуальный межсетевой экран с наивысшим быстродействием



— Наименьшая совокупная стоимость владения (ССВ)



— Интеграция с физическими межсетевыми экранами серии SRX для централизованного управления, конфигурирования политики безопасности и управления



— Встроенная отлаженная маршрутизация, подключение к сети и функционал высокой доступности



— Гибкая модель расчета цены



Использование программного обеспечения vSRX предлагается в виде как бессрочной лицензии, так и подписки. Модель расчета цены меняется в зависимости от типа лицензии на пропускную способность (вместо существующей, где за основу бралось количество виртуальных ЦП). Лицензия vSRX будет предложена в трех разных пакетах с возможностью увеличения пропускной способности на 10 МБ, 100 МБ, 1 Гб, 2 ГБ и 4 ГБ.



— Базовый пакет межсетевого экрана (STD), включающий межсетевой экран, поддержку виртуальной частной сети и функций маршрутизации;



-Пакет защиты приложений (ASEC), который включает все функции пакета STD плюс IPS и AppSecure;



-Пакет защиты контента (CS), включающий все функции пакетов STD и ASEC плюс антивирус, фильтрация веб-контента и антиспам.



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



cSRX



Межсетевой экран cSRX предоставляет усовершенствованные функции безопасности уровней приложений L4-L7 (защита контента Content Security, службы AppSecure, унифицированная защита от угроз UTM) в компактном форм-факторе, допускающем увеличенную плотность на инфраструктуре x86, со временем загрузки менее секунды.







cSRX позволяет специалистам по безопасности разворачивать и масштабировать защиту с помощью межсетевых экранов в высокодинамичной среде. Решение предоставляет контейнеры с «Услугами безопасности функций виртуализированной сети» (Security Services VNF). «Упакованная» в контейнер версия межсетевых экранов Juniper серии SRX позволяет как предприятиям, так и поставщикам услуг значительно увеличить гибкость развертывания усовершенствованных услуг безопасности. Компактность, высокая плотность, а также быстрый разгон до рабочей скорости (fast spin-up times) –ключевые преимущества cSRX.



Контейнеры программного обеспечения Docker совместно используют единую операционную систему хоста для всех контейнеров приложений, запущенных на таком сервере. Контейнеры снижают потребление ресурсов приложениями, избавляя от необходимости в нескольких копиях ОС. Благодаря этому cSRX может работать быстрее, занимает меньше места, масштабируется в обоих направлениях и, наравне с vSRX, обеспечивает уровень плотности, значительно превышающий полноценные виртуальные машины.



Повышая эффективность путем использования Docker в качестве решения для управления контейнерами, сервисные шлюзы серии cSRX обеспечат простые, адаптивные и высокомасштабируемые варианты развертывания, охватывая множество различных способов применения. cSRX также поддерживает Juniper Networks Contrail, OpenContrail и другие решения сторонних производителей, и может интегрироваться с такими инструментами следующего поколения для оркестрации облачной среды, как OpenStack, причем как напрямую, так и с помощью API-интерфейсов.



Решение занимает не слишком много места, что позволяет экономить свободное пространство, и не требует резервирования ресурсов. Кроме того, для соответствия самым высоким требованиям возможно наращивание cSRX. Благодаря скорости начальной загрузки/перезапуска менее 1 секунды, межсетевой экран придает инфраструктуре клиента большую гибкость. При этом использование cSRX способствует снижению затрат компаний, поскольку заказчики могут выбрать необходимые функции, ориентируясь на приемлемую для них стоимость.







Бонус для интеграторов



При добавлении услуг vSRX и cSRX к своему портфолио, партнеры МУК могут получить ряд преимуществ. Так, появляется возможность предложить виртуальный межсетевой экран для клиентов-предприятий, которые переводят свои сети в облачную среду или виртуализируют их как полностью, так и частично. Предложение охватывает потребности как физической, так и виртуальной безопасности. Простая загрузка и 60-дневная пробная версия vSRX позволяет привлечь новых клиентов и дополнительные источники прибыли.



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



По вопросам обращаться: juniper@muk.ua.

Original source: habrahabr.ru.

https://habrahabr.ru/post/305500/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Фотоэкскурсия по дата центру от австралийского колокейшн-провайдера Micron21

Вторник, 12 Июля 2016 г. 13:24 (ссылка)

Представляю Вашему вниманию фото экскурсию по дата центру от австралийского колокейшн-провайдера Micron21. В его расположении на данный момент имеется один коммерческий ЦОД, который получил сертификат по надежности Tier III. Компания Mocron21 прошла также сертификацию проектной документации на соответствующие требования Tier IV (Tier IV Certified Design Documents). В будущем компания планирует сертифицировать свою коммерческую серверную ферму до уровня надежности Tier IV, которая уже построена и введена в эксплуатацию (Tier IV Certified Constructed Facility) и тем самым стать станет первым обладателем сертификата Uptime Institute Tier IV для уже готового дата центра в Австралии.







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















IT-направление принесло свои плоди и в 2014 году. Было принято решение продать все типографское оборудование и освободить место для будущего серверного оборудования (это произошло в июле 2015 года). Благодаря этому Джеймс Браунэгг смог увеличить свою IT-инфраструктуру с 10 стоек до 100 стоек и тем самым повысить мощность серверной фермы до 2 мегаватт. Он принял решение использовать часть полезного пространство для аренды сторонними компаниями с целю последующего размещения клиентского серверного оборудования.







Инженеры компании смогли обеспечить повышенную надежность всего вспомогательного оборудования: блоки питания, систему охлаждения и прочее вспомогательное оборудование, которое имеет запас мощности для получения сертификата и уровеня надежности Tier IV. Колокейшн-провайдер использует резервные генераторы фирмы — Cummins и чиллеры с фрикулингом, также конструкция предоставляет возможность установки дополнительных трубопроводов, компрессоров и насосов.









Главной ключевой особенностью ЦОД Micron21 является плотность размещения вычислительных в машзалах. На данный момент число клиентов превышает 1 тыс. пользователей хостинг-услуг, запросы которых обрабатываются серверным оборудованием внутри всего лишь 10 стоек на базе Raspberry Pi.







Сетевая инфраструктура дата центра Micron21 впечатляет — клиенты имеют прямой доступ к 1,6 тис. сетей по всему миру. И это удивительное достижение, как для такой скромной компании. Компания также защищает свою сеть с помощь собственного анти-DDoS сервиса, способного выдержать атаку 700 ГБ/с.







Micron21 имеет обширную клиентскую базу: от малого и среднего бизнеса до австралийских правительственных ведомств, которым требуется отказоустойчивые IT-услуги. При модернизации и расширении своего дата центра, австралийцы не предоставляли никаких неудобств в виде незапланированных простоев для своих существующих клиентов. При этом они создали собственный ЦОД, который был готов к сертификации Tier IV. Некоторые люди сравнивают это с модернизацией двигателя автомобиля, который находиться в движении.

Original source: habrahabr.ru.

https://habrahabr.ru/post/243927/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<цод - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda