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


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

инфраструктура - Самое интересное в блогах

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

Гражданский сектор аэропорта "Бельбек"

Воскресенье, 25 Сентября 2016 г. 12:18 (ссылка)



У нас в Севастополе презентовали проект гражданского сектора аэропорта "Бельбек", который сейчас используется чисто под военные нужды.

О проекте гражданского сектора аэропорта "Бельбек" под Севастополем.

Открытые данные проекта гражданского сектора будущего аэропорта "Бельбек" были частично представлены сегодня на заседании градостроительного совета при правительстве Севастополя. Архитекторам показали визуализацию будущего гражданского терминала аэропорта, а также проекты планирования и межевания территории будущего объекта. "Мы предлагаем достаточно мощный проект с пропускной способностью до 600 пассажиров в час и годовой нагрузкой порядка двух миллионов человек", – рассказал представитель проектировщика (НИИ "Генплан Москвы"), комментируя документ. По словам докладчика, вредных воздействий со стороны будущего аэропорта не будет, и общий шумовой фон после ввода на военном аэродроме гражданского сектора останется в прежних показателях. "Мы предусматриваем парк и трёхполосный подъезд, бизнес-центр, гостиницу и сам вокзальный комплекс. Также в проекте заложена пустая территория для дальнейшего развития аэропорта", – рассказал докладчик. По его словам, документ составлен строго в рамках технического задания. К сожалению, членам градсовета Севастополя была представлена только часть проекта – так сказать, для ознакомления в общих чертах, поскольку полный документ имеет гриф секретности и со всеми его положениями можно ознакомиться только тем, кто имеет соответствующий допуск. Члены градостроительного совета одобрили представленный документ с рекомендациями поставить территорию, подпадающую под проектирование, на кадастровый учёт и предусмотреть в дальнейшем расширение всего аэропорта на перспективу.

http://sevastopol.su/news.php?id=90577 - цинк

Как будет выглядеть гражданский аэропорт "Бельбек" в Севастополе

Проект реконструкции и развития гражданского "Бельбека" предполагает создание новой авиатехнической базы, строительство контрольно-диспетчерского пункта, здания аэровокзала и грузового терминала. Также будут возведены: склады горюче-смазочных материалов, парковка для сотрудников, суточная парковка на 116 машин, стоянка для ожидающих на 896 автомобилей, бизнес-парк, гостиница, автовокзал, отстойно-разворотная площадка, аварийно-спасательная служба и очистные сооружения.









В границах проекта планировки территории будущего гражданского сектора аэропорта "Бельбек" находится объект историко-культурной ценности "Курганная группа Мамай-Оба-2", а на прилегающей территории располагаются могильник Усть-Бельбекский (Бельбек-Тамак) и Могильник 4-й сектор СОР-2. Также на прилегающей территории есть памятники и исторические объекты – братская могила воинов 315-й стрелковой дивизии и братское кладбище советских воинов 2-й гвардейской армии.
















NB! Видно, что делали в спешке - у проектировщиков и инвесторов время до ноября, когда должно быть принято решение о строительстве.

http://sevastopol.su/news.php?id=90590 - цинк

PS. В общем, если реализуют, будет замечательно - Бельбек всяко ближе Симферополя.

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





http://sevastopol.su/news.php?id=90564 - цинк

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

http://colonelcassad.livejournal.com/2975610.html

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

Переезд в Краснодар. Районы Краснодара.

Пятница, 23 Сентября 2016 г. 17:29 (ссылка)


Продолжаем тему переезда в Краснодар. Первую часть читайте здесь. Сегодня поговорим о наиболее крупных районах Краснодара. Эта статья будет полезна тем, кто собирается переехать в Краснодар и не может определиться, где купить или снять жилье, в каком районе Краснодара.  Краснодар включает в себя четыре административных округа: Центральный, Прикубанский, Западный и Карасунский. Каждый из них неофициально делится на районы, порой с причудливыми названиями, состоящими из аббревиатур.  У каждого района есть свои преимущества и недостатки. Но ключевыми аспектами при поиске жилья остаются: цена, инфраструктура, транспортная доступность. В Краснодаре строится очень много нового жилья. Город занимает одно из ведущих мест по темпам строительства в России. В связи с этим цены на жилье в Краснодаре ниже, чем в других городах, с примерно таким же количеством жителей.



Читать полностью…

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

Про HPE Synergy. Часть III – Дисковое хранилище D3940 и SAS-коммутаторы

Среда, 21 Сентября 2016 г. 08:32 (ссылка)

Продолжение, начало – Часть I (Вступление) — habrahabr.ru/post/308224

Продолжение, начало – Часть II (Шасси и сервера) — habrahabr.ru/post/310092



Дисковое хранилище SY D3940 – один из ключевых элементов Synergy; модуль оптимизирован для использования либо как DAS (Direct Attached Storage — система хранения данных с прямым подключением, т.е. диски подключаются напрямую к серверу, и какой либо уровень RAID организует установленный в сервере контроллер), либо как программно-определяемое хранилище, типа HPE StoreVirtual VSA (или подобное). Про HPE StoreVirtual VSA можно почитать тут — habrahabr.ru/post/308392, Алексей все весьма подробно описал. Лично меня в применении VSA смущает только ограничение в 50 Тб и требования по памяти.

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



В чем ошибка, если расположение дисков вроде верное, ведь по схеме в отсек №1 вставляем первый диск, в отсек №2 – второй диск и так далее?



Так да не так. В документе «HPE Synergy Configuration and Compatibility Guide» указан совсем другой порядок заполнения: «For proper air flow, drives must be populated from back to front. Per the drive numbering below, begin populating bays 33 through 40, and continue to populate back to front, finishing with bays 1 through 8.» На рисунке стрелками указано более правильное расположение дисков.



В чем причина нелогичной нумерации — не понятно.

Теперь про модуль. Как уже было сказано, он поддерживает установку в него 40 штук дисков SFF SAS или SATA. Нельзя (пока, по крайней мере) поставить в него SFF модуль с двумя uFF дисками, описанный во второй части «Шасси и сервера». Подозреваю, что эта функция никогда реализована не будет, так как адаптер-бокс 2 шт. uFF -> SFF имеет внутри себя RAID-адаптер, поддерживающий уровни RAID 0 и 1, а D3940 никаких адаптеров не имеет вообще, все диски из модуля презентуются адаптеру HPE Smart Array P542D Controller with 2GB FBWC, устанавливаемому в сервера. Кабели подключения и электропитания помещены в гибкий сегментированный рукав, который находится внизу модуля, при вытягивании модуля из шасси кабели разматываются, при обратной операции – сматываются, это позволяет не отключать модуль для обслуживания (для замены или добавления дисков, например).

Пример гибкого сегментированного рукава для пулемета




Подключение дисков к SAS-коммутаторам выполняют SAS I/O модули, по умолчанию устанавливается одна штука в отсек I/O 1, который работает с SAS-коммутатором HPE Synergy 12Gb SAS Connection Module, устанавливаемым в слот ICM 1. Если требуется отказоустойчивость, в отсек I/O 2 устанавливается второй I/O модуль, а в отсек ICM 4 – второй SAS-коммутатор, кроме того в каждый сервер, который будет работать с дисками D3940, требуется установить контроллер HPE Smart Array P542D именно в mezzanine slot 1. Сам модуль выглядит скучно, посмотреть его можно или на фото в первой части (установлен в ICM 1), или ниже:



На всякий случай еще раз схема расположения ICM(InterConnect modules):



Так же схема коммутации внутренних компонентов, которая поясняет почему подключения происходят так, а не иначе (The storage module is only supported for connectivity with fabric 1):



Compute module 1-12, имеется ввиду сервер SY 480 Gen9 HH (Half Height), как уже говорил, в нем три отсека для установки мезонинных карт.

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

Если брать неотказоустойчивую конфигурацию, то варианты будут следующие:


  • SAS Connection Module в отсеке ICM 1 подключается к основным I/O адаптерам для отсеков 1, 3 и 5;

  • SAS Connection Module в отсеке ICM 4 подключается к основным I/O адаптерам отсеков 7, 9 и 11;



Получается, если дисковых модулей планируется больше трех, то придется ставить и вторые I/O модули и второй SAS-коммутатор. Согласно документации, для трех и более полноразмерных серверов (FH – full height) и двух дисковых модулей также требуется второй SAS-коммутатор.

SAS-коммутатор имеет 12 внутренних SAS портов по 4х12 Гбит/с линка на порт и создает динамический виртуальный JBOD, который может подключаться к серверам внутри шасси. Отдельно надо отметить, что Фабрика 1 – неблокируемая, что позволяет набить дисковые модули SSD и радоваться колоссальным IOPs’ам и минимальному времени на чтение. Управляется SAS-коммутатор через Synergy Composer или сервер с OneView версии не ниже 3.0.

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

Вернемся к дисковому модулю D3940. Как уже говорилось, можно установить до 40 дисков SFF в модуль и до пяти модулей в шасси, итого — 200 дисков; внутри модуля можно устанавливать любые диски из перечисленных, но надо помнить, что логический массив может создаваться только на дисках одного типа. На данный момент список поддерживаемых дисков такой:

44 типа дисков, поддерживаемых модулем D3940

  • HP 500GB 6G SATA 7.2k 2.5in SC MDL HDD

  • HP 200GB 12G SAS ME 2.5in EM SC H2 SSD

  • HP 400GB 12G SAS ME 2.5in EM SC H2 SSD

  • HP 800GB 12G SAS ME 2.5in EM SC H2 SSD

  • HP 1.6TB 12G SAS ME 2.5in EM SC H2 SSD

  • HP 1.2TB 6G SAS 10K 2.5in DP ENT SC HDD

  • HP 600GB 12G SAS 10K 2.5in SC ENT HDD

  • HP 1.2TB 12G SAS 10K 2.5in SC ENT HDD

  • HP 300GB 12G SAS 10K 2.5in SC ENT HDD

  • HP 900GB 12G SAS 10K 2.5in SC ENT HDD

  • HP 800GB 12G SAS VE 2.5in SC EV SSD

  • HP 1.6TB 12G SAS VE 2.5in SC EV SSD

  • HP 300GB 12G SAS 15K 2.5in SC ENT HDD

  • HP 450GB 12G SAS 15K 2.5in SC ENT HDD

  • HP 600GB 12G SAS 15K 2.5in SC ENT HDD

  • HP 600GB 12G SAS 15K 2.5in SC 512e HDD

  • HP 100GB 6G SATA ME 2.5in SC EM SSD

  • HP 400GB 6G SATA ME 2.5in SC EM SSD

  • HP 800GB 6G SATA ME 2.5in SC EM SSD

  • HP 200GB 12G SAS WI 2.5in SC SSD

  • HP 400GB 12G SAS WI 2.5in SC SSD

  • HP 800GB 12G SAS WI 2.5in SC SSD

  • HP 1.92TB 12G SAS RI 2.5in SC SSD

  • HP 1TB 6G SATA 7.2k 2.5in 512e SC HDD

  • HP 2TB 6G SATA 7.2k 2.5in 512e SC HDD

  • HP 2TB 12G SAS 7.2K 2.5in 512e SC HDD

  • HP 1TB 12G SAS 7.2K 2.5in 512e SC HDD

  • HP 1.8TB 12G SAS 10K 2.5in SC 512e HDD

  • HPE 480GB 12G SAS RI-3 SFF SC SSD

  • HPE 960GB 12G SAS RI-3 SFF SC SSD

  • HPE 1.92TB 12G SAS RI-3 SFF SC SSD

  • HPE 3.84TB 12G SAS RI-3 SFF SC SSD — самый большой диск

  • HPE 400GB 12G SAS MU-3 SFF SC SSD

  • HPE 800GB 12G SAS MU-3 SFF SC SSD

  • HPE 1.6TB 12G SAS MU-3 SFF SC SSD

  • HPE 3.2TB 12G SAS MU-3 SFF SC SSD

  • HP 120GB 6G SATA VE 2.5in SC EV M1 SSD

  • HP 240GB 6G SATA VE 2.5in SC EV M1 SSD

  • HP 480GB 6G SATA VE 2.5in SC EV M1 SSD

  • HP 800GB 6G SATA VE 2.5in SC EV M1 SSD

  • HP 1TB 6G SATA 7.2k 2.5in SC MDL HDD

  • HP 146GB 6G SAS 15K 2.5in SC ENT HDD

  • HP 500GB 6G SAS 7.2K 2.5in SC MDL HDD

  • HP 1TB 6G SAS 7.2K 2.5in SC MDL HDD





Поддерживается 44 типа дисков, причем по типу HDD примерно 45%, и примерно 55% — SSD.

Максимально один дисковый модуль может предоставить 153,6 Тб (в виде 40 шт. HPE 3.84TB 12G SAS RI-3 SFF SC SSD в RAID0), или 768 Тб – пять модулей (максимум) на шасси.

Отдельно надо упомянуть контроллер HPE Smart Array P542D, который устанавливается в сервер и управляет подключаемыми к нему дисками. Он имеет на борту 2 Гб кэш-модуль DDR3-1866 MHz, 16 портов 12 Гбит/с SAS (2х4 внутренних, и 2х4 внешних), но есть следующие ограничения – 404 Тб на один логический диск и 64 логических диска на контроллер. На хосте подключенный контроллер отъедает 4,4 Гб памяти. Поддерживает уровни RAID 0, 1, 10, 5, 50, 6, 60, 1 ADM, 10 ADM.

У этого контроллера есть одна опция, приобретаемая отдельно – HPE SmartCache – позволяет организовывать многоуровневое хранение данных (tiering), т.е. при частой востребованности данных перемещает их на более быстрые SSD. Состоит, соответственно, из медленных HDD и быстрых SSD, подключенных к контроллеру, и мета-данных о востребованности блоков информации с массива, которые держит в FBWC (Flash-backed write cache, флеш-буфер записи, тот самый модуль 2 Гб DDR3). Лично я этот функционал не тестировал, было бы интересно посмотреть как выставляются уровни «температуры» данных и как контроллер справляется с «дрожанием» этого уровня.

Все это великолепие управляется с помощью SY Composer’а и на этом обзор этой части будем считать завершенным.

В завершении осталось описание сетевой части (самая сложная для меня), модулей управления (самая непонятная) и принципов построения и управления (самая интересная).
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/310564/

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

На двух улицах Калининграда запретят остановку транспорта

Вторник, 20 Сентября 2016 г. 10:13 (ссылка)
freekaliningrad.ru/on-two-s..._articles/

10-11 октября 2016 года на улицах Генерала Галицкого
и Диккенса будут установлены дорожные знаки
«Остановка запрещена» и таблички «Работает
эвакуатор».
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Вызовы поискового облака. Лекция в Яндексе

Суббота, 17 Сентября 2016 г. 18:48 (ссылка)

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







Руководитель группы экспертизы runtime поиска Олег Фёдоров был в числе докладчиков на большой поисковой встрече Яндекса, которая прошла в начале августа. Он рассказал обо всех основных аспектах проектирования дата-центров под задачи, связанные с обработкой огромных объёмов данных. Под катом — расшифровка и слайды Олега.



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



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



Вызовы поискового облака. С чем мы сталкиваемся? Какими принципами руководствуемся, когда строим наши большие системы?







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







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



Чем будем тестировать? Возьмем типичные для облака задачи, которые будут работать на наших серверах чаще всего: поиск, кусочек индекса, что нам выдача рисует, еще что-то. Возьмем все эти образцы, поищем аномалии.



Был яркий пример: мы взяли модель процессора одного из производителей и у нас очень сильно просело время отрисовки. Сюрприз. Разобрались: действительно, там была проблема с компилятором, но тем не менее аномалия может возникнуть. Другой пример: производитель заявил новый набор SSE-инструкций, мы немножко переписали наш код – стало существенно быстрее. Это некое конкурентное преимущество нашей модели, все хорошо.



Чуть углубимся. Допустим, мы выбрали некий набор процессоров. Вот мои любимые картинки для привлечения внимания. Это у меня недавно iPhone перегрелся.







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



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



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



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



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







Из этого правила всегда есть исключение. Мы хотим для некоторых не массовых приложений, где очень критично latency, получить максимальную производительность на ядро. Либо мы хотим что-то быстро в онлайне собирать, рисовать и т. д — мы можем позволить себе взять несколько процентов исключительного оборудования.



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



Вторая картинка для привлечения внимания:







Многие, наверное, узнали распределение в реликтовом излучении — так мы пытаемся компьютерно смоделировать, как выглядит наша Вселенная. Данные выглядят примерно так же. Есть очень горячие участки. Например, сайтик «ВКонтакте» почему-то все ищут — не знаю, почему. Или каких-то котят. Эти данные очень горячие, часто используемые, их очень хочется положить в память куда-нибудь поближе к процессору и т. д. А есть какие-нибудь драйвера. У меня предыдущий ноутбук уже лет 10 лежит, и для него, под старую Ubuntu, нужны были драйвера. Почему-то ни у кого, кроме меня, этот запрос долгое время не возникал. Я пытался по логам поискать – никто не интересуется. Эти данные, наверное, никому не нужны — положу куда-нибудь подальше, на холодные диски с маленькой сложной репликацией и т. д.



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







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



Подход такой: выберем приложение в нашем облаке, которое требует какого-то специфического железа, например GPU. Понятно, что GPU поставить в каждый сервер — это мечта, но достаточно дорогостоящая. Разместим наши приложения, требующие специфического железа, на тех серверах, где такое железо есть. Это шаг номер один.



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



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



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







Какие есть подходы в индустрии? Все слышали, а кто-то, у кого ноутбук на Linux, пробовал накрутить, настроить себе cgroups неким образом, чтобы оградить приложение, выставить ему лимиты и чтобы все было более-менее хорошо.



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



К чему все приходят? К маленькому тонкому слою — контейнеру, ограждающему приложение.



Когда мы затевали эту историю в нашем облаке, Docker еще не был настолько развит. Его современные обвязки впечатляют — работы было проделано очень много. Мы сделали свою очень похожую штуку. Назвали Porto. Нам хотелось легко управлять сотнями — уже тысячами — приложений: чтобы они друг другу не мешали, чтобы процесс конфигурирования был очень простой и чтобы мы в каком-то смысле описали все лимиты приложения, поняли, как оно будет работать, что ему требуется, где ему нужно хранить данные, какой у этого приложения выделенный IP-адрес. То есть нужно было описать все, что связывает нас с многомерным пространством, запустить этот контейнер и забыть про него.



С другой стороны, с точки зрения самого приложения оно находится практически в виртуальной машине. У него свой маленький chroot, виден не весь процессор и не вся оперативка. Получили плюсы в своей простоте в системе деплоя, получили учет ресурсов. Нам не очень интересно, что приложение делает внутри себя, какие подпрограммы запускает, что делает с данными и т. д. Нам интересно, что происходило вокруг этого приложения, то есть счетчики с контейнера. А в качестве еще одного приятного бонуса мы получили возможность запускать вложенные подконтейнеры. Мы выделили на какую-то задачу или проблему набор ресурсов и дали имя этому контейнеру — всё. Дальше приложение может внутри себя как-то перераспределить пространство и запустить подпрограммы тоже в подконтейнерах, тоже изолированно. В результате получаем нашу прекрасную подводную лодку, где каждый отсек изолирован. Если у кого-то где-то утечка, что-то взорвалось, то оно взорвалось только там — локально.



Итак, мы всё заизолировали, всё напланировали в кластеры. А как находить, где работают инстансы приложения?



Как мы решаем задачу дискавери? Есть несколько подходов. Один наиболее типичный: приложение запускается, стучится куда-то в центральную точку, говорит — я здесь, я буду обслуживать такой-то трафик, я такого-то типа, у меня все хорошо. Наш подход очень похож на этот. У нас интеграция с системой мониторинга. Когда система видит, что на машине запущено приложение определенного рода, она у себя сохраняет его некое мета-описание. Когда другие приложения будут после этого искать для себя список бэкендов, они смогут воспользоваться этим описанием.







Всё у нас прекрасно. Мы на подводной лодке, всё заизолировали и т. д. Но тут у нас всё начинает ломаться. Представим себе, что мы работаем в таксопарке. У нас сто такси. Всегда будет так: у одной машины колесо спустили, другую водить никто не может, руль странный и т. д. Несколько машин всегда будет сломано. Надо привыкнуть к тому, что несколько процентов наших приложений — узлов системы — всегда будут сломаны. Это нужно закладывать на этапах расчета репликаций, нагрузок на каждом узле и т. д.



Что может ломаться? Если мы написали не совсем хорошую версию приложения – она, понятное дело, падает. Обрабатывает определенное количество запросов и падает. На тесте не нашли — в облаке увидели. Ломается ОС. Возьмем новый супер-секьюрити апдейт, ни на что в рантайме не влияющий. Выпустим его — приложения начнут падать, потому что мы что-то задели в ядре. Будет ломаться наш сервер. Он в аптайме работал два года, все было замечательно, но начала теряться оперативка, стали выпадать диски и т. д.



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



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



Но и целиком, бывает, ломается дата-центр. Как вы думаете, в какое время года чаще всего по сети отваливаются дата-центры и страдают каналы связи?



— …



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



Давайте попробуем расклассифицировать проблемы нашей аварии. Вот ребята уронили спутник на пол, беда.







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



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



Катастрофа — когда из строя вышли 15-20% узлов. Тут уже явно что-то пошло не так, уже нет смысла релизить программы, что-то выкатывать, переконфигурировать. Надо снимать нагрузку, предпринимать более активные действия. Это не жизнеспособная ситуация. Наверное, многим знаком такой подход.







Что в таких случаях можно делать? Начнем с простого. У нас ломаются машинки. Они могут ломаться просто программно. Завис сервер. Надо уметь это детектировать, уметь пробовать общаться с этим сервером по IPMI, чтобы что-то с ним сделать. Мы работу наших систем мониторинга, обнаружения неисправностей и попытки исправить, написать заявку в дата-центре представляем как мультик про робота WALL-E. Такие роботы ездят по кластеру, всё пытаются починить и в некую центральную точку сообщают о том, что у нас происходит. Итак, первый подход — автопочинка.



Как еще можно бороться с тем, что все все время ломается? Есть пессимизация бэкендов. Предположим, у нас есть приложение А, оно ходит в 10 бэкендов приложений В. Один из бэкендов вдруг начинает отвечать ощутимо медленнее, на 100 мс. Мы можем спокойно запессимизировать этот бэкенд, начать задавать в него сильно гораздо запросов — продолжать задавать, чтобы мониторить его состояние, но перевести запросы на оставшиеся живые-здоровые 9 бэкендов. Ничего не произойдет – все хорошо. Мы учим наши приложения быть аккуратными, уметь понимать, что под нами бэкенд и что у него что-то случилось.



Вот другой подход. Приложение А стало в приложение В слать трафика в разы больше, чем мы рассчитывали. Удобно уметь отключать часть своей функциональности и начинать отвечать, может, еще вполне корректно, но гораздо более низкозатратно с точки зрения CPU. Например, чуть менее глубоко искать, если говорим о поиске. Мы не 1000 документов поднимаем, а 900, потихоньку отодвигаем границу. Это вроде незаметно, но мы существенно увеличиваем свою пропускную способность в тот момент, когда нам это действительно нужно. Это деградация.



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



Как понять, что все наши приложения умеют, работают и спроектированы по этой схеме? Нужно регулярно проводить учения: отключать узлы, отключать большое количество серверов, отключать дата-центры. Это должно происходить неожиданно для команд этих приложений — чтобы не было историй, будто мы манипулируем нагрузкой или еще чем-то. Это должна быть честная нормальная авария, но с возможностью быстро вернуть все в первоначальное состояние. Мы не ждем, когда наступит весна и нам экскаватором переедут один из каналов. Мы его отключим сами и посмотрим, что произойдет. Разрезаем свою инфраструктуру — смотрим, что получается.







Хьюстон, у нас проблема. Мы диагностировали проблему до состояния, когда это уже не рутина, а именно проблема — 5-7% или катастрофа. С этим обязательно надо разбираться. На что смотрят типичные инженеры поиска? Не идет ли сейчас какой-то релиз или запуск? Наверное, если приложение сутками, неделями работало хорошо и все было прекрасно, а сейчас вдруг, в час дня, просело время ответа, то что-то поменялось. Вероятно, состоялся релиз, запуск.



На что мы стараемся смотреть? Для меня наиболее типичной, крупной для поиска показательной частью является количество запросов. Казалось бы, в каждый момент времени в течение дня можно предсказать, сколько запросов нам зададут. Вчера в 8:30 и сегодня в 8:30 количество запросов будет примерно одинаковым. Если же их будет на 20% меньше — наверное, что-то пошло не так.



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



Качество поиска. Безусловно, пользователи нам постоянно задают миллионы запросов. Мы сами себе задаем запросы, сами смотрим выдачу, в автоматическом режиме ее разбираем, анализируем и смотрим, насколько она близка к тому, что мы считаем эталоном.



Интересным показателем в последние годы стало распределение по браузерам. Много стало различных браузеров. От истории с Netscape Navigator, когда практически нечем было пользоваться, давно ушли. Появились браузеры в мобильных. Мы смотрим, что у нас происходит в каждом отдельном браузере. Возрастает ли количество запросов? За сколько мы отвечаем? Что интересует пользователей, какие тематики? И т. д.



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



Еще пример из недавнего прошлого. 15 июля вечером было крупное новостное событие в Турции, политическая ситуация. Не будем сейчас вдаваться в подробности. Нам интересно, как это на интернете сказалось. Люди начали активно что-то искать. Голубая линия показывает, что происходило в это время неделю назад, а темно-синяя — что происходило в текущий момент времени. Мы видим резкий всплеск интереса — в мире что-то произошло.







Смотрим наш типичный график времен ответа. Время ответа мы очень любим смотреть квантилями: нарезаем себе разными цветами 100 мс, 200 мс и т. д. Видим, что в смысле времени ответа за указанный промежуток времени ничего не случилось. А вот наша трафик-генерация на масштабе дня. Что было неделю или две назад, мы тоже видим. Простым аналитическим способом мы поняли, что это внешнее событие. Затем, как и все, пошли смотреть новости. Увидели, что происходит.



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



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



Зритель:

— У вас показатели мониторятся автоматизировано или сидят специально обученные люди, которые смотрят за графиками?



Олег:

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



Андрей Стыскин, руководитель управления поисковых продуктов Яндекса:

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



Зритель:

— Денис, компания Startup Makers. Два года назад Google выпустила свое open source solution — Kubernetes. Оно очень похоже на Porto. Смотрели на это решение?



Олег:

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



Андрей:

— В перерыве мне задали примерно такой же вопрос, но про несколько другой компонент. Действительно, в Яндексе существует большой синдром NIH — not invented here. Это происходит не потому что мы такие самодуры, а потому что нам приходится находить решения к задачам, которые параллельно решают западные или другие передовые компании. И они пока не успевают выложить свои решения в open source к тому моменту, когда они нам нужны в готовом виде.



Porto мы начали разрабатывать и написали под него обширную обвязку — конечно, несовместимую с Docker. Хотя там много чего прикольного сделано.



Зритель:

— Docker сейчас не единственный.



Андрей:

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



Зритель:

— Вопрос не в том, почему не используете Kubernetes. Наоборот, молодцы, и будет здорово, если получится лучше, чем у Google. Service discovery — не совсем раскрыта тема. Когда появляются контейнеры, эти поды, некая группа, некий онлайн — куда они дальше стучатся? Я так понимаю, там не какое-то etcd-хранилище, key value, а что-то свое сделано?



Олег:

— Нам больше нравится подход, когда система мониторинга находит такой контейнер, потому что все равно хочет мониторить там приложение и т. д. И заодно — собирает мета-данные, узнает, что за приложение там запущено, агрегирует и дает другим приложениям возможность находить исходное. Немножко обратный подход — не push, а call.



Зритель:

— Да, по метрикам реверс получается. Сейчас метрик по конкретным контейнерам вроде не так много. Это как-то у вас расширяется? Механизм расширения этого предусмотрен?



Олег:

— По контейнерам сотни метрик. Часто используемых — около десятка. Но в целом это очень кастомизированная система.



Зритель:

— У Kubernetes есть Kube Dash, много решений, которые позволяют легко что-нибудь развернуть у себя. И оно работает. На CoreOS, допустим, поставил. А какие-то UI-решения для облаков, для AWS и прочих, у вас собираются в общество выводить, соединять с комьюнити?



Олег:

— Хороший вопрос, спасибо. Смотрите, чуть в историю. У нас некий аналог закона Мура: вообще за историю Яндекса в прошлом каждый раз, когда количество серверов на порядок возрастает и мы берем новую задачу и понимаем, что нам будет интересно, мы каждый раз начинаем перепроектировать свою систему деплоя и всего остального. Потому что накапливаем существующие минусы.



В UI некий прогресс тоже налицо. Понятно, что, когда у нас есть сто запущенных приложений, очень легко написать UI и следить за ними всеми. А вот когда у нас есть 100 млн запущенных приложений, то уже возникает проблема, как их единоразово показать, сагрегировать, чтобы ничего не тормозило. Это каждый раз меняется.



Относительно планов вывести в люди — боюсь, конкретные сроки не могу назвать.



Андрей:

— Сроки не можем назвать, но спасибо правительству нашей страны. Оно нас подталкивает к таким решениям и говорит: «А давайте вы, все западные компании, будете хоститься в России?» Конечно, у нас есть планы сделать доступные облака в России на нашем железе, на наших дата-центрах, и немного монетизировать остатки мощностей, которые у нас есть.



Зритель:

— Это очень ожидаемо, хотелось бы увидеть.



Андрей:

— В стране самая дешевая в мире ожидаемая электроэнергия. Система, которая занимается деплоем, называется у нас «Няня».



Зритель:

— Данил, выпускник МАИ. Вопрос ближе к риторическому. Вы всегда говорите, что надо быть готовым, что система будет ломаться, и надо быть готовым к починке. У вас есть различные методы для исправления различных поломок. Можно ли и нужно ли стремиться к тому, чтобы ничего не ломалось относительно внутренних причин — не считая внешних?



Олег:

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



Андрей:

— Но ломаться все равно будет.



Олег:

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



Зритель:

— То есть в будущем нельзя будет сказать, что от этого можно спокойно защититься?



Олег:

— Можно стараться уменьшать показатели, но рассчитывать на это не нужно.



Зритель:

— Ярослав Нечаев, Фонд Бруно Кесслера. Про Porto. Большой ли overhead у Porto и дорого ли обходятся все эти фичи вроде вложенных контейнеров, изоляции?



Олег:

— В этом ключе Porto очень похож, это в каком-то смысле cgroups на стероидах. Какой пак дают cgroups — столько же примерно дает и Porto.



Зритель:

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



Олег:

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



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



Андрей:

— Здесь есть интересный и важный момент. Например, когда мы эмулируем перерубание кабеля с дата-центром и происходят учения для всех сервисов — а в данном дата-центре в текущий момент можно поменять диски, еще что-то сделать… Так вот, все это синхронизовано с плановыми работами по апгрейду машинок в дата-центрах и позволяет получить информацию, что, скажем, сервис Яндекс.Музыка не переживает отключение одного дата-центра. После этого в нем надо запланировать инфраструктурные изменения.



Олег:

— Наши коллеги из НОК, операторы сети, очень любят совмещать свои работы с нашими учениями. Потому что некоторые железки, которые работают 24/7/365, очень удобно вывести на какое-то время из эксплуатации. Затем можно произвести какие-то обновления. Это еще один существенный фрагмент сетевой инфраструктуры.



Зритель:

— Владимир Цитис. При анализе диагностики неисправностей Яндекс пользуется исключительно естественным интеллектом или есть какие-то инструменты на базе искусственного интеллекта?



Олег:

— Хороший вопрос. Каждый наш узел мониторится: как приложение, так и мы стараемся мониторить наше железо. Предположим, какой-то показатель вышел за граничные условия, что-то происходит не так. И есть некая умная агрегация: если у нас в какой-то части дата-центра на 90% серверов выросла температура, то, наверное, это не 90% серверов сломалось и у них какой-то перегрев, а что-то не так с охлаждением в этом кусочке. Мы производим такого рода анализ.



Андрей:

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



Олег:

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



Зритель:

— Алексей Старцев, «Релевант Медиа». Примерно какая доля человеческого фактора влияет на все критические ситуации, возникающие в Яндексе?



Олег:

— На моей памяти были интересные истории с человеческим фактором. Но все-таки мы практически во всех местах стараемся сделать так, чтобы действия человека могли привести к катастрофе только в одном отдельно взятом месте — чтобы нельзя было легко и удобно из одной консоли последовательно потрогать все инфраструктуры одного рода. Все это должно происходить очень локально — в одном ДЦ, в одном месте и т. д.



Да, в основном ошибаются люди, а не роботы, известный факт. Доля — скажем, 50% внешних факторов, природных или посевных, и, может, 50% внутренних действий.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/310258/

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

Как уехать в Геленджик

Воскресенье, 11 Сентября 2016 г. 13:12 (ссылка)

Геленджик – небольшой курортный город на черноморском побережье России. Население городка составляет всего около 50 тысяч человек. Летом количество людей на улицах увеличивается в десятки раз. На этот чистый уютный курорт с развитой инфраструктурой приезжают отдыхающие со всех концов России. Найти жилье здесь можно на любой вкус и кошелек. Поэтому город готов предоставить возможность отдохнуть и олигархам, и студентам, и парам с детьми, и тем, кто предпочитает «дикий» вариант отдыха. ЧИТАТЬ ДАЛEE>>>



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

Как узнать программу ЭКСПО-2012

Четверг, 09 Сентября 2016 г. 00:36 (ссылка)

Выставка под названием Event Expo проходит на одной из наиболее перспективных и крупных площадок России с достаточно мощной инфраструктурой. Это МВЦ «Крокус Экспо» (Московская область). Программа в этом году будет очень насыщенной. ЧИТАТЬ ДАЛEE>>>



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

В Харькове установят видеонаблюдение за объектами инфраструктуры.

Понедельник, 05 Сентября 2016 г. 12:59 (ссылка)
city.kharkov.ua/ru/news/-32967.html


В Харькове планируют принять программу «Безопасный город» на 2016-2020 годы.



Об этом сегодня, 2 сентября, на заседании постоянной комиссии по вопросам транспорта, связи и экологии Харьковского городского совета сообщил директор Департамента жилищного хозяйства Роман Нехорошков.



По его словам, программа предусматривает приобретение видеокамер и программно-аппаратного комплекса, которые позволят осуществлять наблюдение за стратегическими объектами.



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



По его  словам, первая камера будет установлена до конца года на пл. Свободы, а потом начнется установка на объектах КП «Харьковводоканал», КП «Харьковские тепловые сети», объектах транспортной инфраструктуры и т.п.



Роман Нехорошков не исключил, что в дальнейшем такое видеонаблюдение будет внедряться и на жилых домах.



videonabludeniye (621x323, 41Kb)


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

Как выбрать отель в Хургаде

Воскресенье, 04 Сентября 2016 г. 14:32 (ссылка)

Как выбрать отель в хургаде. Хургада – пожалуй, самый популярный египетский курорт. Здесь неплохие пляжи, чистейшее Красное море, хорошая инфраструктура, доступные цены и множество отелей. Но чтобы не ошибиться в выборе, надо учитывать, где находится гостиница и работают ли ее менеджеры с туристическими фирмами. ЧИТАТЬ ДАЛЬШЕ>>>



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

Как встретить Новый год в Вологде

Воскресенье, 04 Сентября 2016 г. 13:08 (ссылка)

Вологда - старинный русский город. Но в нем хорошо развита инфраструктура развлечений. Там открываются все новые и новые клубы, боулинг-центры, бильярдные. Встретить Новый год весело можно в одном из этих заведений или отправившись в лес на пикник. ЧИТАТЬ ДАЛЬШЕ>>>



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

Как купить дешёвую квартиру

Суббота, 03 Сентября 2016 г. 04:05 (ссылка)

Как купить дешёвую квартиру. Если вы хотите купить дешевую квартиру, то важно знать из чего складывается ее стоимость. Она исходит из многих факторов. Наличие при покупке цепи посредников, благополучия района, степени удаленности от центра города, возраста дома, в котором находится данная квартира, развития социальной инфраструктуры района. ЧИТАТЬ ДАЛЬШЕ>>>



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

Как узнать программу ЭКСПО-2012

Пятница, 03 Сентября 2016 г. 02:30 (ссылка)

Выставка под названием Event Expo проходит на одной из наиболее перспективных и крупных площадок России с достаточно мощной инфраструктурой. Это МВЦ «Крокус Экспо» (Московская область). Программа в этом году будет очень насыщенной. ЧИТАТЬ ДАЛЬШЕ>>>



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

Как купить новостройку

Пятница, 02 Сентября 2016 г. 19:56 (ссылка)

Покупка квартиры в новостройке - выгодное решение. Такие квартиры, как правило, отличаются большей площадью и улучшенной планировкой. Новые микрорайоны, в которых возводятся новостройки, обладают лучшей инфраструктурой, чем старые. Рассмотрим алгоритм покупки квартиры в новостройке. ЧИТАТЬ ДАЛЬШЕ>>>



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

Как найти дом в деревне

Пятница, 02 Сентября 2016 г. 17:54 (ссылка)

Мечта многих горожан - уехать подальше от шума, грязи и пыли. Если не навсегда, то хотя бы на выходные. И покупка дома в деревне - прекрасный выход. Ведь там, в отличие от только что возведенных дачных поселков, присутствует вся необходимая инфраструктура и практически всегда есть центральные коммуникации или способ быстро их подключить. ЧИТАТЬ ДАЛЬШЕ>>>



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

Рефакторинг банковской ИТ-инфраструктуры и как мы дружили ИТ-команду с ИБ-командой

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





Один банк, российский филиал крупной европейской банковской группы, поставил перед нами задачу сегментировать сеть. Его серверы были расположены в наших дата-центрах. На момент начала работ у заказчика была отдельная инфраструктура для собственно финансовых операций и физически отделённая от неё большая одноранговая сеть пользователей на пару крупных узлов и множество филиалов. Первая работала как часы, а со второй были сложности. Кроме того, как раз начиналась внутренняя реорганизация под требования 152-ФЗ о персональных данных.



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



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



Так мы начали разбирать весь трафик сети.



Первый этап: «свой-чужой»



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



О внедрении мы договорились на тот момент, когда 95% трафика за две недели попадут под правила. Остальные (это, как правило, мелкие разовые транзакции по несколько килобайт) измерялись тысячами и типизации поддавались с трудом. Можно было бы потратить всю жизнь на изучение этого трафика: он вёл себя как бесконечная непериодическая дробь — менялся постоянно. Предполагалось, что если что-то пойдёт не так с этими мелочами (напомню, в пользовательской подсети), то просто потребуется новое правило для файрволла. Весь описанный трафик добавлялся в разрешения для файрволла. Если бы возникло что-то новое, оно бы по умолчанию отсекалось и предлагалось бы для анализа ИТ-команде и ИБ-специалистам.



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



Сюрпризов в зоопарке нашлось много. Что ещё важнее — даже крупные объёмы трафика вели себя непериодически, причём некоторые сервисы показывали себя далеко не сразу. Только через 4 недели мы вышли на покрытие 95% в таблице по итогам недели, и через три месяца добились того, что в новых неделях не «всплывало» ничего неожиданного.



За неделю через файрволл проносился примерно терабит трафика. Характер менялся достаточно часто, и по мере определения трафика постоянно требовались новые наборы правил. Например, несколько недель у нас не было трафика до одной из групп IP-адресов, а потом он неожиданно пошёл. Как выяснилось, это были сервера с данными видеонаблюдения: скорее всего, кто-то где-то в нашей необъятной стране накосорезил, и потребовалось перерыть несколько недель видеозаписей из центрального офиса. Естественно, это создало довольно незнакомую для нас нагрузку на сеть. Или был один филиал, который скидывал свою файлопомойку в бекап раз в несколько недель, например, и поэтому за недельный период можно было не поймать эту важную для него операцию.



Безопасники разделили сервисы на критичные и не очень, то есть разметили приоритеты рисков.







Второй этап: как делить



Получалась большая матрица, которая, по сути, содержала правила для файрволла. Кстати, мы написали очень удобный скрипт, который из XLS-файла для ИБ и ИТ-команд, после того как они подписывали, что есть что, делал набор правил прямо для имплеметнации на файрволл. Ставят плюс в Excel-таблице — разрешили трафик, ставят минус — режем.



Когда прогнозируемый режим работы по покрытию 95% трафика начал совпадать с фактическим (в рамках зеркального подключения), стало ясно, что работы по определению трафика окончены. Безопасники получили набор документации, что и куда ходит (и, кажется, были очень рады, что кто-то разобрал это всё за них). ИТ-служба также очень радовалась, что получилось добиться показателя в разумные сроки.



Теперь нужно было разделить сеть. Базовых подходов в таких случаях несколько:


  1. Классический, по географии: у каждого офиса своя подсеть, они объединяются в региональные подсети, а затем попадают в общую сеть компании.

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

  3. Упрощённая сегментация: топы и всё критичное в одну подсеть, пользователи — в другую.

  4. Атомарная сегментация — это когда на каждую проектную группу назначается своя подсеть. Например, сидят 2–3 человека в комнате, занимаются только обслуживанием чего-то одного — раз подсетка. Их соседи — два подсетка, и так далее. Это, на самом деле, рай для безопасников — им так удобнее всего контролировать людей, но ад для тех, кто должен это поддерживать.

  5. Функциональная сегментация: пользователи объединяются по тому, что они могут делать, а что не могут (независимо от географии), то есть, по сути, даётся 6–10 основных ролей.



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



Привлекли HR-отдел, который предоставил штатное расписание. Вместе с ИТ и ИБ определили роли каждому сотруднику, назначили ему его подсеть — и снова добавили в правила на «большую железку». Опять же в течение пары недель смотрели на зеркальном трафике, правильно ли всё обрабатывается.



Кроме «человеческих» ролей у нас были и другие — например, принтеры в группу «принтеры», сервера в группу «серверы» и так далее. Каждый ресурс оценивался по критичности для бизнес-процессов ещё. Например, файлшара, DNS и Radius-сервера были признаны обычными, а сервера, выход из строя которых «клал» бухгалтерию, например, критичными.



Третий этап: внедрение



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



Сюрприза не произошло, переключение прошло ожидаемо штатно. Мы написали исполнительную документацию с настройками и сдали систему в эксплуатацию.



Возвращаясь чуть назад, на этой стадии была только одна небольшая сложность: ИТ-команда считала, что файрволл — это их сетевой узел, и рулят им они. Безопасники же видели это как узел обеспечения доступа (что-то вроде СКУД для данных) и считали, что это полностью их устройство. К счастью, мы настроили и тем и другим необходимые роли на железке: безопасники не трогают конфиги сети, а ИТ-команда не может прописать новые разрешения неожиданно для ИБ (собственно, такие случаи и стали причиной того, что безопасникам нужна была актуальная карта трафика — много чего делалось «на горячую бету» мимо них и навсегда оставалось в продакшне).



Итоговый график такой:









































Название этапа





Продолжительность





Комментарий





Подготовка технико-коммерческого предложения





1 неделя





Это очень быстро для интегратора





Подписание договора





1 неделя





Это очень быстро для банка





Разработка проектной документации





1 месяц





+ время на согласование с заказчиком (это 2–3 недели), включая корректировку документов. Здесь мы параллельно проводили мониторинг сети, который длился 4 недели. Изменения сразу заносились в документацию





Монтаж и пуско-наладка оборудования





3 недели





Так как работы выполнялись на 4 площадках заказчика в согласованные «окна», процесс занял такое время





Опытная эксплуатация





3 месяца





Для достижения целевых показателей было необходимо провести итерационный процесс по настройке правил на МСЭ





Итоговые испытания, ввод в промышленную эксплуатацию





1 день





Переключение







Итоговая архитектура:







Основная железка — Palo Alto 3020. Их 6 штук на 4 объектах. Две штуки на большие офисы (подключённые отказоустойчивым кластером), по одному — на дата-центры (это два наших ЦОД, где расположена ИТ-инфраструктура банка). В ЦОДах файрволлы подключены в прозрачном режиме, а не кластером, поскольку сама по себе архитектура двух дата-центров и является большим кластером по сути.



Ссылки:



Наш код скрипта преобразования требований заказчика в сетевые правила пошёл между нашими же инженерами по руками — прикольная штука, экономит время.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/308886/

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

Следующие 30  »

<инфраструктура - Самое интересное в блогах

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

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