Skip to main content

Центр Обработки Данных будущего: как он выглядит и зачем

А вы уже посмотрели новый фильм с Джеймсом Бондом "007:  Координаты "Скайфолл"? А заметили,что у Дата Центра (на картинке на заднем плане) очень мало проводов? Один блог даже назвал его "ЦОД будущего". Решение Cisco UCS позволяет сделать ваш ЦОД таким уже cегодня: Cisco Cloud Security Appliance.

Cisco Cloud Security Appliance

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

Popular posts from this blog

Сбербанк и дропы с площадки Dark Money, и кто кого?

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

Перехват BGP-сессии опустошил кошельки легальных пользователей MyEtherWallet.com

Нарушитель ( реальный заливщик btc и eth ) используя протокол BGP успешно перенаправил трафик DNS-сервиса Amazon Route 53 на свой сервер в России и на несколько часов подменял настоящий сайт MyEtherWallet.com с реализацией web-кошелька криптовалюты Ethereum . На подготовленном нарушителем клоне сайта MyEtherWallet была организована фишинг-атака, которая позволила за два часа угнать 215 ETH (около 137 тысяч долларов) на кошельки дропов. Подстановка фиктивного маршрута была осуществлена от имени крупного американского интернет-провайдера eNet AS10297 в Колумбусе штат Огайо. После перехвата BGP-сессии и BGP-анонса все пиры eNet, среди которых такие крупнейшие операторы, как Level3 , Hurricane Electric , Cogent и NTT , стали заворачивать трафик к Amazon Route 53 по заданному атакующими маршруту. Из-за фиктивного анонса BGP запросы к 5 подсетям /24 Amazon (около 1300 IP-адресов) в течение двух часов перенаправлялись на подконтрольный нарушителю сервер, размещённый в датацентре п

DDOS атаки на маршрутизатор и методы защиты Juniper routing engine

По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на маршрутизатор  Juniper MX80 поддерживающий BGP сессии и выполняющий анонс сетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом.  История атаки Исторически сложилось, что на маршрутизаторе блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка маршрутизатора: и график unicast пакетов с порта свича подключенного к роутеру: демонстрируют, что весь трафик осел на фильтре маршрутизатора. Поток unicast пакетов на аплинке маршрутизатора увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к

Сброс BGP-сессии при помощи TCP Connection Reset Remote Exploit

Уже ни раз рассказывал о протоколе ТСР , так что повторятся особо не буду, напомню лишь основные положения: Transmission Control Protocol описывается в RFC 793 и преимуществом его является надежность передачи данных от одной машины к другому устройству по сети интернет. Это означает, что ТСР гарантирует надежность передачи данных и автоматически определит пропущенные или поврежденные пакеты. Что для нас важно из его конструкции? В общем виде заголовок ТСР пакета выглядит так: Программа передает по сети некий буфер данных, ТСР разбивает данные на сегменты и дальше упаковывает сегменты в наборы данных. Из наборов данных формируются пакеты и уже они передаются по сети. У получателя происходит обратный процесс: из пакетов извлекаются набор данных, его сегменты, затем сегменты передаются в ТСР стек и там проверяются, потом собираются и передаются программе. Sequence numbers Данные разбиваются на сегменты, которые отдельными пакетами направляются по сети получателю. Возможна ситуация, к

Как найти реального заливщика

Своего первого реального заливщика, который показал мне как можно скачать деньги в интернет с банковских счетов, я нашел случайно, когда еще трудился в Укртелекоме сменным инженером немного подрабатывая продавая трафик налево , но потом этот человек отошел от дел в связи со слишком уж скользкой ситуацией в данной сфере, и я решил поискать партнера на форумах, разместив рекламу на трёх электронных досках объявлений. Честно говоря поначалу даже был готов сразу закинуть 500 000 гривен в Гарант, но потом призадумался, а стоит ли? Ко мне начал обращаться народ обращается разных категорий 1. Дебильная школота, которая что-то любит повтирать про свою серьезность и просит закинуть 10 000 USD им на Вебмани в качестве аванса  2. Реальные мэны, которые  льют сразу большую сумму по SWIFT  без разговоров про гарантии и прочую шнягу, но после того, как им отдаёшь нал, они сразу пропадают, суть данных действий я так и не понял. зачем пропадать, если всё прошло гладко? 3. Мутные личност

Обзор внутренней инфраструктуры безопасности Google

Обычно компании предпочитают хранить в тайне особенности своей инфраструктуры безопасности, которая стоит на защите дата-центров, полагая, что раскрытие подобной информации может дать атакующим преимущество. Однако представители Google смотрят на этот вопрос иначе. На то есть две причины. Во-первых, публикация таких отчетов позволяет потенциальным пользователям Google Cloud Platform (GCP) оценить безопасность служб компании. Во-вторых, специалисты Google уверены в своих системах безопасности. На днях компания обнародовала документ Infrastructure Security Design Overview («Обзор модели инфраструктуры безопасности»), в котором Google достаточно подробно описала свои защитные механизмы. Инфраструктура разделена на шесть слоев, начиная от аппаратных решений (в том числе физических средств защиты), и заканчивая развертыванием служб и идентификацией пользователей. Первый слой защиты – это физические системы безопасности, которые просто не позволяют посторонним попасть в дата-центры. Эта част