В начале мая 2016 года, еще до окончания объединения с Dell, компания EMC объявила о выходе нового поколения массивов среднего уровня под именем Unity. В сентябре 2016 года к нам привезли демо-массив Unty 400F в конфигурации с 10 SSD дисками на 1.6TB каждый. В чем различие между моделями с индексом F и без оного можете почитать по данной ссылке в блоге Дениса Серова. Так как перед передачей демо дальше заказчику возник временной лаг, то было принято решение погонять массив тем же самым тестом, которым ранее уже нагружались VNXe3200 и VNX5400. Что бы посмотреть хотя бы на «синтетике» так ли хорош Unity по сравнению с предыдущими поколениями массивов EMC, как это расписывает вендор. Тем более что, судя по презентациям вендора, Unity 400 является прямой заменой VNX5400.



А DellEMC утверждает, что новое поколение по крайней мере в 3 раза производительнее, чем VNX2.
Если интересно, что из всего этого вышло, то…

Концепция программно-определяемых ЦОД появилась очень давно. Тем не менее, на практике мало что было реализовано и работало, разве что у IaaS-провайдеров. По факту чаще всего была обычная виртуализация. Теперь же можно шагнуть дальше на стеке VMware, а можно реализовать всё на Openstack — тут придётся думать головой и взвешивать много факторов.

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

Зачем это нужно? Очень просто: начиная с автоматизации рутины, отвязывания зависимости от физического железа; точно знать потребление каждого ресурса; знать до копейки, и заканчивая тем куда и как идут деньги в IT-бюджете. Последние две причины лежат немного за пределами обычных админских целей, но очень полезны для CIO или сисадминов среднего и крупного бизнеса, рассчитывающих на полное взаимопонимание с коммерческим отделом. И премию, чего уж там.

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

Обязательства по госконтракту для этого дата-центра мы тогда выполнили.

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

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


Источник: http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures

Важность этого момента трудно переоценить, его можно сравнить с быстрой сменой исторической формации. Эра владычества HDD стремительно уходит в прошлое. И одним из вестников этого процесса стала DSSD D5 — высокопроизводительное хранилище стоечного класса на flash-накопителях (RSF, Rack-Scale Flash).

Летом прошлого года мы писали о наступлении эпохи гиперконвергентности в индустрии систем хранения данных. И в соответствии с веяниями времени и потребностями клиентов мы представляем новый продукт — полностью интегрированную, сконфигурированную и протестированную гиперконвергентную систему VxRail, созданную на базе vSphere и Virtual SAN.

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

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

Если совсем коротко, то VxRail это «в одном флаконе» высоконадежный масштабируемый серверный кластер VMware, плюс СХД, плюс управляющий софт, плюс защита данных, плюс интеграция с облаком, плюс 200+ автоматизированных типовых задач.

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

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

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Кладбище мессенджеров, на котором обязательно должны оказаться Skype, Viber, WhatsApp, Hangouts, ooVoo, Apple iMessage, Telegram, Line, Facebook messenger и еще сотни мессенджеров, которым только предстоит выйти в ближайшее время.

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

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

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

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

Новинки в области хранения данных — это одна из наших любимых тем. Сегодня мы решили взглянуть на технологии многослойных дисков с большой емкостью.

В прошлый четверг наш сервис пережил крупнейшую аварию в своей истории. Одна из инсталляций на М9 оставалась недоступной из внешней сети в течение нескольких часов. Что случилось? Что делать? Как должен поступить ответственный вендор? Как сохранить репутацию вендора телефонной платформы №1?

Считается, что вовремя исправленная ошибка уже не является ошибкой. Что же, проверим правильность афоризма на практике. Обычно маркетологи пишут план публикаций на месяц вперед и идеология каждого поста — это что-то вроде мотивирующего “Быстрее, выше, сильнее”. Так принято и мы не исключение, но на этот раз отойдем от маркетинговых догм и честно расскажем о появившейся проблеме без шелестящих предновогодних PR-оберток.

Ранее мы рассматривали закон Мура применительно к конкуренции между Intel и IBM. Сегодня мы решили обратить внимание на сферу хранения данных и проанализировали заметку Wired.

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

Железо, в целом, неплохое, просто прошлого поколения. Выкидывать, естественно, было жалко. Тогда я и предложил протестировать EMС ScaleIO. Если коротко, работает это так:



ScaleIO — это софт, который ставится на серверы поверх операционной системы. ScaleIO состоит из серверной части, клиентской части и нод управления. Дисковые ресурсы объединяются в одну виртуальную одноуровневую систему.

Нода кластера: сервер отечественного производства Etegro (2 AMD Opteron 6320, 16 GB RAM, 4 HDD)

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

• Очень дорогие high-end СХД;
• Мидрейнжевые массивы (тиринг, HDD, гибридные решения);
• И экономичные кластеры на базе SSD-массивов и HDD-массивов из «бытовых» дисков, часто собранные своими руками.

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

И вот на этот рынок пришла EMC, известная своими чертовски дорогими и надёжными железками с софтом, который позволяет без проблем поднять и VMware-ферму, и виртуальную СХД, и всякий приклад на одних и тех же х86 серверах. И ещё началась история с серверов русского производства.

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

Но вернёмся в Россию 2015 года. Ниже я покажу, как «из подручных средств» (x86 машин и любых «хранилок») сэкономить денег, повысить надёжность и решить ещё ряд типовых для сисадминов среднего и крупного бизнеса задач.


На этой схеме видны обе архитектуры, о которых пойдет речь. SDS — два красных контроллера в центре с любым бекэндом, от внутренних дисков до FC полок и облаков. И виртуальный SAN, на схеме Hyper-converged storage.

Самое главное:

• Вам плевать, что за железо стоит: диски, SSD, зоопарк производителей, старые и новые модели… — всё это отдаётся оркестирующему софту, и он приводит это к той виртуальной архитектуре, которая вам нужна в итоге. Грубо говоря, объединяет в один том или позволяет нарезать как вам удобно.
• Вам плевать, какие интерфейсы у этих систем. SDS построится сверху.
• Вам плевать, какие функции ваши хранилки могли, а какие не могли (опять же, теперь они могут то, что надо: решает софт сверху).

Заодно рассмотрим пару типовых задач с конкретным железом и ценами.

Решил написать эту статью после знакомства с публикацией «HP, Dell и IBM: компоненты, отвечающие за надёжность сервера», поскольку имею другое мнение насчёт некоторых моментов. Эта статья не претендует на инновационные подходы, а просто описывает полученный опыт и, надеюсь, предотвратит банальные ошибки.

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

Почти все население Азербайджана лишилось доступа к интернету

В одном из дата-центров компании Delta Telecom вспыхнул огонь. Даунтайм длился в течение восьми часов. После этого инцидента получить доступ к интернет-услугам можно было лишь с использование каналов местных мобильных операторов Backcell и Azerfon.

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

Схема отработки аварии первого уровня в «Мультикарте»

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

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

А теперь поехали развеивать другие мифы про DRP и непрерывности. Ну и заодно расскажу про наш последний проект — аварийные планы «Мультикарты», то есть той системы, через которую идут все ваши оплаты картами в России.

Ну и, конечно, истории былинных провалов.

Продолжая и дополняя тему номера «Отказы и аварии в ЦОД», мы поделимся несколькими наблюдениями без претензии на серьезный анализ причин и следствий. Возможно, некоторые моменты покажутся читателю курьезными и забавными, хотя все, что происходило, было очень серьезно. Надеемся, эти достаточно поучительные истории позволят читателю самому сделать выводы.

Хрестоматийный сценарий

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

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

Введение

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

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

В этой статье я хочу рассказать про ещё один этап развития DWH в Тинькофф Банке.

Ни для кого не секрет, что требования к наличию Disaster Recovery (далее DR) в современных бизнес информационных системах относятся к категории «must have». Так, чуть более года назад, команде, занимающейся развитием DWH в банке, была поставлена задача реализовать DR для DWH, на котором построены как offline, так и online процессы банка.