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


Я понимал, что данное решение никак не повлияет на производительность и результаты работы Ивана, все знали, насколько он крут. С одной стороны, сотрудник получил возможность работать из дома 2 дня в неделю и сильно смещенный к утру график в остальные дни. С другой стороны, мы договорились о бонусе, который удерживает ведущего специалиста в нашем отделе от перехода куда-либо. Win-win, как ни крути!

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

Тогда я задумался, почему остальные команды разработки не могут также работать удаленно. Чем они отличаются от Ивана и Василия?

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

• А вдруг они перестанут работать?
• А вдруг мне что-то резко понадобится от сотрудника и я не смогу найти его на месте?

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


Посмотрим, какие бонусы получают сотрудники от удаленной работы:

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

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

Моими доводами в этом стали:

1. Иван с Василием работают из дома, почему остальным нельзя? Мы же команда, делающая общее дело!
2. Давай судить по результату работы, а не по тому месту, где был достигнут результат.
3. Дополнительная нематериальная мотивация, которая для многих сотрудников может стать решающей в решении уйти или остаться.

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

Я решил двигаться маленькими шажками: удаленный день для некоторых сотрудников -> удаленный день для всех сотрудников -> 2 удаленных дня для всех сотрудников -> ???
Основная идея: доказать, что удаленная работа не вредит бизнесу, а только помогает ему.

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

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

А как вы работаете в больших компаниях? Есть ли у вас удаленные дни и возможность поработать из дома?

Фрилансеров, работающих полностью удаленно, призываю также оставить комментарии.

Напоследок, приведу всем сомневающимся отличную книгу про плюсы удаленной работы «Remote: офис не обязателен» Джейсон Фрайд, Дэвид Хенссон.

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

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

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

Теперь же платформа дала начало сразу двум пилотным проектам — чат-боту на сайте и в мобильном приложении и более интеллектуальной системе анализа обратной связи от клиентов. Обо всем по порядку — под катом.




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

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

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

На текущий момент значимых для компании проектов четыре. Далее — подробнее о каждом из них.

Сбербанк Попутчик

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

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

В качестве движка сообщества была разработана платформа чат-бота.

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

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

Платежный бот

Еще один ранний проект, задействовавший разработанную платформу чат-бота, — платежный бот. Он был запущен в пилотную эксплуатацию в начале этого года (т.е. появился на свет примерно на полгода раньше, чем аналогичное решение, представленное весной Google на конференции Google I/O 2017).

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

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

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

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

Чат-бот контактного центра

Чат-бот для корпоративного сайта стал первым подобным проектом, который вышел за рамки «песочницы» в большой мир. Здесь, безусловно, используются наработки из Попутчика и платежного бота, но реализованы более «взрослые» и Machine Learning алгоритмы анализа запросов и поиска подходящих ответов.

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

Бот построен на технологии латентно-семантического анализа, обеспечивающей поиск ответа на вопрос клиента с учетом контекста. Методика позволяет по ключевым словам и контексту диалога найти в базе готовых ответов, куда входят разнообразные FAQ по продуктам, наиболее релевантный ответ.

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

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

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

Система обработки клиентских обращений

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

Вокруг публичных компаний, таких как Сбербанк, всегда существует некий информационный фон. Это могут быть как прямые обращения в компанию через форму обратной связи или телефон, так и оценки услуг или продуктов, публично выраженные в интернете — на личных страницах клиентов в социальных сетях, на сайтах с отзывами. Причем мнения могут содержать как позитивную, так и негативную оценку работы Банка. Предполагается, что система будет обрабатывать все обращения, поступающие по доступным каналам, классифицировать их (отделять жалобы или, наоборот, благодарности, определять тематику) и фиксировать тенденции на более высоком уровне абстракции — выявлять проблемы, которые более всего волнуют клиентов, определять продукты и услуги, требующие пристального внимания, расставлять приоритеты. Поскольку развитие услуг и продуктов в Сбербанке идет по методологии agile, в идеале мы надеемся, что система станет дополнительным источником идей в бэклог извне на тот случай, если у команды, развивающей тот или иной продукт, замылится взгляд.



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

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



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

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

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

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

Материал подготовили сотрудники ЦК развития биллинговых технологий СберТеха:
nill2, Данил Кабанов, директор ЦК
aspera, Руслан Халимов, ведущий инженер
Станислав Ким, руководитель разработки

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

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

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

Теперь же платформа дала начало сразу двум пилотным проектам — чат-боту на сайте и в мобильном приложении и более интеллектуальной системе анализа обратной связи от клиентов. Обо всем по порядку — под катом.




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

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

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

На текущий момент значимых для компании проектов четыре. Далее — подробнее о каждом из них.

Сбербанк Попутчик

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

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

В качестве движка сообщества была разработана платформа чат-бота.

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

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

Платежный бот

Еще один ранний проект, задействовавший разработанную платформу чат-бота, — платежный бот. Он был запущен в пилотную эксплуатацию в начале этого года (т.е. появился на свет примерно на полгода раньше, чем аналогичное решение, представленное весной Google на конференции Google I/O 2017).

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

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

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

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

Чат-бот контактного центра

Чат-бот для корпоративного сайта стал первым подобным проектом, который вышел за рамки «песочницы» в большой мир. Здесь, безусловно, используются наработки из Попутчика и платежного бота, но реализованы более «взрослые» и Machine Learning алгоритмы анализа запросов и поиска подходящих ответов.

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

Бот построен на технологии латентно-семантического анализа, обеспечивающей поиск ответа на вопрос клиента с учетом контекста. Методика позволяет по ключевым словам и контексту диалога найти в базе готовых ответов, куда входят разнообразные FAQ по продуктам, наиболее релевантный ответ.

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

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

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

Система обработки клиентских обращений

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

Вокруг публичных компаний, таких как Сбербанк, всегда существует некий информационный фон. Это могут быть как прямые обращения в компанию через форму обратной связи или телефон, так и оценки услуг или продуктов, публично выраженные в интернете — на личных страницах клиентов в социальных сетях, на сайтах с отзывами. Причем мнения могут содержать как позитивную, так и негативную оценку работы Банка. Предполагается, что система будет обрабатывать все обращения, поступающие по доступным каналам, классифицировать их (отделять жалобы или, наоборот, благодарности, определять тематику) и фиксировать тенденции на более высоком уровне абстракции — выявлять проблемы, которые более всего волнуют клиентов, определять продукты и услуги, требующие пристального внимания, расставлять приоритеты. Поскольку развитие услуг и продуктов в Сбербанке идет по методологии agile, в идеале мы надеемся, что система станет дополнительным источником идей в бэклог извне на тот случай, если у команды, развивающей тот или иной продукт, замылится взгляд.



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

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



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

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

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

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

Материал подготовили сотрудники ЦК развития биллинговых технологий СберТеха:
nill2, Данил Кабанов, директор ЦК
aspera, Руслан Халимов, ведущий инженер
Станислав Ким, руководитель разработки

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

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

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

Теперь же платформа дала начало сразу двум пилотным проектам — чат-боту на сайте и в мобильном приложении и более интеллектуальной системе анализа обратной связи от клиентов. Обо всем по порядку — под катом.




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

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

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

На текущий момент значимых для компании проектов четыре. Далее — подробнее о каждом из них.

Сбербанк Попутчик

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

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

В качестве движка сообщества была разработана платформа чат-бота.

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

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

Платежный бот

Еще один ранний проект, задействовавший разработанную платформу чат-бота, — платежный бот. Он был запущен в пилотную эксплуатацию в начале этого года (т.е. появился на свет примерно на полгода раньше, чем аналогичное решение, представленное весной Google на конференции Google I/O 2017).

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

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

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

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

Чат-бот контактного центра

Чат-бот для корпоративного сайта стал первым подобным проектом, который вышел за рамки «песочницы» в большой мир. Здесь, безусловно, используются наработки из Попутчика и платежного бота, но реализованы более «взрослые» и Machine Learning алгоритмы анализа запросов и поиска подходящих ответов.

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

Бот построен на технологии латентно-семантического анализа, обеспечивающей поиск ответа на вопрос клиента с учетом контекста. Методика позволяет по ключевым словам и контексту диалога найти в базе готовых ответов, куда входят разнообразные FAQ по продуктам, наиболее релевантный ответ.

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

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

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

Система обработки клиентских обращений

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

Вокруг публичных компаний, таких как Сбербанк, всегда существует некий информационный фон. Это могут быть как прямые обращения в компанию через форму обратной связи или телефон, так и оценки услуг или продуктов, публично выраженные в интернете — на личных страницах клиентов в социальных сетях, на сайтах с отзывами. Причем мнения могут содержать как позитивную, так и негативную оценку работы Банка. Предполагается, что система будет обрабатывать все обращения, поступающие по доступным каналам, классифицировать их (отделять жалобы или, наоборот, благодарности, определять тематику) и фиксировать тенденции на более высоком уровне абстракции — выявлять проблемы, которые более всего волнуют клиентов, определять продукты и услуги, требующие пристального внимания, расставлять приоритеты. Поскольку развитие услуг и продуктов в Сбербанке идет по методологии agile, в идеале мы надеемся, что система станет дополнительным источником идей в бэклог извне на тот случай, если у команды, развивающей тот или иной продукт, замылится взгляд.



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

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



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

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

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

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

Материал подготовили сотрудники ЦК развития биллинговых технологий СберТеха:
nill2, Данил Кабанов, директор ЦК
aspera, Руслан Халимов, ведущий инженер
Станислав Ким, руководитель разработки

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

Продолжаю свой рассказ о самом интересном на конференции VMworld 2017 Europe (первая часть рассказа о конференции).

Первый день начался с генеральной сессии под воодушевляющим заголовком: Good Technologists Solve Problems. Great Innovators Create Opportunities. Генеральный директор VMware Пэт Гелсингер (Pat Gelsinger) рассказал о том, как технологии меняют окружающий нас мир. Он привел в пример то, как быстро люди могут адаптироваться ко всему новому. Например, первоначальный страх перед беспилотными автомобилями сменяется интересом: «А как же это внутри работает?», что приводит к возникновению новых потребностей: «Почему эта штука не может ехать быстрее?». В результате именно ИТ становится основным источником роста для компаний. И если 100 лет назад человек должен был уметь делать три вещи: читать, писать и считать, то теперь это выглядит скорее, как «читать, писать код и считать».

VMware предоставляет решения, обеспечивающие работу любого приложения в любом облаке (частном или публичном) с возможностью доступа с любого устройства. Одним из таких решений является VMware HCX, обеспечивающий связь между on-premise инфраструктурой и публичными облачными сервисами (вроде IBM Cloud или OVH) и позволяющий в реальном времени переносить виртуальные машины туда и обратно без простоя (zero-downtime migration).

Однако далеко не все заказчики готовы с головой ринутся в публичное облако. Многие практикуют гибридный подход, когда часть инфраструктуры развернута on-premise, а часть — в облаке. Для улучшения возможностей по управлению такими гибридными средами VMware предлагает набор продуктов, распространяемых по модели SaaS — VMware Cloud Services, в число которых входят решения по мониторингу, анализу стоимости, организации сетевой связности, защите приложений и обеспечению единой точки подключения к приложениям.

Дальше речь зашла о публичном облаке VMware Cloud on AWS. Вкратце: Amazon предоставляет свои виртуальные ЦОД, расположенные во всех уголках мира, а также инженерную, сетевую инфраструктуру и серверное оборудование, на которое устанавливается набор продуктов VMware SDDC.

Также VMware напомнила о других недавно анонсированных продуктах, работающих внутри виртуальных сред: VMware Integrated OpenStack 4.0 (собственном дистрибутиве OpenStack) и VMware AppDefense (решении по организации защиты приложений).

Выставка

После завершения генеральной сессии посетители стали расходиться. Одни спешили на другие сессии, другие расслаблялись в lounge-зоне, третьи направились на выставку партнерских решений Solutions Exchange.



Ежегодно на VMworld более 100 компаний развёртывают стенды для демонстрации всевозможных продуктов и решений. Например, здесь можно побывать на стендах Dell, HPE, NetApp, IBM, Hitachi, Red Hat, Arista, Nutanix, а также перспективных стартапов. Особенно приятно, что на выставке представлены ИТ-компании, имеющие российские корни: Kaspersky и Veeam.

Вендоры всеми правдами и неправдами стараются зазвать посетителей на свои стенды:



Игра на стенде Intel, в котором участникам на время требовалось подобрать сервер в оптимальной конфигурации для решения потребностей бизнеса:



Первым мое внимание привлек стенд компании VMware, в первую очередь благодаря своим гигантским размерам (почему-то вспомнилась поговорка про «кто ужинает девушку, тот её и танцует»).



Здесь были представлены все направления работы компании: от десктопных гипервизоров VMware Workstation до недавно анонсированного AppDefense



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



Например, для банковского сектора демонстрировались смартфоны Samsung, поддерживающие работу в режиме декстопа (Samsung DEX). После установки смартфона в крэдл к нему можно подключить клавиатуру, мышь и монитор и работать практически как с полноценным настольным компьютером. Или можно запустить на нем клиент Horizon View, подключиться к VDI-инфраструктуре и получить доступ к опубликованным приложениям и виртуальным рабочим станциям, превратив устройство в мобильный тонкий клиент.



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



Cloud on AWS был анонсирован еще на прошлогоднем VMworld, и, наконец, решение стало доступным для конечных заказчиков.



В этом облаке любой заказчик может нажать пару кнопок и развернуть свой виртуальный ЦОД в облаке Amazon. Каждый такой ЦОД включает в себя:

• кластер VMware vSphere (не менее четырех физических серверов),
• сервер управления vCenter Server,
• распределенное хранилище VSAN,
• программно-конфигурируемую сеть NSX.

Каждый сервер имеет типовую конфигурацию: два процессора по 18 ядер в каждом, 512 Гб ОЗУ, 10,7 Тб дискового пространства на flash. При необходимости заказчик может наращивать вычислительные ресурсы виртуального ЦОД, добавляя дополнительные узлы вручную или в автоматическом режиме по мере роста нагрузки (так называемый Elastic DRS). Cloud on AWS предоставляет механизмы интеграции с on-premise инфраструктурой заказчика, позволяя управлять локальными и облачными кластерами vSphere и виртуальными машинами из единой консоли vSphere Client (Hybrid Linked Mode).

VMware полностью берет на себя поддержку облачной инфраструктуры, включая настройку, патч-менеджмент и обслуживание оборудования.

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

VMware выделяет три основных сценария использования Cloud on AWS:

1. расширение существующей виртуальной инфраструктуры или организация резервной площадки для обеспечения аварийного восстановления без необходимости построения собственного ЦОД;
2. консолидация нескольких существующих ЦОД или полная миграция в облако с минимальным влиянием на существующие приложения и ВМ;
3. быстрое предоставление вычислительных ресурсов для задач тестирования/разработки или при цикличной нагрузке (пики в сезон продаж).

На текущий момент развертывание виртуальных ЦОД доступно только в одном регионе (US West Oregon), однако уже в ближайшем будущем список регионов будет расширен.

На стенде HPE демонстрировалось новое поколение серверов ProLiant GEN10. В частности, был представлен 1U rackmount-серер HPE ProLiant DL360 GEN10.

Среди нововведений GEN10

• Поддержка процессоров архитектуры Intel Xeon Scalable. Новые процессоры имеют большее количество ядер (28 у старшей модели Intel Xeon Platinum 8150M вместо 22 ядер у Intel Xeon E5-2699A v4), большие тактовые частоты и кэш-память третьего уровня, а также возросший до 205 Вт тепловой пакет.
• Поддержка установки большего числа flash-накопителей с интерфейсом NVMe, которые обеспечивают более высокие скорости передачи данных и меньшие задержки по сравнению с накопителями с SATA/SAS интерфейсами. В 1U-сервер можно установить до 10 таких накопителей, выполненных в форм-факторе 2,5 дюйма. В более вместительный 2U-сервер — уже 20. Если учесть, что в портфолио HPE есть NVMe-накопители объемом до 2 ТБ, нетрудно подсчитать итоговую ёмкость.

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

Стоит отметить постепенный переход производителей серверов к сетевым адаптерам 25 Гбит/с и, соответственно, к портам 100 Гбит/с на сетевом оборудовании. Помимо двух с половиной кратного увеличения полосы пропускания и уменьшения задержек по сравнению с 10 GbE, что может быть полезно для современных гиперконвергентных решений и программно-определяемых СХД, такие адаптеры могут похвастаться наличием разъемов стандарта SFP28, которые по размерам совпадают с обычными SFP+ и занимают меньше места, чем QSFP+.



На стенде Intel демонстрировалась гиперконвергентная платформа на базе серверов, процессоров и flash-накопителей производства Intel и ПО VMware (vSphere и vSAN).



Невзрачные, на первый взгляд, серверы содержат по два процессора Intel Xeon Gol 6152, 768 ГБ ОЗУ, четыре накопителя Intel Optane DC P4800X объемом 375 ГБ на базе памяти 3D XPoint и 12 «классических» NVMe flash-накопителей Intel DC P4500.



Накопители выполнены в форм-факторе 2,5 дюйма, поддерживают горячую замену и подключаются напрямую к шине PCI-E через специальные host-адаптеры.



Один такой сервер способен обеспечивать производительность на уровне 380 тысяч IOPS при случайной нагрузке блоками 4 Кб и соотношении чтения/записи равном 70/30.



Следующей на очереди была зона HCI (HyperConverged Infrastructure) — гиперконвергентных решений, совмещающих вычислительные ресурсы и ресурсы хранения в рамках одного конструктивного блока. Помимо партнерских решений Intel, Lenovo и Fujitsu, на стенде демонстрировалась HCI-платформа Dell-EMC VxRail 4.0.



VxRail представляет собой законченное решение, построенное на базе серверов Dell и программного обеспечения VMware vSAN. На текущий момент в линейке VxRail присутствуют 5 типов конфигураций, предназначенных для решения разных задач: от высокоплотных серверов G-серии и типовых 1U-серверов E-серии (Entry level) до серверов серии V, поддерживающих установку графических ускорителей и оптимизированных для запуска виртуальных рабочих станций, высокопроизводительных (серия P) или емких (серия S) серверов.



VxRail, как и большинство других HCI-решений, поставляются заказчикам в уже готовом к работе виде. Достаточно на месте скоммутировать сервер, включить питание, пройти простой мастер первоначальной настройки — и «Voila!», полностью функционирующая виртуальная инфраструктура готова к работе.

Для популяризации HCI и других решений среди молодежи Dell EMC выпустила серию комиксов.





Прямо на выставке записывался подкаст Virtually Speaking Podcast (https://soundcloud.com/virtuallyspeakingpodcast) о виртуализации и облачных технологиях.



На стенде Mellanox демонстрировались всевозможные сетевые и конвергентные адаптеры серии ConnectX, поддерживающие 10, 25, 40, 100 Гбит/с и даже 200 Гбит/с подключения. Обратите внимание, как растут требования к шине PCI-E по мере увеличения количества и скорости портов.



Рядом с Mellanox расположился стенд Supermicro, на котором демонстрировались современные серверы Twin-формата (позволяющие размещать два или четыре сервера в одном шасси), поддерживающие процессоры Intel Xeon Scalable и AMD EPYC. Серверы Supermicro пользуются неизменной популярностью у экономных заказчиков, сборщиков оборудования и производителей апплайнсов, например, платформа Web Scale от Nutanix строится именно на таких серверах.



Серверы имеют заменяемый адаптер LOM (Lan-on-board), позволяющий подобрать необходимую конфигурацию сетевых портов без замены материнской платы и без использования PCI-E слота расширения.

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

Андрей Коновалов, начальник отдела виртуализации компании «Инфосистемы Джет»

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

Продолжаю свой рассказ о самом интересном на конференции VMworld 2017 Europe (первая часть рассказа о конференции).

Первый день начался с генеральной сессии под воодушевляющим заголовком: Good Technologists Solve Problems. Great Innovators Create Opportunities. Генеральный директор VMware Пэт Гелсингер (Pat Gelsinger) рассказал о том, как технологии меняют окружающий нас мир. Он привел в пример то, как быстро люди могут адаптироваться ко всему новому. Например, первоначальный страх перед беспилотными автомобилями сменяется интересом: «А как же это внутри работает?», что приводит к возникновению новых потребностей: «Почему эта штука не может ехать быстрее?». В результате именно ИТ становится основным источником роста для компаний. И если 100 лет назад человек должен был уметь делать три вещи: читать, писать и считать, то теперь это выглядит скорее, как «читать, писать код и считать».

VMware предоставляет решения, обеспечивающие работу любого приложения в любом облаке (частном или публичном) с возможностью доступа с любого устройства. Одним из таких решений является VMware HCX, обеспечивающий связь между on-premise инфраструктурой и публичными облачными сервисами (вроде IBM Cloud или OVH) и позволяющий в реальном времени переносить виртуальные машины туда и обратно без простоя (zero-downtime migration).

Однако далеко не все заказчики готовы с головой ринутся в публичное облако. Многие практикуют гибридный подход, когда часть инфраструктуры развернута on-premise, а часть — в облаке. Для улучшения возможностей по управлению такими гибридными средами VMware предлагает набор продуктов, распространяемых по модели SaaS — VMware Cloud Services, в число которых входят решения по мониторингу, анализу стоимости, организации сетевой связности, защите приложений и обеспечению единой точки подключения к приложениям.

Дальше речь зашла о публичном облаке VMware Cloud on AWS. Вкратце: Amazon предоставляет свои виртуальные ЦОД, расположенные во всех уголках мира, а также инженерную, сетевую инфраструктуру и серверное оборудование, на которое устанавливается набор продуктов VMware SDDC.

Также VMware напомнила о других недавно анонсированных продуктах, работающих внутри виртуальных сред: VMware Integrated OpenStack 4.0 (собственном дистрибутиве OpenStack) и VMware AppDefense (решении по организации защиты приложений).

Выставка

После завершения генеральной сессии посетители стали расходиться. Одни спешили на другие сессии, другие расслаблялись в lounge-зоне, третьи направились на выставку партнерских решений Solutions Exchange.



Ежегодно на VMworld более 100 компаний развёртывают стенды для демонстрации всевозможных продуктов и решений. Например, здесь можно побывать на стендах Dell, HPE, NetApp, IBM, Hitachi, Red Hat, Arista, Nutanix, а также перспективных стартапов. Особенно приятно, что на выставке представлены ИТ-компании, имеющие российские корни: Kaspersky и Veeam.

Вендоры всеми правдами и неправдами стараются зазвать посетителей на свои стенды:



Игра на стенде Intel, в котором участникам на время требовалось подобрать сервер в оптимальной конфигурации для решения потребностей бизнеса:



Первым мое внимание привлек стенд компании VMware, в первую очередь благодаря своим гигантским размерам (почему-то вспомнилась поговорка про «кто ужинает девушку, тот её и танцует»).



Здесь были представлены все направления работы компании: от десктопных гипервизоров VMware Workstation до недавно анонсированного AppDefense



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



Например, для банковского сектора демонстрировались смартфоны Samsung, поддерживающие работу в режиме декстопа (Samsung DEX). После установки смартфона в крэдл к нему можно подключить клавиатуру, мышь и монитор и работать практически как с полноценным настольным компьютером. Или можно запустить на нем клиент Horizon View, подключиться к VDI-инфраструктуре и получить доступ к опубликованным приложениям и виртуальным рабочим станциям, превратив устройство в мобильный тонкий клиент.



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



Cloud on AWS был анонсирован еще на прошлогоднем VMworld, и, наконец, решение стало доступным для конечных заказчиков.



В этом облаке любой заказчик может нажать пару кнопок и развернуть свой виртуальный ЦОД в облаке Amazon. Каждый такой ЦОД включает в себя:

• кластер VMware vSphere (не менее четырех физических серверов),
• сервер управления vCenter Server,
• распределенное хранилище VSAN,
• программно-конфигурируемую сеть NSX.

Каждый сервер имеет типовую конфигурацию: два процессора по 18 ядер в каждом, 512 Гб ОЗУ, 10,7 Тб дискового пространства на flash. При необходимости заказчик может наращивать вычислительные ресурсы виртуального ЦОД, добавляя дополнительные узлы вручную или в автоматическом режиме по мере роста нагрузки (так называемый Elastic DRS). Cloud on AWS предоставляет механизмы интеграции с on-premise инфраструктурой заказчика, позволяя управлять локальными и облачными кластерами vSphere и виртуальными машинами из единой консоли vSphere Client (Hybrid Linked Mode).

VMware полностью берет на себя поддержку облачной инфраструктуры, включая настройку, патч-менеджмент и обслуживание оборудования.

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

VMware выделяет три основных сценария использования Cloud on AWS:

1. расширение существующей виртуальной инфраструктуры или организация резервной площадки для обеспечения аварийного восстановления без необходимости построения собственного ЦОД;
2. консолидация нескольких существующих ЦОД или полная миграция в облако с минимальным влиянием на существующие приложения и ВМ;
3. быстрое предоставление вычислительных ресурсов для задач тестирования/разработки или при цикличной нагрузке (пики в сезон продаж).

На текущий момент развертывание виртуальных ЦОД доступно только в одном регионе (US West Oregon), однако уже в ближайшем будущем список регионов будет расширен.

На стенде HPE демонстрировалось новое поколение серверов ProLiant GEN10. В частности, был представлен 1U rackmount-серер HPE ProLiant DL360 GEN10.

Среди нововведений GEN10

• Поддержка процессоров архитектуры Intel Xeon Scalable. Новые процессоры имеют большее количество ядер (28 у старшей модели Intel Xeon Platinum 8150M вместо 22 ядер у Intel Xeon E5-2699A v4), большие тактовые частоты и кэш-память третьего уровня, а также возросший до 205 Вт тепловой пакет.
• Поддержка установки большего числа flash-накопителей с интерфейсом NVMe, которые обеспечивают более высокие скорости передачи данных и меньшие задержки по сравнению с накопителями с SATA/SAS интерфейсами. В 1U-сервер можно установить до 10 таких накопителей, выполненных в форм-факторе 2,5 дюйма. В более вместительный 2U-сервер — уже 20. Если учесть, что в портфолио HPE есть NVMe-накопители объемом до 2 ТБ, нетрудно подсчитать итоговую ёмкость.

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

Стоит отметить постепенный переход производителей серверов к сетевым адаптерам 25 Гбит/с и, соответственно, к портам 100 Гбит/с на сетевом оборудовании. Помимо двух с половиной кратного увеличения полосы пропускания и уменьшения задержек по сравнению с 10 GbE, что может быть полезно для современных гиперконвергентных решений и программно-определяемых СХД, такие адаптеры могут похвастаться наличием разъемов стандарта SFP28, которые по размерам совпадают с обычными SFP+ и занимают меньше места, чем QSFP+.



На стенде Intel демонстрировалась гиперконвергентная платформа на базе серверов, процессоров и flash-накопителей производства Intel и ПО VMware (vSphere и vSAN).



Невзрачные, на первый взгляд, серверы содержат по два процессора Intel Xeon Gol 6152, 768 ГБ ОЗУ, четыре накопителя Intel Optane DC P4800X объемом 375 ГБ на базе памяти 3D XPoint и 12 «классических» NVMe flash-накопителей Intel DC P4500.



Накопители выполнены в форм-факторе 2,5 дюйма, поддерживают горячую замену и подключаются напрямую к шине PCI-E через специальные host-адаптеры.



Один такой сервер способен обеспечивать производительность на уровне 380 тысяч IOPS при случайной нагрузке блоками 4 Кб и соотношении чтения/записи равном 70/30.



Следующей на очереди была зона HCI (HyperConverged Infrastructure) — гиперконвергентных решений, совмещающих вычислительные ресурсы и ресурсы хранения в рамках одного конструктивного блока. Помимо партнерских решений Intel, Lenovo и Fujitsu, на стенде демонстрировалась HCI-платформа Dell-EMC VxRail 4.0.



VxRail представляет собой законченное решение, построенное на базе серверов Dell и программного обеспечения VMware vSAN. На текущий момент в линейке VxRail присутствуют 5 типов конфигураций, предназначенных для решения разных задач: от высокоплотных серверов G-серии и типовых 1U-серверов E-серии (Entry level) до серверов серии V, поддерживающих установку графических ускорителей и оптимизированных для запуска виртуальных рабочих станций, высокопроизводительных (серия P) или емких (серия S) серверов.



VxRail, как и большинство других HCI-решений, поставляются заказчикам в уже готовом к работе виде. Достаточно на месте скоммутировать сервер, включить питание, пройти простой мастер первоначальной настройки — и «Voila!», полностью функционирующая виртуальная инфраструктура готова к работе.

Для популяризации HCI и других решений среди молодежи Dell EMC выпустила серию комиксов.





Прямо на выставке записывался подкаст Virtually Speaking Podcast (https://soundcloud.com/virtuallyspeakingpodcast) о виртуализации и облачных технологиях.



На стенде Mellanox демонстрировались всевозможные сетевые и конвергентные адаптеры серии ConnectX, поддерживающие 10, 25, 40, 100 Гбит/с и даже 200 Гбит/с подключения. Обратите внимание, как растут требования к шине PCI-E по мере увеличения количества и скорости портов.



Рядом с Mellanox расположился стенд Supermicro, на котором демонстрировались современные серверы Twin-формата (позволяющие размещать два или четыре сервера в одном шасси), поддерживающие процессоры Intel Xeon Scalable и AMD EPYC. Серверы Supermicro пользуются неизменной популярностью у экономных заказчиков, сборщиков оборудования и производителей апплайнсов, например, платформа Web Scale от Nutanix строится именно на таких серверах.



Серверы имеют заменяемый адаптер LOM (Lan-on-board), позволяющий подобрать необходимую конфигурацию сетевых портов без замены материнской платы и без использования PCI-E слота расширения.

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

Андрей Коновалов, начальник отдела виртуализации компании «Инфосистемы Джет»

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

2 сентября 2017 прошла конференция Moscow Frontend, где я на примере React UI Kit рассказывала о проблемах, которые встречаются при внедрении UI Kit в компании. Тема оказалась актуальнее, чем я могла предположить, поэтому решила опубликовать статью по этой же тематике, преследуя две цели: донести материал до людей, которые не смогли оказаться на конференции лично, и предоставить отличную возможность провести жаркую дискуссию на эту тему в комментариях.

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

Что такое UI Kit?

Как показал опрос зала, не все присутствующие на профильной конференции по frontend знают, что такое UI Kit. Если говорить простым языком, UI Kit – это набор элементов пользовательского интерфейса в едином стиле. Еще проще: кнопки, поля для ввода текста, выпадающее меню и прочее в одном цвете.

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

Пройдемся по всему процессу внедрения шаг за шагом:

1. Определение необходимости Kit в компании
2. Анализ уже существующих решений
3. Разработка дизайна
4. Организация библиотеки компонентов
5. Создание компонентов
6. Использование

Определение необходимости Kit в компании

Если вы только что узнали, что такое UI Kit, у вас сразу возникнет первая проблема – как понять, нужен ли он нам? UI Kit точно не нужен, если:

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

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

Как объяснить бизнесу и компании, что вам нужен UI Kit

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

Приводите аргументы, которые будут понятны всем. Возможно, в вашей компании уже давно есть проблема с тем, что все продукты различаются визуально, и пора синхронизовать их дизайн. В качестве весомого аргумента можно предложить прочитать статью «And You Thought Buttons Were Easy?» , в которой рассказывается о материальной выгоде использования единой дизайн-системы. И объясните на пальцах, что страстно желаемые фичи будут создаваться и выкатываться намного быстрее, чем раньше.

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

Анализ существующих решений

Допустим, мы поняли, что Kit нам нужен, и бизнес полностью с нами солидарен. Теперь перед нами стоит новая проблема – определить, создавать кит самим, или использовать один из существующих на рынке. При этом мы хотим исключить лишнюю работу по разработке и использовать существующую библиотеку компонентов. В этом случае нужно изучить рынок и понять, какую использовать.

Библиотек компонентов во frontend на порядок больше, чем фреймворков, и не шутят о них только потому, что уже не смешно. Для простоты я создала небольшую подборку основных библиотек компонентов React и провела сравнительный анализ по трем критериям: кастомизация стилей, производительность и количество компонентов.


Зеленым выделены характеристики, которые нам подходят. В результате определились три лидера: Material-UI, Ant-design и React-md. Дальше вы можете проводить уже свои сравнения по скорости работы, функциональности или весу компонентов. Но я могу вас заранее предупредить: нельзя предугадать будущие потребности продуктов, находясь на старте разработки. Поэтому, если у компании есть ресурсы и заинтересованность в гибких решениях, то лучше создавать свой Kit.

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

Разработка дизайна

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

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

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

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

В зависимости от ситуации список можно сокращать или дополнять.

Очень важным моментом, на который сейчас обращают внимание далеко не все, является понимание разработки дизайном. Например, далеко не все дизайнеры знают, что такое компонент, что разработчикам может казаться удивительным. Но это факт! Пример общего подхода и к дизайну и к разработке – Tinkoff.ru, где в дизайне и в разработке используется методология atomic design, которая легка в понимании и хорошо соотносится с дизайном и разработкой UI Kit.


Все методологии, о которых я пишу, всего лишь вектор, в котором стоит начать думать или работать, но никак не ультимативное руководство к действию. Так поступили в Tinkoff.ru с atomic design: в методологии появляется новая сущность под названием «продукт».

Организация библиотеки компонентов

Шаг, который стоит под четвертым номером, но к которому стоит обратиться в разработке одновременно с третьим (разумеется, после «стола переговоров» с дизайном).

Перед вами так или иначе будет стоять выбор: создавать UI Kit как единую библиотеку или каждый компонент как отдельный npm-пакет. И, что бы вы ни выбрали, вас все равно ожидает ряд проблем.

Проблемы единой библиотеки:

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

Проблемы компонентов как отдельных пакетов:

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

Я указала не все проблемы и не все возможные решения, поскольку каждая компания уникальна. Но многие из них можно решить версионированием или договоренностью о возможности делать Pull request-ы всем командам, как в OpenSource. Если вы выбрали подход, при котором каждый компонент это отдельный пакет, то я могу предложить отличный инструмент для работы с разными пакетами в одном монорепозитории – Lerna. Если вы с ним еще не знакомы, обязательно сходите по ссылке и изучите все возможности. Возможно, это инструмент может оказаться вам полезным не только в контексте создания UI Kit.

Проблема, которая вам, как разработчику, не понравится больше всего, – построение процесса работы с Kit-ом. Кто будет создавать и контролировать Kit? Будет ли это отдельная команда или мейнтейнеры из разных продуктовых команд? Здесь, как и в ситуации с организацией библиотеки, вне зависимости от выбора у вас будет ряд проблем.

Если создавать и контролировать будет единая команда Kit-a, то:

• создание кита происходит в отрыве от реальных продуктов;
• большой список продуктовых задач, который упирается в одну команду;
• постоянные вопросы: «Создается ли компонент, нужный только одной команде?», «Что происходит при конфликте требований разных продуктов?» и т.п.

Если мейнтейнеры из разных команд, то:

• рассинхронизируются общие подходы;
• случается перевес в сторону требований собственного продукта;
• возникают сложности в формирования единого соглашения.

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

Создание компонентов

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

Вот мои небольшие рекомендации к обсуждению соглашение:

• покрыть весь функционал;
• максимально глупые компоненты;
• Pure Component;
• масштабируемые компоненты;
• переиспользуемые компоненты;
• тесты;
• кастомизация;
• версионирование;
• технологии/подходы.

Рекомендую также ознакомиться с книгой «Design of everyday things». В ней рассказывается о дизайне вещей, с которым мы сталкиваемся каждый день, и почему нам сразу понятно, как ими пользоваться. Например, двери, стулья или чайники. Эта книга в действительности изменила мое мышление о вещах, которые меня окружают и которые я создаю. А создаем мы все (разработчики) программы, компоненты и их интерфейсы. Так вот, интерфейсы наших компонентов должны быть понятны нам в использовании так же, как чайник, с которым мы точно знаем, что делать.

Использование

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

Некоторые из проблем можно решить, собрав все компоненты в единой витрине, включая и компоненты из разных библиотек. Очень простая в использовании витрина, которую используют и в Tinkoff.ru – Storyboook.

Вывод

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

Вы сделаете отличный вклад, если поделитесь со мной ответами на некоторые вопросы в комментариях:

1. Есть ли у вас в компании Kit?
2. Какие из проблем встречались вам?
3. Какие из указанных решений вы использовали и какую получили при этом пользу?

Спасибо, что прочитали эту статью до конца. Очень рада, если статья оказалась полезной. Хочу еще раз сказать спасибо организаторам Moscow Frontend Conference за возможность выступить и поделиться мыслями с коллегами.

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

2 сентября 2017 прошла конференция Moscow Frontend, где я на примере React UI Kit рассказывала о проблемах, которые встречаются при внедрении UI Kit в компании. Тема оказалась актуальнее, чем я могла предположить, поэтому решила опубликовать статью по этой же тематике, преследуя две цели: донести материал до людей, которые не смогли оказаться на конференции лично, и предоставить отличную возможность провести жаркую дискуссию на эту тему в комментариях.

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

Что такое UI Kit?

Как показал опрос зала, не все присутствующие на профильной конференции по frontend знают, что такое UI Kit. Если говорить простым языком, UI Kit – это набор элементов пользовательского интерфейса в едином стиле. Еще проще: кнопки, поля для ввода текста, выпадающее меню и прочее в одном цвете.

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

Пройдемся по всему процессу внедрения шаг за шагом:

1. Определение необходимости Kit в компании
2. Анализ уже существующих решений
3. Разработка дизайна
4. Организация библиотеки компонентов
5. Создание компонентов
6. Использование

Определение необходимости Kit в компании

Если вы только что узнали, что такое UI Kit, у вас сразу возникнет первая проблема – как понять, нужен ли он нам? UI Kit точно не нужен, если:

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

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

Как объяснить бизнесу и компании, что вам нужен UI Kit

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

Приводите аргументы, которые будут понятны всем. Возможно, в вашей компании уже давно есть проблема с тем, что все продукты различаются визуально, и пора синхронизовать их дизайн. В качестве весомого аргумента можно предложить прочитать статью «And You Thought Buttons Were Easy?» , в которой рассказывается о материальной выгоде использования единой дизайн-системы. И объясните на пальцах, что страстно желаемые фичи будут создаваться и выкатываться намного быстрее, чем раньше.

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

Анализ существующих решений

Допустим, мы поняли, что Kit нам нужен, и бизнес полностью с нами солидарен. Теперь перед нами стоит новая проблема – определить, создавать кит самим, или использовать один из существующих на рынке. При этом мы хотим исключить лишнюю работу по разработке и использовать существующую библиотеку компонентов. В этом случае нужно изучить рынок и понять, какую использовать.

Библиотек компонентов во frontend на порядок больше, чем фреймворков, и не шутят о них только потому, что уже не смешно. Для простоты я создала небольшую подборку основных библиотек компонентов React и провела сравнительный анализ по трем критериям: кастомизация стилей, производительность и количество компонентов.


Зеленым выделены характеристики, которые нам подходят. В результате определились три лидера: Material-UI, Ant-design и React-md. Дальше вы можете проводить уже свои сравнения по скорости работы, функциональности или весу компонентов. Но я могу вас заранее предупредить: нельзя предугадать будущие потребности продуктов, находясь на старте разработки. Поэтому, если у компании есть ресурсы и заинтересованность в гибких решениях, то лучше создавать свой Kit.

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

Разработка дизайна

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

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

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

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

В зависимости от ситуации список можно сокращать или дополнять.

Очень важным моментом, на который сейчас обращают внимание далеко не все, является понимание разработки дизайном. Например, далеко не все дизайнеры знают, что такое компонент, что разработчикам может казаться удивительным. Но это факт! Пример общего подхода и к дизайну и к разработке – Tinkoff.ru, где в дизайне и в разработке используется методология atomic design, которая легка в понимании и хорошо соотносится с дизайном и разработкой UI Kit.


Все методологии, о которых я пишу, всего лишь вектор, в котором стоит начать думать или работать, но никак не ультимативное руководство к действию. Так поступили в Tinkoff.ru с atomic design: в методологии появляется новая сущность под названием «продукт».

Организация библиотеки компонентов

Шаг, который стоит под четвертым номером, но к которому стоит обратиться в разработке одновременно с третьим (разумеется, после «стола переговоров» с дизайном).

Перед вами так или иначе будет стоять выбор: создавать UI Kit как единую библиотеку или каждый компонент как отдельный npm-пакет. И, что бы вы ни выбрали, вас все равно ожидает ряд проблем.

Проблемы единой библиотеки:

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

Проблемы компонентов как отдельных пакетов:

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

Я указала не все проблемы и не все возможные решения, поскольку каждая компания уникальна. Но многие из них можно решить версионированием или договоренностью о возможности делать Pull request-ы всем командам, как в OpenSource. Если вы выбрали подход, при котором каждый компонент это отдельный пакет, то я могу предложить отличный инструмент для работы с разными пакетами в одном монорепозитории – Lerna. Если вы с ним еще не знакомы, обязательно сходите по ссылке и изучите все возможности. Возможно, это инструмент может оказаться вам полезным не только в контексте создания UI Kit.

Проблема, которая вам, как разработчику, не понравится больше всего, – построение процесса работы с Kit-ом. Кто будет создавать и контролировать Kit? Будет ли это отдельная команда или мейнтейнеры из разных продуктовых команд? Здесь, как и в ситуации с организацией библиотеки, вне зависимости от выбора у вас будет ряд проблем.

Если создавать и контролировать будет единая команда Kit-a, то:

• создание кита происходит в отрыве от реальных продуктов;
• большой список продуктовых задач, который упирается в одну команду;
• постоянные вопросы: «Создается ли компонент, нужный только одной команде?», «Что происходит при конфликте требований разных продуктов?» и т.п.

Если мейнтейнеры из разных команд, то:

• рассинхронизируются общие подходы;
• случается перевес в сторону требований собственного продукта;
• возникают сложности в формирования единого соглашения.

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

Создание компонентов

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

Вот мои небольшие рекомендации к обсуждению соглашение:

• покрыть весь функционал;
• максимально глупые компоненты;
• Pure Component;
• масштабируемые компоненты;
• переиспользуемые компоненты;
• тесты;
• кастомизация;
• версионирование;
• технологии/подходы.

Рекомендую также ознакомиться с книгой «Design of everyday things». В ней рассказывается о дизайне вещей, с которым мы сталкиваемся каждый день, и почему нам сразу понятно, как ими пользоваться. Например, двери, стулья или чайники. Эта книга в действительности изменила мое мышление о вещах, которые меня окружают и которые я создаю. А создаем мы все (разработчики) программы, компоненты и их интерфейсы. Так вот, интерфейсы наших компонентов должны быть понятны нам в использовании так же, как чайник, с которым мы точно знаем, что делать.

Использование

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

Некоторые из проблем можно решить, собрав все компоненты в единой витрине, включая и компоненты из разных библиотек. Очень простая в использовании витрина, которую используют и в Tinkoff.ru – Storyboook.

Вывод

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

Вы сделаете отличный вклад, если поделитесь со мной ответами на некоторые вопросы в комментариях:

1. Есть ли у вас в компании Kit?
2. Какие из проблем встречались вам?
3. Какие из указанных решений вы использовали и какую получили при этом пользу?

Спасибо, что прочитали эту статью до конца. Очень рада, если статья оказалась полезной. Хочу еще раз сказать спасибо организаторам Moscow Frontend Conference за возможность выступить и поделиться мыслями с коллегами.

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

Источник

Друзья, всех с прошедшим вчера Днем программиста! Жизни без багов и красивейшего кода!)

Мы продолжаем разбор облачных сервисов Техносерв Cloud и сегодня детально разложим, из чего состоит наша облачная база данных. Если заглянуть в результаты исследования, проведенного IDG Connect по заказу Oracle, увидим, что DBaaS скоро будет самым востребованным сервисом частного облака. Растет и число публичных сервисов DBaaS.

Снижение затрат за счет консолидации ресурсов, масштабирование по мере необходимости, контроль расходов, доступ к данным из любого места – всё это факторы, влияющие на выбор в пользу облачной базы данных. На рынке облачных услуг свои базы данных предлагают его ведущие игроки – Amazon Web Services, IBM, Microsoft и Oracle. Но есть одна проблема — все они разворачивают БД за пределами России, более того, далеко не все из них предлагают сервис – администрирование, управление производительностью, круглосуточную техническую поддержку (желательно на русском языке), – а только платформу.

Чтобы ответить на этот запрос рынка, мы запустили свой сервис и стали единственным российским облачный провайдером, работающим с четырьмя основными базами данных под ФЗ-152 и ФЗ-242.

Рынок DBaaS

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

По прогнозу Technavio, в ближайшие годы мировой рынок DBaaS будет демонстрировать экспоненциальный рост — более чем на 65% ежегодно. Вместо того, чтобы вкладывать большие средства в аппаратные платформы, многие компании склонны инвестировать средства в услуги с еженедельной, ежеквартальной или ежегодной оплатой по подписке.

Объем работ по поддержке собственных многочисленных баз данных и серверов может быть весьма серьезным. Стандартизация, когда все в одной среде, переводит процесс на уровень выше и упрощает работу с БД. Тут ключевое слово – «упрощает», отмечают аналитики IDC.

Судя по результатам опросов, реляционные облачные СУБД – в числе самых популярных сервисов публичных облаков. Их используют 35% респондентов, экспериментируют -14%, планируют внедрение – 12% (источник – RightScale).

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

По данным Forrester, AWS – лидер рынка DBaaS. Amazon Relational Database Service позволяет работать с БД Oracle, Microsoft SQL Server, MySQL, MariaDB и PostgreSQL в среде EC2. Из 100 тыс. исследованных 2ndWatch экземпляров БД 67% представляли Amazon RDS.

Рост оборота мирового рынка DBaaS в млн. долларов (по данным 451 Research).

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

Рост сервиса Oracle DBaaS в мире.

Аналитики Markets&Markets прогнозируют, что рынок облачных СУБД/DBaaS вырастет с 1,07 млрд. долларов в 2014 году до 14,05 млрд. долларов к 2019 году при ежегодных темпах роста (CAGR) в 46%.

Что лучше, сервис или своя СУБД?

Облачная база данных или DBaaS (Database as a Service) – это любая СУБД, предоставляемая по подписке как облачный сервис в рамках платформенной модели обслуживания. То есть DBaaS – один из сервисов PaaS. В случае PaaS, «платформы как сервис», заказчик получает уже установленное и настроенное программное обеспечение для разработки и тестирования или развертывания приложений. Для заказчика создается БД нужной конфигурации в одном из следующих вариантов:

• БД без виртуализации (на физической машине)
• БД на виртуальной машине
• БД в виде контейнера в многоарендной базе данных

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

Отдельные базы данных консолидируются на физических серверах и группируются в облачных пулах. Любой сервер из пула может размещать один или несколько экземпляров баз данных (источник – Oracle).

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

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

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

Как показывает практика, многие заказчики DBaaS отмечают:

• Снижение общих расходов.
• Большую независимость бизнес-пользователей от ИТ-подразделений.
• Снижение рисков в сценариях ИТ-планирования.
• Большую предсказуемость и гибкость.
• Разработчики приложений достаточную степень свободы для творчества и инноваций.
• DBaaS улучшает работу администраторов БД. Они больше концентрируются на задачах бизнеса и меньше — на рутинных операциях.

Отличия DBaaS от традиционного подхода (источник – Oracle).

Основные преимущества облачной БД

1. Начнем с того, что не каждая компания может выделить отдельного сотрудника для мониторинга и управления своей СУБД. Результат — высокие риски остановки бизнес-процессов, прерывание производственных процессов, потеря данных и прочие неприятности. С сервисом «Облачная база данных» все эти заботы мы берем на себя. Преимущества DBaaS:
   • высокая масштабируемость,
   • снижение затрат,
   • быстрое предоставление услуг,
   • повышение надежности и безопасности.

   
   
2. Это не только надежнее и безопаснее, но и выгоднее. Как уже отмечалось, компания может существенно сэкономить на зарплатах DBA. Действительно квалифицированных специалистов на рынке очень мало, и часто те, что есть, перегружены текущими задачами. В облаке нет необходимости заботиться о настройках сервера БД, и цена поддержки обычно оказывается значительно меньше. К тому же собственные специалисты по БД не всегда способны обеспечить необходимый уровень сервиса, а облачные решения гарантируют высокий уровень доступности – мы круглосуточно осуществляем мониторинг на уровне платформы и на уровне СУБД.
3. На самом деле многие компании вообще не имеют специалистов по БД в штате. Одно дело запустить SQL Server или MySQL на сервере и обеспечить работу приложения, другое — исправить ошибки в БД и оптимизировать ее функционирование. В случае возникновения реальных проблем придется срочно искать внешнего специалиста. В облаке «узкие места» БД становятся головной болью провайдера. К тому же он вполне может нанять специалистов по БД и поддерживать высокий уровень их квалификации. А к вашим услугам — первая линия поддержки. Это к вопросу выбора места размещения БД – «у себя» или в облаке.
4. Еще одно преимущество сервиса – быстро развертываемые готовые типовые конфигурации, оптимизированные по производительности под типовые задачи использования баз данных. Создание индивидуальной конфигурации и конфигураций с кластеризацией может занимать до трех рабочих дней.
5. Сервис «Облачная база данных» использует резервируемые виртуальные ресурсы, предусматривает отчеты по доступности, базовое администрирование БД и ОС, резервное копирование БД и восстановление из резервной копии, управление емкостью хранения. Дополнительные услуги — мониторинг производительности БД, мониторинг бизнес процессов, расширенное администрирование и резервирование с индивидуальным расписанием резервного копирования и глубины хранения. Профессиональные услуги включают также аудит, консультации, миграцию, в том числе конвертацию и перенос данных (с предоставлением СХД). И конечно, мы обеспечиваем отказоустойчивость и повышенную доступность баз данных. Ведь база данных является одним из наиболее критичных сервисов для предприятия.

Четыре в одном

Переходим к описанию нашего сервиса «Облачная база данных». Как мы уже сказали, эта услуга может работать с четырьмя основными базами данных: мы предоставляем готовые к работе базы данных Microsoft SQL (лицензии MS по модели SPLA), PostgreSQL и MySQL, а также хостинг Oracle.

Тарифный план предусматривает более 80 вариантов оказания услуги под различные классы экземпляров баз данных.

Клиентам доступны следующие версии и редакции СУБД:

Особенности услуги «Облачная база данных»

• Высокая производительность.
• Оптимизированные в соответствии с рекомендациями разработчиков и лучшими практиками конфигурации ОС и СУБД.
• Профессиональная техническая поддержка, в которой работают специалисты интегратора по базам данных.
• Услуга создавалась с учетом ФЗ-149, ФЗ-152 и ФЗ-242.
• Ценовое предложение в среднем на 35-40% выгоднее западных облачных платформ (с учетом затрат на работы по администрированию баз данных и операционных систем которые по умолчанию включены в состав услуги).

Согласно законодательству РФ, основными документами, определяющими требования к защите информации, являются:

• Закон ФЗ-149 «Об информации, информационных технологиях и о защите информации».
• Закон ФЗ-152 «О персональных данных».
• Приказы ФСТЭК России №17 и №21.
• Закон ФЗ-242, который уточняет ФЗ-152 и обязывает операторов персональных данных обрабатывать и хранить персональные данные россиян с использованием баз данных, размещенных на территории РФ.

По умолчанию наш сервис предоставляется клиентам в соответствии с 3-й и 4-й категориями защищенности ПДн (о безопасности данных), а по запросу – в аттестованном сегменте* платформы, согласно всем требованиям защиты информации, установленным ФСТЭК России.

*Аттестат соответствия требованиям по безопасности информации

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

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

Санкции также подталкивают наших потенциальных заказчиков на поиск альтернативных решений на российском рынке. На фоне высокого курса валют и сложной политической ситуации они ищут возможные пути минимизации рисков, и «Облачная база данных», как российский сервис, предлагаемый на территории России по рублевым ценам, заслуживает пристального внимания. Облачные сервисы могут выступить в качестве альтернативы покупке ИТ-оборудования западных вендоров, а открытое ПО, на основе которого сервис функционирует, отвечает курсу на импортозамещение. Open Source платформы, такие как OpenStack, — одна из ключевых альтернатив проприетарным решениям.

Наш сервис включает все опции, обеспечивающие доступность базы данных:

• динамически расширяемые вычислительные ресурсы;
• администрирование ОС и СУБД силами провайдера;
• мониторинг СУБД;
• резервное копирование данных.

И предлагает следующие варианты подключения к БД:

• сети общего пользования (публичный интернет).
• защищенное VPN-подключение поверх интернета (IPSec VPN).
• защищенный L2 VPN-канал связи.
• сеть IP VPN.
• через внутреннюю сеть, при условии размещения серверов приложений в облачной платформе Техносерв Cloud (скорость 10 Гбит/с).

Администрирование БД включает в себя выполнение следующих операций:

• решение инцидентов в работе БД;
• установка и настройка клиента и ПО БД;
• управление доступом к БД;
• резервное копирование БД;
• обновление ПО БД;
• мониторинг доступности БД;
• мониторинг состояния БД и резервных копий, периодическое тестирование резервных копий (1 раз в месяц);
• управление пространством;
• анализ журналов и файлов трассировки;
• восстановление БД из резервных копий в случае сбоя*.

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

Администрирование операционных систем включает в себя выполнение следующих операций:

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

Для реализации сервиса мы используем в своей облачной платформе сегмент OpenStack со следующими возможностями:

• среда виртуализации OpenStack/KVM;
• обмен данными между ВМ — до 10 Гбит\с;
• система управления OpenStack (основана на релизе Mitaka);
• использование модуля виртуализации сети Neutron позволяет реализовывать функции NAT, VPNaaS, FWaaS, LBaaS, маршрутизации;
• программно-определяемое хранилище (SDS) — тройное резервирование обеспечивает не только сохранность данных при выходе из строя любого диска, узла или группы узлов, но и автоматизированное восстановление копий на других узлах.

Ресурсы у сегмента OpenStack (с учетом резервирования):

• vCPU – 1000 ядер.
• vRam – 1400 Гбайт.
• vHDD – 24000 Гбайт.

Какие задачи решаем?

Наша услуга сокращает эксплуатационные затраты, в которые среди прочего входят зарплаты администраторов БД (например, в Московском регионе зарплата Oracle DBA в месяц может доходить до 200 т.р.), а также снижает риски, связанные с инфраструктурой, на которой развернуты БД. Ее можно использовать для запуска новых или обновления существующих бизнес-приложений, таких как корпоративная система электронной почты, системы CRM и HRM, бухгалтерское, складское, финансовое и аналитическое ПО.

Она сводит к минимуму риск недоступности бизнес-приложений из-за ошибок в работе баз данных, снижает вероятность потери данных из-за несвоевременного резервного копирования, дает возможность обеспечить высокую доступность БД в условиях отсутствия или недостаточности собственных ресурсов/экспертизы. Кроме того, можно повысить отказоустойчивость критичных бизнес-систем за счет использования технологии кластеризации баз данных, получить достаточную производительность при нехватке вычислительных ресурсов и пропускной способности собственного оборудования или реализовать план аварийного восстановления (DRP). Сервис удобно также применять для резервного копирования и проверки консистентности резервных копий данных.

Для разных приложений у нас типовые конфигурации:

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

Одиночная база данных: резервное копирование и восстановление

Это базовый вариант сервиса для БД Oracle, MS SQL Server (2012/2014/2016 Standard Edition), MySQL и PostgreSQL, при котором заказчику предоставляется система с необходимыми характеристиками. Экземпляр базы данных располагается на виртуальной машине.
Системой резервного копирования Commvault резервируются файлы базы данных и журналы транзакций. Они хранятся семь дней. В течение этого периода можно восстановить БД по состоянию на момент последнего резервирования журнальных файлов (с интервалом в час).

По умолчанию резервное копирование выполняется по следующему сценарию:

• Один раз в неделю — полное резервирование.
• Каждый день сохраняется дифференциальная резервная копия.
• Каждый час сохраняется журнал транзакций.

Целевой срок восстановления (RTO) – до нескольких часов (в зависимости от объёма базы данных), целевая точка восстановления (RPO) – до 1 часа. Время восстановления сервиса в случае потери базы данных зависит от объема БД и интенсивности ее использования. В случае аппаратного сбоя система автоматически заменяется в течение нескольких минут.

Архитектура: Одиночная база данных

Одиночная база данных — время восстановления и потенциальная потеря данных:

БД повышенной защищенности

Конфигурация зависит от типа БД:

SQL Server 2012/2014/2016 Standard Edition

Database Mirroring: предоставляются две системы с необходимыми характеристиками. На одной из машин располагается основной экземпляр, на второй — резервный. Используется зеркальное отображение базы данных (Database Mirroring), которое обладает следующими преимуществами:

1. Повышает доступность базы данных. В режиме высокой безопасности с автоматическим переходом на другой ресурс и возникновении сбоя резервная копия базы данных переводится в режим «в сети» (без потери данных). В других режимах работы администратор базы данных может включить принудительное обслуживание (с возможной потерей данных) на резервной копии базы данных.
2. Повышает защиту данных. Зеркалирование базы данных обеспечивает полную избыточность данных (используется режим высокой безопасности). Кроме того, участник зеркального отображения предпринимает попытки автоматически разрешить ошибки некоторых типов, которые могут мешать чтению страницы данных. Участник, который не может прочитать страницу, запрашивает новую копию у другого участника. Если этот запрос завершился успешно, то нечитаемая страница заменяется копией, в результате чего ошибка обычно устраняется.
3. Повышает доступность рабочей базы данных при обновлениях. Чтобы свести к минимуму время простоя базы данных, участвующей в зеркалировании, можно последовательно обновить экземпляры SQL Server, на которых размещены партнеры по отработке отказа. Это вызовет простой только на время одной отработки отказа.
   В случае выхода из строя основной базы данных происходит переключение на резервную, при этом время простоя обычно составляет меньше минуты.
   Для автоматического перехода на другой ресурс (процесс, согласно которому при недоступности основного сервера зеркальный сервер берет на себя роль основного и выводит свою копию базы данных в сеть как основную базу данных); также используется дополнительный “служебный” экземпляр SQL Server — “Свидетель”, который может одновременно использоваться несколькими системами. Применяется “Режим высокой безопасности”, при котором сеанс зеркалирования базы данных работает синхронно, и в нем используются следящий сервер, а также основной сервер и зеркальный сервер. Следящий сервер “Свидетель” не обслуживает базы данных, его единственная функция заключается в поддержке автоматического перехода на резервную систему.
   В качестве последней линии защиты данных используется резервное копирование средствами Commvault. В случае аппаратного сбоя наша система автоматически обеспечит замену в течение нескольких минут.

PostgreSQL и MySQL

База данных повышенной защищённости: предоставляется две системы с необходимыми характеристиками. На одной из виртуальных машин располагается основной экземпляр, на второй — резервный. В случае выхода из строя основной базы данных происходит переключение на резервную. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой Commvault.

Архитектура: База данных повышенной защищенности

Доступность сервиса — 99,95%. RTO – от нескольких минут до 1 часа, RPO – близко или равна нулю.

БД высокой доступности и защищенности

SQL Server 2012/2014/2016 Enterprise Edition

Используются группы высокой доступности (Always On Availability Groups), которые предоставляют широкий набор параметров, позволяющих повысить уровень доступности баз данных и улучшить использование ресурсов, а также обладают следующими преимуществами:

• Поддержка до девяти реплик доступности (по умолчанию — 2 реплики). Реплика является выделенным экземпляром группы доступности, который размещается на отдельном экземпляре SQL Server и поддерживает локальную копию каждой базы данных доступности, которая принадлежит группе доступности. Каждая группа доступности поддерживает одну первичную реплику и до восьми вторичных реплик.
• Поддержка альтернативных режимов доступности: 1) асинхронная фиксация (решение аварийного восстановления, которое хорошо работает, когда реплики доступности распределены и удалены дркг от друга); 2) синхронная фиксация (отдается предпочтение высокому уровню доступности и защите данных перед производительностью за счет повышения задержки транзакций). Отдельно взятая группа доступности может поддерживать до трех реплик доступности с синхронной фиксацией, в том числе текущую первичную реплику.
• Поддержка различных форм отработки отказа другой группы доступности: 1) автоматический переход на другой ресурс; 2) запланированный переход на другой ресурс вручную; 3) принудительный переход на другой ресурс вручную.
• Возможность настройки реплик доступности для поддержки одной или обеих возможностей активных вторичных реплик: 1) доступ с подключением только для чтения, который позволяет использовать подключения только для чтения для чтения баз данных во время работы в качестве вторичной реплики; 2) выполнение операций резервного копирования для своих баз данных во время работы в качестве вторичной реплики.
• Поддержка прослушивателя (Listener) для каждой группы доступности. Listener — это сервер, к которому могут подключаться клиенты, чтобы получить доступ к базе данных из первичной или вторичной реплики группы доступности AlwaysOn. Прослушиватели группы доступности направляют входящие соединения на первичную реплику или на доступную только для чтения вторичную реплику. Listener обеспечивает быструю отработку отказа приложений после отработки отказа группы доступности.
• Поддержка гибкой политики отработки отказа для обеспечения большего контроля над отработкой отказа группы доступности.
• Поддержка автоматического восстановления страниц для защиты от повреждения.
• Поддержка шифрования и сжатия, что обеспечивает безопасный, высокопроизводительный транспорт.

В случае выхода из строя основной базы данных происходит переключение на резервную базу данных, при этом время простоя обычно составляет меньше минуты.
Каждая реплика группы доступности размещается на отдельном узле отказоустойчивого кластера Windows Server (WSFC). Развертывание WSFC требует, чтобы серверы, участвующие в WSFC (также называются узлами), были присоединены к одному и тому же домену.
В качестве последней линии защиты данных используется резервное копирование, которое выполняется системой Commvault.

Архитектура: База данных высокой доступности и защищенности (1)

БД высокой доступности и защищенности. RTO – от нескольких секунд до 1 часа, RPO – близка или равна нулю.

(1) — Данная опция в разработке. Плановый срок ноябрь 2017г.

Как это работает?

«Облачная база данных» (TS-Cloud.DBaaS) включает в себя:

• Подсистему оркестрации, обеспечивающую управление сервисом и инфраструктурой. Она взаимодействует с порталом самообслуживания и использует ресурсы облака TS-Cloud для размещения ВМ.
• Портал самообслуживания.
• Подсистему резервного копирования на базе сервиса TS-Cloud.BaaS CommVault Simpana.
• Облачную платформу TS-Cloud (OpenStack).
• Подсистему мониторинга на базе Zabbix.
• Cистему доменных имен (DNS)

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

Схема TS-Cloud.DBaaS.

После запроса услуги клиентом портал запускает шаблон стека, соответствующий выбранной клиентом СУБД, и передает в Heat необходимые параметры сервиса (имя узла, размер дисков для размещения БД и транзакционных логов и т.д.). Heat запрашивает ресурсы для сервиса у компонентов платформы виртуализации, создает ВМ из образа, подключает к ней необходимые дополнительные диски и сети, запускает ВМ. Далее ВМ инициализируется при помощи Cloud-init. Метаданные ВМ сервиса (внутренний и внешний сетевые адреса, id стека и т.д.) передаются в портал. Портал самообслуживания взаимодействует с Heat через программный интерфейс Heat-API.

Подсистема оркестрации Ansible и обеспечивает настройку и управление сервиса DBaaS и инфраструктуры, необходимой для работы сервиса. Она управляется порталом самообслуживания и использует ресурсы облака TS-Cloud для размещения ВМ.
Портал самообслуживания взаимодействует с подсистемой оркестрации на базе Ansible через REST API, реализованный при помощи открытого продукта Flansible. Данный интерфейс позволяет исполнять сценарии Ansible (скрипты), отслеживать статус и результат их исполнения.

После запуска ВМ и получения порталом самообслуживания сетевых реквизитов сервиса запускается Ansible-скрипт конфигурирования сервиса — портал через REST-API передает необходимые параметры (внешний и внутренний адрес ВМ сервиса, имя БД, кодировка, имя пользователя БД, пароли и т.д.) и запускает скрипт. В процессе работы скрипта портал отслеживает статус выполнения.

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

Портал взаимодействует с подсистемами автоматизации Heat и Ansible для создания экземпляров БД по запросу пользователя. В разделе «Каталог Услуг» пользователь может выбрать параметры конфигурацию и заказать одну или несколько услуг DBaaS.

После получения параметров заказа портал вызывает API Heat для выделения ресурсов OpenStack, получает от Heat IP-адреса созданных виртуальных машин и передает их по в Ansible для установки выбранной пользователем СУБД.

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

Миграция в облако

Часто возникает вопрос, как перенести БД в облако. Мы разработали сценарии миграции данных на облачную инфраструктуру с использованием технологий Microsoft Mirroring и Always On Availability Groups, Oracle Data Guard, Oracle Golden Gate, Oracle Dbvision. Миграция включает в себя:

• Анализ с выбором методов решения задачи.
• Исследование на готовность системы.
• Рекомендации по подготовки системы.
• Составление детального плана.
• Тестирование процедуры миграции.
• Актуализацию результатов.
• Тестирование перед запуском в эксплуатацию.
• Финальную миграцию.
• Сопровождение постмиграционного периода.
• Решение проблемных вопросов.
• Контроль качества на всех этапах работ.
• Учет всех требований по простою системы, методик и оформления миграционных процедур.

Сколько это стоит?

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

Вариант 1. Функциональное тестирование на СУБД PostgreSQL для разработчиков конфигурации «1С: Зарплата и кадры», эксплуатируемой в сети автосервисов.

Вариант 2. Пример расчета стоимости сервиса БД MS SQL для ERP MS Axapta эксплуатируемой в сети магазинов детских игрушек.

Вариант 3. Пример расчета стоимости сервиса БД Oracle для системы поддержки туристического бизнеса используемой туристическим оператором и его агентствами.

У нас на сайте можно рассчитать стоимость услуги с помощью онлайн-калькулятора.

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

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

Источник

Друзья, всех с прошедшим вчера Днем программиста! Жизни без багов и красивейшего кода!)

Мы продолжаем разбор облачных сервисов Техносерв Cloud и сегодня детально разложим, из чего состоит наша облачная база данных. Если заглянуть в результаты исследования, проведенного IDG Connect по заказу Oracle, увидим, что DBaaS скоро будет самым востребованным сервисом частного облака. Растет и число публичных сервисов DBaaS.

Снижение затрат за счет консолидации ресурсов, масштабирование по мере необходимости, контроль расходов, доступ к данным из любого места – всё это факторы, влияющие на выбор в пользу облачной базы данных. На рынке облачных услуг свои базы данных предлагают его ведущие игроки – Amazon Web Services, IBM, Microsoft и Oracle. Но есть одна проблема — все они разворачивают БД за пределами России, более того, далеко не все из них предлагают сервис – администрирование, управление производительностью, круглосуточную техническую поддержку (желательно на русском языке), – а только платформу.

Чтобы ответить на этот запрос рынка, мы запустили свой сервис и стали единственным российским облачный провайдером, работающим с четырьмя основными базами данных под ФЗ-152 и ФЗ-242.

Рынок DBaaS

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

По прогнозу Technavio, в ближайшие годы мировой рынок DBaaS будет демонстрировать экспоненциальный рост — более чем на 65% ежегодно. Вместо того, чтобы вкладывать большие средства в аппаратные платформы, многие компании склонны инвестировать средства в услуги с еженедельной, ежеквартальной или ежегодной оплатой по подписке.

Объем работ по поддержке собственных многочисленных баз данных и серверов может быть весьма серьезным. Стандартизация, когда все в одной среде, переводит процесс на уровень выше и упрощает работу с БД. Тут ключевое слово – «упрощает», отмечают аналитики IDC.

Судя по результатам опросов, реляционные облачные СУБД – в числе самых популярных сервисов публичных облаков. Их используют 35% респондентов, экспериментируют -14%, планируют внедрение – 12% (источник – RightScale).

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

По данным Forrester, AWS – лидер рынка DBaaS. Amazon Relational Database Service позволяет работать с БД Oracle, Microsoft SQL Server, MySQL, MariaDB и PostgreSQL в среде EC2. Из 100 тыс. исследованных 2ndWatch экземпляров БД 67% представляли Amazon RDS.

Рост оборота мирового рынка DBaaS в млн. долларов (по данным 451 Research).

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

Рост сервиса Oracle DBaaS в мире.

Аналитики Markets&Markets прогнозируют, что рынок облачных СУБД/DBaaS вырастет с 1,07 млрд. долларов в 2014 году до 14,05 млрд. долларов к 2019 году при ежегодных темпах роста (CAGR) в 46%.

Что лучше, сервис или своя СУБД?

Облачная база данных или DBaaS (Database as a Service) – это любая СУБД, предоставляемая по подписке как облачный сервис в рамках платформенной модели обслуживания. То есть DBaaS – один из сервисов PaaS. В случае PaaS, «платформы как сервис», заказчик получает уже установленное и настроенное программное обеспечение для разработки и тестирования или развертывания приложений. Для заказчика создается БД нужной конфигурации в одном из следующих вариантов:

• БД без виртуализации (на физической машине)
• БД на виртуальной машине
• БД в виде контейнера в многоарендной базе данных

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

Отдельные базы данных консолидируются на физических серверах и группируются в облачных пулах. Любой сервер из пула может размещать один или несколько экземпляров баз данных (источник – Oracle).

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

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

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

Как показывает практика, многие заказчики DBaaS отмечают:

• Снижение общих расходов.
• Большую независимость бизнес-пользователей от ИТ-подразделений.
• Снижение рисков в сценариях ИТ-планирования.
• Большую предсказуемость и гибкость.
• Разработчики приложений достаточную степень свободы для творчества и инноваций.
• DBaaS улучшает работу администраторов БД. Они больше концентрируются на задачах бизнеса и меньше — на рутинных операциях.

Отличия DBaaS от традиционного подхода (источник – Oracle).

Основные преимущества облачной БД

1. Начнем с того, что не каждая компания может выделить отдельного сотрудника для мониторинга и управления своей СУБД. Результат — высокие риски остановки бизнес-процессов, прерывание производственных процессов, потеря данных и прочие неприятности. С сервисом «Облачная база данных» все эти заботы мы берем на себя. Преимущества DBaaS:
   • высокая масштабируемость,
   • снижение затрат,
   • быстрое предоставление услуг,
   • повышение надежности и безопасности.

   
   
2. Это не только надежнее и безопаснее, но и выгоднее. Как уже отмечалось, компания может существенно сэкономить на зарплатах DBA. Действительно квалифицированных специалистов на рынке очень мало, и часто те, что есть, перегружены текущими задачами. В облаке нет необходимости заботиться о настройках сервера БД, и цена поддержки обычно оказывается значительно меньше. К тому же собственные специалисты по БД не всегда способны обеспечить необходимый уровень сервиса, а облачные решения гарантируют высокий уровень доступности – мы круглосуточно осуществляем мониторинг на уровне платформы и на уровне СУБД.
3. На самом деле многие компании вообще не имеют специалистов по БД в штате. Одно дело запустить SQL Server или MySQL на сервере и обеспечить работу приложения, другое — исправить ошибки в БД и оптимизировать ее функционирование. В случае возникновения реальных проблем придется срочно искать внешнего специалиста. В облаке «узкие места» БД становятся головной болью провайдера. К тому же он вполне может нанять специалистов по БД и поддерживать высокий уровень их квалификации. А к вашим услугам — первая линия поддержки. Это к вопросу выбора места размещения БД – «у себя» или в облаке.
4. Еще одно преимущество сервиса – быстро развертываемые готовые типовые конфигурации, оптимизированные по производительности под типовые задачи использования баз данных. Создание индивидуальной конфигурации и конфигураций с кластеризацией может занимать до трех рабочих дней.
5. Сервис «Облачная база данных» использует резервируемые виртуальные ресурсы, предусматривает отчеты по доступности, базовое администрирование БД и ОС, резервное копирование БД и восстановление из резервной копии, управление емкостью хранения. Дополнительные услуги — мониторинг производительности БД, мониторинг бизнес процессов, расширенное администрирование и резервирование с индивидуальным расписанием резервного копирования и глубины хранения. Профессиональные услуги включают также аудит, консультации, миграцию, в том числе конвертацию и перенос данных (с предоставлением СХД). И конечно, мы обеспечиваем отказоустойчивость и повышенную доступность баз данных. Ведь база данных является одним из наиболее критичных сервисов для предприятия.

Четыре в одном

Переходим к описанию нашего сервиса «Облачная база данных». Как мы уже сказали, эта услуга может работать с четырьмя основными базами данных: мы предоставляем готовые к работе базы данных Microsoft SQL (лицензии MS по модели SPLA), PostgreSQL и MySQL, а также хостинг Oracle.

Тарифный план предусматривает более 80 вариантов оказания услуги под различные классы экземпляров баз данных.

Клиентам доступны следующие версии и редакции СУБД:

Особенности услуги «Облачная база данных»

• Высокая производительность.
• Оптимизированные в соответствии с рекомендациями разработчиков и лучшими практиками конфигурации ОС и СУБД.
• Профессиональная техническая поддержка, в которой работают специалисты интегратора по базам данных.
• Услуга создавалась с учетом ФЗ-149, ФЗ-152 и ФЗ-242.
• Ценовое предложение в среднем на 35-40% выгоднее западных облачных платформ (с учетом затрат на работы по администрированию баз данных и операционных систем которые по умолчанию включены в состав услуги).

Согласно законодательству РФ, основными документами, определяющими требования к защите информации, являются:

• Закон ФЗ-149 «Об информации, информационных технологиях и о защите информации».
• Закон ФЗ-152 «О персональных данных».
• Приказы ФСТЭК России №17 и №21.
• Закон ФЗ-242, который уточняет ФЗ-152 и обязывает операторов персональных данных обрабатывать и хранить персональные данные россиян с использованием баз данных, размещенных на территории РФ.

По умолчанию наш сервис предоставляется клиентам в соответствии с 3-й и 4-й категориями защищенности ПДн (о безопасности данных), а по запросу – в аттестованном сегменте* платформы, согласно всем требованиям защиты информации, установленным ФСТЭК России.

*Аттестат соответствия требованиям по безопасности информации

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

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

Санкции также подталкивают наших потенциальных заказчиков на поиск альтернативных решений на российском рынке. На фоне высокого курса валют и сложной политической ситуации они ищут возможные пути минимизации рисков, и «Облачная база данных», как российский сервис, предлагаемый на территории России по рублевым ценам, заслуживает пристального внимания. Облачные сервисы могут выступить в качестве альтернативы покупке ИТ-оборудования западных вендоров, а открытое ПО, на основе которого сервис функционирует, отвечает курсу на импортозамещение. Open Source платформы, такие как OpenStack, — одна из ключевых альтернатив проприетарным решениям.

Наш сервис включает все опции, обеспечивающие доступность базы данных:

• динамически расширяемые вычислительные ресурсы;
• администрирование ОС и СУБД силами провайдера;
• мониторинг СУБД;
• резервное копирование данных.

И предлагает следующие варианты подключения к БД:

• сети общего пользования (публичный интернет).
• защищенное VPN-подключение поверх интернета (IPSec VPN).
• защищенный L2 VPN-канал связи.
• сеть IP VPN.
• через внутреннюю сеть, при условии размещения серверов приложений в облачной платформе Техносерв Cloud (скорость 10 Гбит/с).

Администрирование БД включает в себя выполнение следующих операций:

• решение инцидентов в работе БД;
• установка и настройка клиента и ПО БД;
• управление доступом к БД;
• резервное копирование БД;
• обновление ПО БД;
• мониторинг доступности БД;
• мониторинг состояния БД и резервных копий, периодическое тестирование резервных копий (1 раз в месяц);
• управление пространством;
• анализ журналов и файлов трассировки;
• восстановление БД из резервных копий в случае сбоя*.

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

Администрирование операционных систем включает в себя выполнение следующих операций:

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

Для реализации сервиса мы используем в своей облачной платформе сегмент OpenStack со следующими возможностями:

• среда виртуализации OpenStack/KVM;
• обмен данными между ВМ — до 10 Гбит\с;
• система управления OpenStack (основана на релизе Mitaka);
• использование модуля виртуализации сети Neutron позволяет реализовывать функции NAT, VPNaaS, FWaaS, LBaaS, маршрутизации;
• программно-определяемое хранилище (SDS) — тройное резервирование обеспечивает не только сохранность данных при выходе из строя любого диска, узла или группы узлов, но и автоматизированное восстановление копий на других узлах.

Ресурсы у сегмента OpenStack (с учетом резервирования):

• vCPU – 1000 ядер.
• vRam – 1400 Гбайт.
• vHDD – 24000 Гбайт.

Какие задачи решаем?

Наша услуга сокращает эксплуатационные затраты, в которые среди прочего входят зарплаты администраторов БД (например, в Московском регионе зарплата Oracle DBA в месяц может доходить до 200 т.р.), а также снижает риски, связанные с инфраструктурой, на которой развернуты БД. Ее можно использовать для запуска новых или обновления существующих бизнес-приложений, таких как корпоративная система электронной почты, системы CRM и HRM, бухгалтерское, складское, финансовое и аналитическое ПО.

Она сводит к минимуму риск недоступности бизнес-приложений из-за ошибок в работе баз данных, снижает вероятность потери данных из-за несвоевременного резервного копирования, дает возможность обеспечить высокую доступность БД в условиях отсутствия или недостаточности собственных ресурсов/экспертизы. Кроме того, можно повысить отказоустойчивость критичных бизнес-систем за счет использования технологии кластеризации баз данных, получить достаточную производительность при нехватке вычислительных ресурсов и пропускной способности собственного оборудования или реализовать план аварийного восстановления (DRP). Сервис удобно также применять для резервного копирования и проверки консистентности резервных копий данных.

Для разных приложений у нас типовые конфигурации:

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

Одиночная база данных: резервное копирование и восстановление

Это базовый вариант сервиса для БД Oracle, MS SQL Server (2012/2014/2016 Standard Edition), MySQL и PostgreSQL, при котором заказчику предоставляется система с необходимыми характеристиками. Экземпляр базы данных располагается на виртуальной машине.
Системой резервного копирования Commvault резервируются файлы базы данных и журналы транзакций. Они хранятся семь дней. В течение этого периода можно восстановить БД по состоянию на момент последнего резервирования журнальных файлов (с интервалом в час).

По умолчанию резервное копирование выполняется по следующему сценарию:

• Один раз в неделю — полное резервирование.
• Каждый день сохраняется дифференциальная резервная копия.
• Каждый час сохраняется журнал транзакций.

Целевой срок восстановления (RTO) – до нескольких часов (в зависимости от объёма базы данных), целевая точка восстановления (RPO) – до 1 часа. Время восстановления сервиса в случае потери базы данных зависит от объема БД и интенсивности ее использования. В случае аппаратного сбоя система автоматически заменяется в течение нескольких минут.

Архитектура: Одиночная база данных

Одиночная база данных — время восстановления и потенциальная потеря данных:

БД повышенной защищенности

Конфигурация зависит от типа БД:

SQL Server 2012/2014/2016 Standard Edition

Database Mirroring: предоставляются две системы с необходимыми характеристиками. На одной из машин располагается основной экземпляр, на второй — резервный. Используется зеркальное отображение базы данных (Database Mirroring), которое обладает следующими преимуществами:

1. Повышает доступность базы данных. В режиме высокой безопасности с автоматическим переходом на другой ресурс и возникновении сбоя резервная копия базы данных переводится в режим «в сети» (без потери данных). В других режимах работы администратор базы данных может включить принудительное обслуживание (с возможной потерей данных) на резервной копии базы данных.
2. Повышает защиту данных. Зеркалирование базы данных обеспечивает полную избыточность данных (используется режим высокой безопасности). Кроме того, участник зеркального отображения предпринимает попытки автоматически разрешить ошибки некоторых типов, которые могут мешать чтению страницы данных. Участник, который не может прочитать страницу, запрашивает новую копию у другого участника. Если этот запрос завершился успешно, то нечитаемая страница заменяется копией, в результате чего ошибка обычно устраняется.
3. Повышает доступность рабочей базы данных при обновлениях. Чтобы свести к минимуму время простоя базы данных, участвующей в зеркалировании, можно последовательно обновить экземпляры SQL Server, на которых размещены партнеры по отработке отказа. Это вызовет простой только на время одной отработки отказа.
   В случае выхода из строя основной базы данных происходит переключение на резервную, при этом время простоя обычно составляет меньше минуты.
   Для автоматического перехода на другой ресурс (процесс, согласно которому при недоступности основного сервера зеркальный сервер берет на себя роль основного и выводит свою копию базы данных в сеть как основную базу данных); также используется дополнительный “служебный” экземпляр SQL Server — “Свидетель”, который может одновременно использоваться несколькими системами. Применяется “Режим высокой безопасности”, при котором сеанс зеркалирования базы данных работает синхронно, и в нем используются следящий сервер, а также основной сервер и зеркальный сервер. Следящий сервер “Свидетель” не обслуживает базы данных, его единственная функция заключается в поддержке автоматического перехода на резервную систему.
   В качестве последней линии защиты данных используется резервное копирование средствами Commvault. В случае аппаратного сбоя наша система автоматически обеспечит замену в течение нескольких минут.

PostgreSQL и MySQL

База данных повышенной защищённости: предоставляется две системы с необходимыми характеристиками. На одной из виртуальных машин располагается основной экземпляр, на второй — резервный. В случае выхода из строя основной базы данных происходит переключение на резервную. Время восстановления сервиса в случае потери базы данных не превышает 15 минут. Резервное копирование выполняется системой Commvault.

Архитектура: База данных повышенной защищенности

Доступность сервиса — 99,95%. RTO – от нескольких минут до 1 часа, RPO – близко или равна нулю.

БД высокой доступности и защищенности

SQL Server 2012/2014/2016 Enterprise Edition

Используются группы высокой доступности (Always On Availability Groups), которые предоставляют широкий набор параметров, позволяющих повысить уровень доступности баз данных и улучшить использование ресурсов, а также обладают следующими преимуществами:

• Поддержка до девяти реплик доступности (по умолчанию — 2 реплики). Реплика является выделенным экземпляром группы доступности, который размещается на отдельном экземпляре SQL Server и поддерживает локальную копию каждой базы данных доступности, которая принадлежит группе доступности. Каждая группа доступности поддерживает одну первичную реплику и до восьми вторичных реплик.
• Поддержка альтернативных режимов доступности: 1) асинхронная фиксация (решение аварийного восстановления, которое хорошо работает, когда реплики доступности распределены и удалены дркг от друга); 2) синхронная фиксация (отдается предпочтение высокому уровню доступности и защите данных перед производительностью за счет повышения задержки транзакций). Отдельно взятая группа доступности может поддерживать до трех реплик доступности с синхронной фиксацией, в том числе текущую первичную реплику.
• Поддержка различных форм отработки отказа другой группы доступности: 1) автоматический переход на другой ресурс; 2) запланированный переход на другой ресурс вручную; 3) принудительный переход на другой ресурс вручную.
• Возможность настройки реплик доступности для поддержки одной или обеих возможностей активных вторичных реплик: 1) доступ с подключением только для чтения, который позволяет использовать подключения только для чтения для чтения баз данных во время работы в качестве вторичной реплики; 2) выполнение операций резервного копирования для своих баз данных во время работы в качестве вторичной реплики.
• Поддержка прослушивателя (Listener) для каждой группы доступности. Listener — это сервер, к которому могут подключаться клиенты, чтобы получить доступ к базе данных из первичной или вторичной реплики группы доступности AlwaysOn. Прослушиватели группы доступности направляют входящие соединения на первичную реплику или на доступную только для чтения вторичную реплику. Listener обеспечивает быструю отработку отказа приложений после отработки отказа группы доступности.
• Поддержка гибкой политики отработки отказа для обеспечения большего контроля над отработкой отказа группы доступности.
• Поддержка автоматического восстановления страниц для защиты от повреждения.
• Поддержка шифрования и сжатия, что обеспечивает безопасный, высокопроизводительный транспорт.

В случае выхода из строя основной базы данных происходит переключение на резервную базу данных, при этом время простоя обычно составляет меньше минуты.
Каждая реплика группы доступности размещается на отдельном узле отказоустойчивого кластера Windows Server (WSFC). Развертывание WSFC требует, чтобы серверы, участвующие в WSFC (также называются узлами), были присоединены к одному и тому же домену.
В качестве последней линии защиты данных используется резервное копирование, которое выполняется системой Commvault.

Архитектура: База данных высокой доступности и защищенности (1)

БД высокой доступности и защищенности. RTO – от нескольких секунд до 1 часа, RPO – близка или равна нулю.

(1) — Данная опция в разработке. Плановый срок ноябрь 2017г.

Как это работает?

«Облачная база данных» (TS-Cloud.DBaaS) включает в себя:

• Подсистему оркестрации, обеспечивающую управление сервисом и инфраструктурой. Она взаимодействует с порталом самообслуживания и использует ресурсы облака TS-Cloud для размещения ВМ.
• Портал самообслуживания.
• Подсистему резервного копирования на базе сервиса TS-Cloud.BaaS CommVault Simpana.
• Облачную платформу TS-Cloud (OpenStack).
• Подсистему мониторинга на базе Zabbix.
• Cистему доменных имен (DNS)

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

Схема TS-Cloud.DBaaS.

После запроса услуги клиентом портал запускает шаблон стека, соответствующий выбранной клиентом СУБД, и передает в Heat необходимые параметры сервиса (имя узла, размер дисков для размещения БД и транзакционных логов и т.д.). Heat запрашивает ресурсы для сервиса у компонентов платформы виртуализации, создает ВМ из образа, подключает к ней необходимые дополнительные диски и сети, запускает ВМ. Далее ВМ инициализируется при помощи Cloud-init. Метаданные ВМ сервиса (внутренний и внешний сетевые адреса, id стека и т.д.) передаются в портал. Портал самообслуживания взаимодействует с Heat через программный интерфейс Heat-API.

Подсистема оркестрации Ansible и обеспечивает настройку и управление сервиса DBaaS и инфраструктуры, необходимой для работы сервиса. Она управляется порталом самообслуживания и использует ресурсы облака TS-Cloud для размещения ВМ.
Портал самообслуживания взаимодействует с подсистемой оркестрации на базе Ansible через REST API, реализованный при помощи открытого продукта Flansible. Данный интерфейс позволяет исполнять сценарии Ansible (скрипты), отслеживать статус и результат их исполнения.

После запуска ВМ и получения порталом самообслуживания сетевых реквизитов сервиса запускается Ansible-скрипт конфигурирования сервиса — портал через REST-API передает необходимые параметры (внешний и внутренний адрес ВМ сервиса, имя БД, кодировка, имя пользователя БД, пароли и т.д.) и запускает скрипт. В процессе работы скрипта портал отслеживает статус выполнения.

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

Портал взаимодействует с подсистемами автоматизации Heat и Ansible для создания экземпляров БД по запросу пользователя. В разделе «Каталог Услуг» пользователь может выбрать параметры конфигурацию и заказать одну или несколько услуг DBaaS.

После получения параметров заказа портал вызывает API Heat для выделения ресурсов OpenStack, получает от Heat IP-адреса созданных виртуальных машин и передает их по в Ansible для установки выбранной пользователем СУБД.

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

Миграция в облако

Часто возникает вопрос, как перенести БД в облако. Мы разработали сценарии миграции данных на облачную инфраструктуру с использованием технологий Microsoft Mirroring и Always On Availability Groups, Oracle Data Guard, Oracle Golden Gate, Oracle Dbvision. Миграция включает в себя:

• Анализ с выбором методов решения задачи.
• Исследование на готовность системы.
• Рекомендации по подготовки системы.
• Составление детального плана.
• Тестирование процедуры миграции.
• Актуализацию результатов.
• Тестирование перед запуском в эксплуатацию.
• Финальную миграцию.
• Сопровождение постмиграционного периода.
• Решение проблемных вопросов.
• Контроль качества на всех этапах работ.
• Учет всех требований по простою системы, методик и оформления миграционных процедур.

Сколько это стоит?

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

Вариант 1. Функциональное тестирование на СУБД PostgreSQL для разработчиков конфигурации «1С: Зарплата и кадры», эксплуатируемой в сети автосервисов.

Вариант 2. Пример расчета стоимости сервиса БД MS SQL для ERP MS Axapta эксплуатируемой в сети магазинов детских игрушек.

Вариант 3. Пример расчета стоимости сервиса БД Oracle для системы поддержки туристического бизнеса используемой туристическим оператором и его агентствами.

У нас на сайте можно рассчитать стоимость услуги с помощью онлайн-калькулятора.

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

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

Предлагаю всем близким к фронтенду посмотреть доклады с прошедшего в августе митапа Frontend MIX. Приглашенные спикеры из Альфа-Лаборатории, Яндекс.Денег и Epam делятся нюансами мобильной оптимизации и выбора между Npm v5, Yarn или pnpm, а также секретами построения дизайн-системы на БЭМ и React.

Под катом вы найдете три видео.

#1 Как ускорить загрузку сайтов в эпоху смартфонов

Андрей Мелихов, ведущий разработчик Яндекс.Денег, рассказывает о способах повысить скорость загрузки сайтов на смартфонах.

В докладе упоминаются современные способы передачи контента (HTTP/2: preload, server push), профилирование загрузки в Chrome Dev Tools и оптимизация JavaScript.

#2 Как в Альфа-Лаборатории сделали гибкую и расширяемую дизайн-систему с помощью БЭМ и React

В своем докладе Виталий Галахов делится опытом использования методологии БЭМ в Альфа-Лаборатории. Сначала они попробовали БЭМ, потом отказались от нее, а позже все же нашли, где методология оказалась полезной.

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

#3 Увлекательный выбор между Npm v5, Yarn или pnpm

Закрывал митап разработчик Epam Майкл Башуров, который поделился своим мнением по поводу выбора менеджера пакетов. Обсуждались как сакральные вопросы вроде «нужен ли Yarn» и «когда вышел Npm v5», так и плюсы использования менее популярных продуктов вроде pnpm.

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

Напомню, что за всеми нашими мероприятиями вы можете следить на Я.Встречах – записывайтесь и приходите в гости!

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

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

Предлагаю всем близким к фронтенду посмотреть доклады с прошедшего в августе митапа Frontend MIX. Приглашенные спикеры из Альфа-Лаборатории, Яндекс.Денег и Epam делятся нюансами мобильной оптимизации и выбора между Npm v5, Yarn или pnpm, а также секретами построения дизайн-системы на БЭМ и React.

Под катом вы найдете три видео.

#1 Как ускорить загрузку сайтов в эпоху смартфонов

Андрей Мелихов, ведущий разработчик Яндекс.Денег, рассказывает о способах повысить скорость загрузки сайтов на смартфонах.

В докладе упоминаются современные способы передачи контента (HTTP/2: preload, server push), профилирование загрузки в Chrome Dev Tools и оптимизация JavaScript.

#2 Как в Альфа-Лаборатории сделали гибкую и расширяемую дизайн-систему с помощью БЭМ и React

В своем докладе Виталий Галахов делится опытом использования методологии БЭМ в Альфа-Лаборатории. Сначала они попробовали БЭМ, потом отказались от нее, а позже все же нашли, где методология оказалась полезной.

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

#3 Увлекательный выбор между Npm v5, Yarn или pnpm

Закрывал митап разработчик Epam Майкл Башуров, который поделился своим мнением по поводу выбора менеджера пакетов. Обсуждались как сакральные вопросы вроде «нужен ли Yarn» и «когда вышел Npm v5», так и плюсы использования менее популярных продуктов вроде pnpm.

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

Напомню, что за всеми нашими мероприятиями вы можете следить на Я.Встречах – записывайтесь и приходите в гости!

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

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

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


/ Flickr / kosheahan / CC

В рейтинге самых производительных компьютеров в мире, представленном в июне на Международной конференции суперкомпьютеров во Франкфурте, разработкам Китая принадлежат две первые строчки. Их занимают Sunway TaihuLight и Тяньхэ-2, которые имеют производительность в 125,43 петафлопс и 54,9 петафлопс соответственно.

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

Для этого Китай готов финансировать как минимум три конкурирующие группы разработчиков: Sugon, Оборонный научно-технический университет НОАК, который разрабатывал суперкомпьютеры Tianhe, и Sunway, занимавшейся TahiuLight. Власти хотят выбрать проект, который обеспечит высочайшую производительность и будет готов к немедленному использованию после создания. Ожидается, что траты на суперкомпьютер составят от одного до двух миллиардов юаней (150–300 млн долларов).

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

Китай инвестировал значительные средства в глубоководную добычу полезных ископаемых и реализует глобальный проект нового Шелкового пути. В результате всех инициатив у страны непременно возникнет необходимость по сбору и обработке огромных объемов данных.

Исследователи уверены, что эксафлопсные вычисления помогут проводить комплексное моделирование океана и решать сложнейшие проблемы. Фэн Лицян (Feng Liqiang), глава Marine Science Data Centre в Циндао, считает, что суперкомпьютер сможет собрать все данные, связанные с морской средой, для проведения всестороннего анализа. В результате Китай добьется океанических симуляций с беспрецедентно высоким разрешением, что поможет формировать надежные прогнозы в таких вопросах, как изменение климата на планете.

Эксафлопсные гонки

Поскольку создание суперкомпьютера имеет стратегическое значение, а Titan из национальной лаборатории Ок-Ридж, США, располагается на четвертой строчке в рейтинге самых быстрых устройств, в июне Министерство энергетики Штатов приняло решение сократить разрыв с Китаем. Оно объявило о финансировании работы шести компаний — AMD, Cray, HPE, IBM, Intel и Nvidia — в размере $258 млн на ниве эксафлопсных вычислений. Строительство действующего прототипа назначено на 2021 год.

Чтобы притормозить конкурентов, в 2015 году правительство США даже запретили Intel поставлять свои самые быстрые чипы для проектов по созданию суперкомпьютеров в Китае.

Несмотря на это, Китай анонсировал запуск прототипа устройства Tianhe-3 для генетических исследований в первом квартале 2017 года с выходом на полную мощность к 2020 году. Сегодня в стране обещают продемонстрировать все возможности нового эксафлопсного компьютера в 2019 году.

В то же время в августе Национальная лаборатория Ок-Ридж начала сборку Summit — системы IBM–NVIDIA, которая имеет шансы стать самым мощным суперкомпьютером в мире. Ожидается, что система будет доступна для научных исследований к январю 2019 года.


/ wikimedia / Titan / PD

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

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

Проблемы эксафлопсных суперкомпьютеров

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

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

Стив Конуэй (Steve Conway), из научного агентства Riken, отмечает, что «гонка за эксафлопсами», так или иначе, продвигает вперед технологию суперкомпьютеров и искусственного интеллекта. Он прогнозирует, что существующие проблемы будут преодолены, и первые эксафлопсные суперкомпьютеры появятся в списке 500 самых быстрых компьютеров в 2021 году, а уже к 2023 году станут обычным явлением.

Уже сегодня китайский Sunway TaihuLight добился моделирования Вселенной с 10 триллионами цифровых частиц, а ученые из Цюрихского университета воссоздали 25 миллиардов виртуальных галактик, состоящих из 2 триллионов цифровых частиц. В любом случае в гонке стран за эксафлопсами выиграет в первую очередь наука.

P.S. О чем еще мы пишем в нашем блоге:

• Виртуальный или физический сервер? Сравнение расходов
• Технологии охлаждения дата-центров
• Подборка материалов об облаках, дата-центрах и разработке сервисов

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

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


/ Flickr / kosheahan / CC

В рейтинге самых производительных компьютеров в мире, представленном в июне на Международной конференции суперкомпьютеров во Франкфурте, разработкам Китая принадлежат две первые строчки. Их занимают Sunway TaihuLight и Тяньхэ-2, которые имеют производительность в 125,43 петафлопс и 54,9 петафлопс соответственно.

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

Для этого Китай готов финансировать как минимум три конкурирующие группы разработчиков: Sugon, Оборонный научно-технический университет НОАК, который разрабатывал суперкомпьютеры Tianhe, и Sunway, занимавшейся TahiuLight. Власти хотят выбрать проект, который обеспечит высочайшую производительность и будет готов к немедленному использованию после создания. Ожидается, что траты на суперкомпьютер составят от одного до двух миллиардов юаней (150–300 млн долларов).

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

Китай инвестировал значительные средства в глубоководную добычу полезных ископаемых и реализует глобальный проект нового Шелкового пути. В результате всех инициатив у страны непременно возникнет необходимость по сбору и обработке огромных объемов данных.

Исследователи уверены, что эксафлопсные вычисления помогут проводить комплексное моделирование океана и решать сложнейшие проблемы. Фэн Лицян (Feng Liqiang), глава Marine Science Data Centre в Циндао, считает, что суперкомпьютер сможет собрать все данные, связанные с морской средой, для проведения всестороннего анализа. В результате Китай добьется океанических симуляций с беспрецедентно высоким разрешением, что поможет формировать надежные прогнозы в таких вопросах, как изменение климата на планете.

Эксафлопсные гонки

Поскольку создание суперкомпьютера имеет стратегическое значение, а Titan из национальной лаборатории Ок-Ридж, США, располагается на четвертой строчке в рейтинге самых быстрых устройств, в июне Министерство энергетики Штатов приняло решение сократить разрыв с Китаем. Оно объявило о финансировании работы шести компаний — AMD, Cray, HPE, IBM, Intel и Nvidia — в размере $258 млн на ниве эксафлопсных вычислений. Строительство действующего прототипа назначено на 2021 год.

Чтобы притормозить конкурентов, в 2015 году правительство США даже запретили Intel поставлять свои самые быстрые чипы для проектов по созданию суперкомпьютеров в Китае.

Несмотря на это, Китай анонсировал запуск прототипа устройства Tianhe-3 для генетических исследований в первом квартале 2017 года с выходом на полную мощность к 2020 году. Сегодня в стране обещают продемонстрировать все возможности нового эксафлопсного компьютера в 2019 году.

В то же время в августе Национальная лаборатория Ок-Ридж начала сборку Summit — системы IBM–NVIDIA, которая имеет шансы стать самым мощным суперкомпьютером в мире. Ожидается, что система будет доступна для научных исследований к январю 2019 года.


/ wikimedia / Titan / PD

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

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

Проблемы эксафлопсных суперкомпьютеров

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

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

Стив Конуэй (Steve Conway), из научного агентства Riken, отмечает, что «гонка за эксафлопсами», так или иначе, продвигает вперед технологию суперкомпьютеров и искусственного интеллекта. Он прогнозирует, что существующие проблемы будут преодолены, и первые эксафлопсные суперкомпьютеры появятся в списке 500 самых быстрых компьютеров в 2021 году, а уже к 2023 году станут обычным явлением.

Уже сегодня китайский Sunway TaihuLight добился моделирования Вселенной с 10 триллионами цифровых частиц, а ученые из Цюрихского университета воссоздали 25 миллиардов виртуальных галактик, состоящих из 2 триллионов цифровых частиц. В любом случае в гонке стран за эксафлопсами выиграет в первую очередь наука.

P.S. О чем еще мы пишем в нашем блоге:

• Виртуальный или физический сервер? Сравнение расходов
• Технологии охлаждения дата-центров
• Подборка материалов об облаках, дата-центрах и разработке сервисов

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

В предыдущей статье «SDAccel – первое знакомство» я попытался описать основы применения OpenCL на ПЛИС Xilinx. Теперь настало время поделиться результатами экспериментов по передаче данных на модуле ADP-PCIe-KU3. Проверяется передача данных в обоих направлениях. Исходный код программ размещён на GitHub: https://github.com/dsmv/sdaccel

Аппаратура

Все эксперименты выполнены на модуле ADM-PCIe_KU3 компании Alpha-Data

Центральным элементом является ПЛИС Xilinx Kintex UltraScale KU060
К ПЛИС подключены два модуля SODIMM DDR3-1600; Ширина памяти 72 бита, это даёт возможность использовать контроллер памяти с коррекцией ошибок.

Существует возможность подключения двух QSFP модулей. Каждый QSFP модуль это четыре двунаправленные линии со скоростью передачи до 10 Гбит/с. Это даёт возможность использовать 1G, 10G, 40G Ethernet, в том числе реализовать Low-Latency Network Card. Также есть интересное свойство – ввод секундной метки от GPS приёмника. Но в данной работе всё это не используется.

Сервер NIMBIX

Сервер NIMBIX предоставляет разные вычислительные услуги, в том числе среду разработки SDAccel и что более важно – выполнение программы на выбранном аппаратном модуле.

Модель вычислителя

Хочу напомнить, что из себя представляет система OpenCL.

Система состоит из HOST компьютера и вычислителя, которые связаны между собой по шине. В данном случае это PCI Express v3.0 x8;

Прикладное программное обеспечение состоит из двух частей:

• Программа HOST компьютера.
• Одна или несколько функций для работы на вычислителе.

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

Для работы прикладного ПО требуется инфраструктура, которую должен кто-то предоставить. В данном случае — компания Xilinx. В состав инфраструктуры входят:

• библиотека opencl — реализация функций стандарта OpenCL.
• драйвер модуля — обеспечивает взаимодействие с модулем.
• пакет DSA. Это основа для разработки собственной прошивки ПЛИС.

Пакет DSA содержит базовую прошивку, в состав которой входят контроллеры для PCI Express, динамической памяти и возможно для других узлов. В составе базовой прошивки есть элемент, который называется OpenCL Region. Вот внутри именно этого элемента и будут реализованы все функции OpenCL kernels. Загрузка прошивки внутрь OpenCL Regions производится через PCI Express с использованием технологии частичной перезагрузки (Partial Reconfiguration). Надо отметить, что Xilinx сильно продвинулся в скорости загрузки. Если в предыдущих версиях загрузка занимала несколько минут, что сейчас около 5 секунд. А в версии 2017.2 объявлено что можно вообще не проводить повторную загрузку прошивки.

На данный момент для модуля ADM-PCIe-KU3 в составе пакета SDAccel доступно два пакета:

• xilinx:adm-pcie-ku3:2ddr:3.3
• xilinx:adm-pcie-ku3:2ddr-xpr:4.0

Оба пакета имеют поддержку двух контроллеров памяти и PCI Express v3.0 x8; Обратите внимание на суффикс -xpr. Это достаточно важное различие. Вариант без xpr фиксирует положение DDR контроллеров и PCI Express. Вариант с xpr фиксирует только положение PCI Express, а контроллеры DDR участвуют в трассировке прикладных функций OpenCL. Это различие приводит и к различиям в результатах. Вариант без xpr разводится быстрее, а вариант с xpr может получить более оптимальную трассировку. Для данного проекта получилось 1 час 11 минут для варианта без xpr и 1 час 32 минуты для варианта xpr. Логи здесь.

Кстати, в состав каждого DSA пакета входит свой драйвер.

Программа CHECK_TRANSFER

Программа предназначена для проверки непрерывной передачи данных в трёх режимах:

• Из ПЛИС в SODIM и в компьютер
• Из компьютера в SODIMM и в ПЛИС
• Одновременная передача в двух направлениях

На мой взгляд проверка скорости работы без проверки данных особого смысла не имеет. Поэтому я с помощью OpenCL реализовал на ПЛИС узел генератора тестовой последовательности и узел проверки тестовой последовательности.

Стандарт OpenCL предусматривает обмен между устройством и компьютером только через глобальную память устройства. Обычно это динамическая память на SODIMM. И здесь возникает очень интересный вопрос о возможности передачи данных с предельными скоростями. На модуле ADM-PCIe-KU3 применены два SODIM DDR3-1600. Скорость обмена для одного SODIMM около 10 Гбайт/с. Скорость обмена по шине PCI Express v3.0 x8 – около 5 Гбайт/с (пока получилось намного меньше). Т.е. существует возможность записывать в память один блок поступающий от PCI Express и одновременно считывать второй блок для обработки внутри ПЛИС. А что делать если надо ещё возвращать результат? PCI Express обеспечивает двунаправленный поток на высокой скорости. Но у памяти шина одна, и скорость будет делиться между чтением и записью. Вот здесь и нужен второй SODIMM. У нас существует возможность указать в каком именно модуле будет размещён буфер для обработки.

Операционная система

SDAccel может работать только под некоторыми системами Linux. В списке доступных систем CentOS 6.8, CentOS 7.3, Ubuntu 16.04, RedHat 6.8, RedHat 7.3; Первые эксперименты я начинал на CentOs 6.7; Далее попробовал использовать Ubuntu 16.04, но там не всё заработало. На данный момент я использую CentOS 7.3 и очень доволен этой системой. Однако при настройке SDAccel есть ряд тонкостей. Главная проблема – по умолчанию сетевой интерфейс имеет имя “enp6s0”. Такое имя не понимает сервер лицензий Xilinx. Ему требуется обычный “eth0”.
Настройка здесь: https://github.com/dsmv/sdaccel/wiki/note_04---Install-CentOS-7-and-SDAccel-2017.1

Qt 5.9.1 устанавливается но не работает. Для него требуется более новый компилятор gcc и git. Это тоже решается, подробности здесь: https://github.com/dsmv/sdaccel/wiki/note_05---Install-Qt-5.9.1-and-Git-2.9.3

Системы разработки

Для разработки я использую две системы:

• SDAccel 2017.1 – для разработки kernal и небольших тестовых программ HOST
• Qt 5.9.1 – для разработки более сложных программ. Qt используется только для разработки программ HOST.

Организация проекта на GitHub

Репозитарий dsmv/sdaccel предназначен для разработки примеров для SDAccel. В данный момент там есть только одна программа check_transfer. Для проекта используются ряд возможностей GitHub:

• README.md – первый файл, который виден посетителю.
• WiKi – описание программы
• Development Notes – заметки по ходу разработки
• Issues – список задач
• Projects – управление проектом
• А также есть документация на программу сформированная Doxygen

Основные каталоги программы

• useful – полезные скрипты для настройки системы
• qt – каталог для исходников Qt
• sdx_wsp/check_transfer — рабочий каталог SDAccel

В данном проекте исходные тексты для Qt и SDAссel одни и те же, хотя и находятся в разных каталогах. Однако предполагается, что на Qt будут разрабатываться намного более сложные программы.

Два режима вывода

(Нажмите на картинку для увеличения)

На рисунке показан внешний вид терминала во время работы программы. Обратите внимание на таблицу. Это таблица с выводом текущего состояния теста. Во время работы очень интересно узнать, а что собственно происходит. Тем более что предусмотрен режим без ограничения по времени. Таблица очень помогает. К сожалению, есть проблемы. SDAccel сделан на основе Eclipse. Мне не удалось научиться запускать программу из среды во внешнем терминале. А во встроенном терминале таблица не работает. Пришлось сделать режим запуска без таблицы. Кстати система Nsight Eclipse Edition для программирования устройств NVIDIA тоже не умеет запускать программы во внешнем терминале. Или может я что-то не знаю?

Мегабайты или Мебибайты ?

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

Давайте рассмотрим некоторые фрагменты кода программы.

Kernel gen_cnt

Код ядра gen_cnt() очень простой. Функция заполняет массив заданного размера тестовым блоком данных.

__kernel
__attribute__ ((reqd_work_group_size(1,1,1)))
void gen_cnt(
                __global ulong8    *pOut,
                __global ulong8    *pStatus,
                const   uint  size
              )
{
    uint    blockWr;
    ulong8  temp1;
    ulong8  checkStatus;
    ulong8  addConst;
    checkStatus = pStatus[0];
    temp1       = pStatus[1];
    addConst    = pStatus[2];
    blockWr     = checkStatus.s0 >> 32;
  __attribute__((xcl_pipeline_loop))
  for ( int ii=0; iicode>

Переменная temp1 имеет тип ulong8. Это стандартный тип OpenCL который представляет собой вектор из восьми 64-х разрядных чисел. Обращаться к элементам вектора можно по именам s0..s7 или так temp1.s[ii]. Это достаточно удобно. Ширина вектора 512 бит. Это соответствует ширине внутренней шины для контроллера SODIMM. Одним из элементов оптимизации как раз и заключается в обмене с памятью только 512 битными данными. По указателю pStatus находится блок со статусной информацией, из него считывается текущее значение и константы. Для каждого 64-х битного поля используется своя константа. Это позволяет сделать не только простой счётчик но и что то более сложное. Хотя пока что программа делает только простой счётчик. В конце функции производится запись текущего значения данных и число заполненных блоков.

check_cnt_m2a и check_read_input

Для реализации проверки я написал две функции, одна check_read_input — читает данные из динамической памяти и записывает их в pipe. Вторая – check_cnt_m2a – читает данные из pipe и проверяет их. Наверное в данном случае разделение на два kernel и их связь через pipe является избыточным. Но мне было интересно проверить эту технологию.

Код здесь

Структура программы HOST

Программа основана применении виртуальных классов TF_Test и TF_TestThread; На основе этих классов разработаны два класса тестирования

• TF_CheckTransferOut — проверка передачи от устройства в компьютер
• TF_CheckTransferIn – проверка передачи из компьютера в устройство

Базовый класс TF_Test содержит функции:

Название	Назначение
Prepare()	Подготовка
Start()	Запуск
Stop()	Останов
StepTable()	Шаг отображения таблицы
isComplete()	Работа теста завершена
GetResult()	Вывод результата

Функция main() создаёт по одному экземпляру каждого класса и начинает выполнение.
Каждый класс тестирования создаёт свой поток выполнения, в котором происходит обмен с модулем. Функция main вызывает Prepare() для каждого класса. Внутри этой функции как раз и создаётся поток, выделяется память и проводится вся подготовка. После того как оба класса готовы вызывается старт, что приводит к запуску главного цикла тестирования. При нажатии Ctrl-C или при окончании заданного времени тестирования вызывается Stop(). Классы останавливают работу и с помощью функции isComplete() информируют об этом main(). После остановки вызывается GetResult() для получения результата. В процессе выполнения теста функция main() вызывает StepTable каждые 100 мс для обновления таблицы. Это позволяет обновлять статусную информацию без вмешательства в обмен данными.
Такой подход оказался очень удобным для построения тестовых программ. Здесь все тесты строятся по одинаковому шаблону. В результате их можно запускать параллельно, а можно и поодиночке. В данной программе легко организуется режим как одиночного запуска одного из тестов, так и одновременный запуск.

Режимы выполнения OpenCL программы

Система SDAccel предоставляет три режима выполнения программы:

• Emulation-CPU — всё выполняется на HOST процессоре
• Emulation-HW — функции OpenCL выполняются на симуляторе Vivado
• System — работа на реальной аппаратуре.

Более подробно — в предыдущей статье.

Интересно сравнить скорости работы в трёх средах. Сравнение очень показательное:

Emulation-CPU	Emulation-HW	System
200 МБ/с	0.1 МБ/с	2000 МБ/с

Числа я округлил что бы лучше видеть порядок. Собственно разница в скорости между Emulation-CPU и Emulation-HW показывает что в разработке прошивок ПЛИС надо переходить на C/C++ или что-то аналогичное. Выигрыш на четыре порядка это очень много, это перекрывает все недостатки С++. При этом надо отметить, что разработка на VHDL/Verilog не исчезнет, и эти языки скорее всего придётся применять для достижения предельных характеристик. Очень перспективным выглядит возможность создания OpenCL kernel на VHDL/Verilog, это позволит сочетать высокую скорость разработки и предельные характеристики ПЛИС. Но это уже тема отдельного исследования и отдельной статьи.

Результат трассировки

Вот что получилось. Обратите внимание на количество DSP для gen_cnt. Для реализации восьми 64-х разрядных счётчиков потребовалось 128 DSP блоков. Это по 16 блоков на счётчик. Скорее всего это результат работы оптимизатора по раскрытию цикла.

Различия в методах оптимизации для FPGA и GPU

Для достижения предельных результатов должны применяться разные методы оптимизации. GPU имеет фиксированную структуру. Если условно говоря один процессорный элемент GPU может выполнять одну операцию, то что бы параллельно выполнить 100 операций надо задействовать 100 процессорных элементов. А вот в ПЛИС это не является единственным вариантом. Да, мы можем написать один kernel и разместить несколько экземпляров в ПЛИС. Но это приводит к большим накладным расходам. Xilinx рекомендует использовать не более 16 kernel, а точнее портов памяти. Зато внутри одного элемента нет ограничений на распараллеливание. Собственно пример gen_cnt это и показывает. Там сразу в коде записаны восемь 64-х разрядных сумматоров. Кроме того сработал оптимизатор и развернул цикл. Для GPU этот пример надо написать по другому, например сделать один kernel для получения 64-х разрядного отсчёта и запустить сразу восемь экземпляров.

Что может показать Emulation-HW

Этот режим может показать что происходит на шинах доступа к памяти. На картинке показан процесс чтения данных из памяти функцией check_read_input().

(Нажмите что бы увеличить)

Во первых здесь видно с какой большой задержкой приходят данные. Задержка от первого запроса до появления первых данных 512 нс. Во вторых видно что чтение идёт блоками по 16 слов (размером 512 бит). При разработке на VHDL я бы использовал больший размер блока. Но видимо контроллер умеет объединять блоки и это не приводит к замедлению. В третьих видно что есть разрывы в получении данных. Они тоже объяснимы. Частота работы OpenCL 250 МГц, частота шины памяти для SODIMM DDR3-1600 составляет 200 МГц. Разрывы точно соответствуют переходу от шины 200 МГц к шине 250 МГц.

Результаты

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

Одиночные тесты

Компьютер	Ввод [MiB/s]	Вывод [MiB/s]
Intel Core-i5, PCIe v2.0 x8	2048	1837
Intel Core-i7, PCIe v3.0 x8	2889	2953

Двунаправленный тест

Компьютер	Ввод [MiB/s]	Вывод [MiB/s]
Intel Core-i5, PCIe v2.0 x8	1609	1307
Intel Core-i7, PCIe v3.0 x8	2048	2057

Для сравнения, на нашем модуле с аналогичной ПЛИС рекордная скорость ввода составила 5500 MiB/s, хотя по ряду причин пришлось её снизить до 5000. Так что возможности для увеличения скорости обмена есть.

Что дальше

Работа будет продолжаться.

• Исследование возможностей SDAccel 2017.2
• Реализация узла свёртки на основе библиотеки FPFFTK от Александра Капитанова ( capitanov )
• Разработка собственных DSA пакетов, в том числе с поддержкой 10G Ethernet
• И главное — разработка собственного модуля, название уже есть — DSP135P

P.S. Хочу выразить благодарность Владимиру Каракозову за помощь в разработке шаблона программы тестирования.

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

В предыдущей статье «SDAccel – первое знакомство» я попытался описать основы применения OpenCL на ПЛИС Xilinx. Теперь настало время поделиться результатами экспериментов по передаче данных на модуле ADP-PCIe-KU3. Проверяется передача данных в обоих направлениях. Исходный код программ размещён на GitHub: https://github.com/dsmv/sdaccel

Аппаратура

Все эксперименты выполнены на модуле ADM-PCIe_KU3 компании Alpha-Data

Центральным элементом является ПЛИС Xilinx Kintex UltraScale KU060
К ПЛИС подключены два модуля SODIMM DDR3-1600; Ширина памяти 72 бита, это даёт возможность использовать контроллер памяти с коррекцией ошибок.

Существует возможность подключения двух QSFP модулей. Каждый QSFP модуль это четыре двунаправленные линии со скоростью передачи до 10 Гбит/с. Это даёт возможность использовать 1G, 10G, 40G Ethernet, в том числе реализовать Low-Latency Network Card. Также есть интересное свойство – ввод секундной метки от GPS приёмника. Но в данной работе всё это не используется.

Сервер NIMBIX

Сервер NIMBIX предоставляет разные вычислительные услуги, в том числе среду разработки SDAccel и что более важно – выполнение программы на выбранном аппаратном модуле.

Модель вычислителя

Хочу напомнить, что из себя представляет система OpenCL.

Система состоит из HOST компьютера и вычислителя, которые связаны между собой по шине. В данном случае это PCI Express v3.0 x8;

Прикладное программное обеспечение состоит из двух частей:

• Программа HOST компьютера.
• Одна или несколько функций для работы на вычислителе.

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

Для работы прикладного ПО требуется инфраструктура, которую должен кто-то предоставить. В данном случае — компания Xilinx. В состав инфраструктуры входят:

• библиотека opencl — реализация функций стандарта OpenCL.
• драйвер модуля — обеспечивает взаимодействие с модулем.
• пакет DSA. Это основа для разработки собственной прошивки ПЛИС.

Пакет DSA содержит базовую прошивку, в состав которой входят контроллеры для PCI Express, динамической памяти и возможно для других узлов. В составе базовой прошивки есть элемент, который называется OpenCL Region. Вот внутри именно этого элемента и будут реализованы все функции OpenCL kernels. Загрузка прошивки внутрь OpenCL Regions производится через PCI Express с использованием технологии частичной перезагрузки (Partial Reconfiguration). Надо отметить, что Xilinx сильно продвинулся в скорости загрузки. Если в предыдущих версиях загрузка занимала несколько минут, что сейчас около 5 секунд. А в версии 2017.2 объявлено что можно вообще не проводить повторную загрузку прошивки.

На данный момент для модуля ADM-PCIe-KU3 в составе пакета SDAccel доступно два пакета:

• xilinx:adm-pcie-ku3:2ddr:3.3
• xilinx:adm-pcie-ku3:2ddr-xpr:4.0

Оба пакета имеют поддержку двух контроллеров памяти и PCI Express v3.0 x8; Обратите внимание на суффикс -xpr. Это достаточно важное различие. Вариант без xpr фиксирует положение DDR контроллеров и PCI Express. Вариант с xpr фиксирует только положение PCI Express, а контроллеры DDR участвуют в трассировке прикладных функций OpenCL. Это различие приводит и к различиям в результатах. Вариант без xpr разводится быстрее, а вариант с xpr может получить более оптимальную трассировку. Для данного проекта получилось 1 час 11 минут для варианта без xpr и 1 час 32 минуты для варианта xpr. Логи здесь.

Кстати, в состав каждого DSA пакета входит свой драйвер.

Программа CHECK_TRANSFER

Программа предназначена для проверки непрерывной передачи данных в трёх режимах:

• Из ПЛИС в SODIM и в компьютер
• Из компьютера в SODIMM и в ПЛИС
• Одновременная передача в двух направлениях

На мой взгляд проверка скорости работы без проверки данных особого смысла не имеет. Поэтому я с помощью OpenCL реализовал на ПЛИС узел генератора тестовой последовательности и узел проверки тестовой последовательности.

Стандарт OpenCL предусматривает обмен между устройством и компьютером только через глобальную память устройства. Обычно это динамическая память на SODIMM. И здесь возникает очень интересный вопрос о возможности передачи данных с предельными скоростями. На модуле ADM-PCIe-KU3 применены два SODIM DDR3-1600. Скорость обмена для одного SODIMM около 10 Гбайт/с. Скорость обмена по шине PCI Express v3.0 x8 – около 5 Гбайт/с (пока получилось намного меньше). Т.е. существует возможность записывать в память один блок поступающий от PCI Express и одновременно считывать второй блок для обработки внутри ПЛИС. А что делать если надо ещё возвращать результат? PCI Express обеспечивает двунаправленный поток на высокой скорости. Но у памяти шина одна, и скорость будет делиться между чтением и записью. Вот здесь и нужен второй SODIMM. У нас существует возможность указать в каком именно модуле будет размещён буфер для обработки.

Операционная система

SDAccel может работать только под некоторыми системами Linux. В списке доступных систем CentOS 6.8, CentOS 7.3, Ubuntu 16.04, RedHat 6.8, RedHat 7.3; Первые эксперименты я начинал на CentOs 6.7; Далее попробовал использовать Ubuntu 16.04, но там не всё заработало. На данный момент я использую CentOS 7.3 и очень доволен этой системой. Однако при настройке SDAccel есть ряд тонкостей. Главная проблема – по умолчанию сетевой интерфейс имеет имя “enp6s0”. Такое имя не понимает сервер лицензий Xilinx. Ему требуется обычный “eth0”.
Настройка здесь: https://github.com/dsmv/sdaccel/wiki/note_04---Install-CentOS-7-and-SDAccel-2017.1

Qt 5.9.1 устанавливается но не работает. Для него требуется более новый компилятор gcc и git. Это тоже решается, подробности здесь: https://github.com/dsmv/sdaccel/wiki/note_05---Install-Qt-5.9.1-and-Git-2.9.3

Системы разработки

Для разработки я использую две системы:

• SDAccel 2017.1 – для разработки kernal и небольших тестовых программ HOST
• Qt 5.9.1 – для разработки более сложных программ. Qt используется только для разработки программ HOST.

Организация проекта на GitHub

Репозитарий dsmv/sdaccel предназначен для разработки примеров для SDAccel. В данный момент там есть только одна программа check_transfer. Для проекта используются ряд возможностей GitHub:

• README.md – первый файл, который виден посетителю.
• WiKi – описание программы
• Development Notes – заметки по ходу разработки
• Issues – список задач
• Projects – управление проектом
• А также есть документация на программу сформированная Doxygen

Основные каталоги программы

• useful – полезные скрипты для настройки системы
• qt – каталог для исходников Qt
• sdx_wsp/check_transfer — рабочий каталог SDAccel

В данном проекте исходные тексты для Qt и SDAссel одни и те же, хотя и находятся в разных каталогах. Однако предполагается, что на Qt будут разрабатываться намного более сложные программы.

Два режима вывода

(Нажмите на картинку для увеличения)

На рисунке показан внешний вид терминала во время работы программы. Обратите внимание на таблицу. Это таблица с выводом текущего состояния теста. Во время работы очень интересно узнать, а что собственно происходит. Тем более что предусмотрен режим без ограничения по времени. Таблица очень помогает. К сожалению, есть проблемы. SDAccel сделан на основе Eclipse. Мне не удалось научиться запускать программу из среды во внешнем терминале. А во встроенном терминале таблица не работает. Пришлось сделать режим запуска без таблицы. Кстати система Nsight Eclipse Edition для программирования устройств NVIDIA тоже не умеет запускать программы во внешнем терминале. Или может я что-то не знаю?

Мегабайты или Мебибайты ?

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

Давайте рассмотрим некоторые фрагменты кода программы.

Kernel gen_cnt

Код ядра gen_cnt() очень простой. Функция заполняет массив заданного размера тестовым блоком данных.

__kernel
__attribute__ ((reqd_work_group_size(1,1,1)))
void gen_cnt(
                __global ulong8    *pOut,
                __global ulong8    *pStatus,
                const   uint  size
              )
{
    uint    blockWr;
    ulong8  temp1;
    ulong8  checkStatus;
    ulong8  addConst;
    checkStatus = pStatus[0];
    temp1       = pStatus[1];
    addConst    = pStatus[2];
    blockWr     = checkStatus.s0 >> 32;
  __attribute__((xcl_pipeline_loop))
  for ( int ii=0; iicode>

Переменная temp1 имеет тип ulong8. Это стандартный тип OpenCL который представляет собой вектор из восьми 64-х разрядных чисел. Обращаться к элементам вектора можно по именам s0..s7 или так temp1.s[ii]. Это достаточно удобно. Ширина вектора 512 бит. Это соответствует ширине внутренней шины для контроллера SODIMM. Одним из элементов оптимизации как раз и заключается в обмене с памятью только 512 битными данными. По указателю pStatus находится блок со статусной информацией, из него считывается текущее значение и константы. Для каждого 64-х битного поля используется своя константа. Это позволяет сделать не только простой счётчик но и что то более сложное. Хотя пока что программа делает только простой счётчик. В конце функции производится запись текущего значения данных и число заполненных блоков.

check_cnt_m2a и check_read_input

Для реализации проверки я написал две функции, одна check_read_input — читает данные из динамической памяти и записывает их в pipe. Вторая – check_cnt_m2a – читает данные из pipe и проверяет их. Наверное в данном случае разделение на два kernel и их связь через pipe является избыточным. Но мне было интересно проверить эту технологию.

Код здесь

Структура программы HOST

Программа основана применении виртуальных классов TF_Test и TF_TestThread; На основе этих классов разработаны два класса тестирования

• TF_CheckTransferOut — проверка передачи от устройства в компьютер
• TF_CheckTransferIn – проверка передачи из компьютера в устройство

Базовый класс TF_Test содержит функции:

Название	Назначение
Prepare()	Подготовка
Start()	Запуск
Stop()	Останов
StepTable()	Шаг отображения таблицы
isComplete()	Работа теста завершена
GetResult()	Вывод результата

Функция main() создаёт по одному экземпляру каждого класса и начинает выполнение.
Каждый класс тестирования создаёт свой поток выполнения, в котором происходит обмен с модулем. Функция main вызывает Prepare() для каждого класса. Внутри этой функции как раз и создаётся поток, выделяется память и проводится вся подготовка. После того как оба класса готовы вызывается старт, что приводит к запуску главного цикла тестирования. При нажатии Ctrl-C или при окончании заданного времени тестирования вызывается Stop(). Классы останавливают работу и с помощью функции isComplete() информируют об этом main(). После остановки вызывается GetResult() для получения результата. В процессе выполнения теста функция main() вызывает StepTable каждые 100 мс для обновления таблицы. Это позволяет обновлять статусную информацию без вмешательства в обмен данными.
Такой подход оказался очень удобным для построения тестовых программ. Здесь все тесты строятся по одинаковому шаблону. В результате их можно запускать параллельно, а можно и поодиночке. В данной программе легко организуется режим как одиночного запуска одного из тестов, так и одновременный запуск.

Режимы выполнения OpenCL программы

Система SDAccel предоставляет три режима выполнения программы:

• Emulation-CPU — всё выполняется на HOST процессоре
• Emulation-HW — функции OpenCL выполняются на симуляторе Vivado
• System — работа на реальной аппаратуре.

Более подробно — в предыдущей статье.

Интересно сравнить скорости работы в трёх средах. Сравнение очень показательное:

Emulation-CPU	Emulation-HW	System
200 МБ/с	0.1 МБ/с	2000 МБ/с

Числа я округлил что бы лучше видеть порядок. Собственно разница в скорости между Emulation-CPU и Emulation-HW показывает что в разработке прошивок ПЛИС надо переходить на C/C++ или что-то аналогичное. Выигрыш на четыре порядка это очень много, это перекрывает все недостатки С++. При этом надо отметить, что разработка на VHDL/Verilog не исчезнет, и эти языки скорее всего придётся применять для достижения предельных характеристик. Очень перспективным выглядит возможность создания OpenCL kernel на VHDL/Verilog, это позволит сочетать высокую скорость разработки и предельные характеристики ПЛИС. Но это уже тема отдельного исследования и отдельной статьи.

Результат трассировки

Вот что получилось. Обратите внимание на количество DSP для gen_cnt. Для реализации восьми 64-х разрядных счётчиков потребовалось 128 DSP блоков. Это по 16 блоков на счётчик. Скорее всего это результат работы оптимизатора по раскрытию цикла.

Различия в методах оптимизации для FPGA и GPU

Для достижения предельных результатов должны применяться разные методы оптимизации. GPU имеет фиксированную структуру. Если условно говоря один процессорный элемент GPU может выполнять одну операцию, то что бы параллельно выполнить 100 операций надо задействовать 100 процессорных элементов. А вот в ПЛИС это не является единственным вариантом. Да, мы можем написать один kernel и разместить несколько экземпляров в ПЛИС. Но это приводит к большим накладным расходам. Xilinx рекомендует использовать не более 16 kernel, а точнее портов памяти. Зато внутри одного элемента нет ограничений на распараллеливание. Собственно пример gen_cnt это и показывает. Там сразу в коде записаны восемь 64-х разрядных сумматоров. Кроме того сработал оптимизатор и развернул цикл. Для GPU этот пример надо написать по другому, например сделать один kernel для получения 64-х разрядного отсчёта и запустить сразу восемь экземпляров.

Что может показать Emulation-HW

Этот режим может показать что происходит на шинах доступа к памяти. На картинке показан процесс чтения данных из памяти функцией check_read_input().

(Нажмите что бы увеличить)

Во первых здесь видно с какой большой задержкой приходят данные. Задержка от первого запроса до появления первых данных 512 нс. Во вторых видно что чтение идёт блоками по 16 слов (размером 512 бит). При разработке на VHDL я бы использовал больший размер блока. Но видимо контроллер умеет объединять блоки и это не приводит к замедлению. В третьих видно что есть разрывы в получении данных. Они тоже объяснимы. Частота работы OpenCL 250 МГц, частота шины памяти для SODIMM DDR3-1600 составляет 200 МГц. Разрывы точно соответствуют переходу от шины 200 МГц к шине 250 МГц.

Результаты

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

Одиночные тесты

Компьютер	Ввод [MiB/s]	Вывод [MiB/s]
Intel Core-i5, PCIe v2.0 x8	2048	1837
Intel Core-i7, PCIe v3.0 x8	2889	2953

Двунаправленный тест

Компьютер	Ввод [MiB/s]	Вывод [MiB/s]
Intel Core-i5, PCIe v2.0 x8	1609	1307
Intel Core-i7, PCIe v3.0 x8	2048	2057

Для сравнения, на нашем модуле с аналогичной ПЛИС рекордная скорость ввода составила 5500 MiB/s, хотя по ряду причин пришлось её снизить до 5000. Так что возможности для увеличения скорости обмена есть.

Что дальше

Работа будет продолжаться.

• Исследование возможностей SDAccel 2017.2
• Реализация узла свёртки на основе библиотеки FPFFTK от Александра Капитанова ( capitanov )
• Разработка собственных DSA пакетов, в том числе с поддержкой 10G Ethernet
• И главное — разработка собственного модуля, название уже есть — DSP135P

P.S. Хочу выразить благодарность Владимиру Каракозову за помощь в разработке шаблона программы тестирования.

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

В предыдущей статье «SDAccel – первое знакомство» я попытался описать основы применения OpenCL на ПЛИС Xilinx. Теперь настало время поделиться результатами экспериментов по передаче данных на модуле ADP-PCIe-KU3. Проверяется передача данных в обоих направлениях. Исходный код программ размещён на GitHub: https://github.com/dsmv/sdaccel

Аппаратура

Все эксперименты выполнены на модуле ADM-PCIe_KU3 компании Alpha-Data

Центральным элементом является ПЛИС Xilinx Kintex UltraScale KU060
К ПЛИС подключены два модуля SODIMM DDR3-1600; Ширина памяти 72 бита, это даёт возможность использовать контроллер памяти с коррекцией ошибок.

Существует возможность подключения двух QSFP модулей. Каждый QSFP модуль это четыре двунаправленные линии со скоростью передачи до 10 Гбит/с. Это даёт возможность использовать 1G, 10G, 40G Ethernet, в том числе реализовать Low-Latency Network Card. Также есть интересное свойство – ввод секундной метки от GPS приёмника. Но в данной работе всё это не используется.

Сервер NIMBIX

Сервер NIMBIX предоставляет разные вычислительные услуги, в том числе среду разработки SDAccel и что более важно – выполнение программы на выбранном аппаратном модуле.

Модель вычислителя

Хочу напомнить, что из себя представляет система OpenCL.

Система состоит из HOST компьютера и вычислителя, которые связаны между собой по шине. В данном случае это PCI Express v3.0 x8;

Прикладное программное обеспечение состоит из двух частей:

• Программа HOST компьютера.
• Одна или несколько функций для работы на вычислителе.

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

Для работы прикладного ПО требуется инфраструктура, которую должен кто-то предоставить. В данном случае — компания Xilinx. В состав инфраструктуры входят:

• библиотека opencl — реализация функций стандарта OpenCL.
• драйвер модуля — обеспечивает взаимодействие с модулем.
• пакет DSA. Это основа для разработки собственной прошивки ПЛИС.

Пакет DSA содержит базовую прошивку, в состав которой входят контроллеры для PCI Express, динамической памяти и возможно для других узлов. В составе базовой прошивки есть элемент, который называется OpenCL Region. Вот внутри именно этого элемента и будут реализованы все функции OpenCL kernels. Загрузка прошивки внутрь OpenCL Regions производится через PCI Express с использованием технологии частичной перезагрузки (Partial Reconfiguration). Надо отметить, что Xilinx сильно продвинулся в скорости загрузки. Если в предыдущих версиях загрузка занимала несколько минут, что сейчас около 5 секунд. А в версии 2017.2 объявлено что можно вообще не проводить повторную загрузку прошивки.

На данный момент для модуля ADM-PCIe-KU3 в составе пакета SDAccel доступно два пакета:

• xilinx:adm-pcie-ku3:2ddr:3.3
• xilinx:adm-pcie-ku3:2ddr-xpr:4.0

Оба пакета имеют поддержку двух контроллеров памяти и PCI Express v3.0 x8; Обратите внимание на суффикс -xpr. Это достаточно важное различие. Вариант без xpr фиксирует положение DDR контроллеров и PCI Express. Вариант с xpr фиксирует только положение PCI Express, а контроллеры DDR участвуют в трассировке прикладных функций OpenCL. Это различие приводит и к различиям в результатах. Вариант без xpr разводится быстрее, а вариант с xpr может получить более оптимальную трассировку. Для данного проекта получилось 1 час 11 минут для варианта без xpr и 1 час 32 минуты для варианта xpr. Логи здесь.

Кстати, в состав каждого DSA пакета входит свой драйвер.

Программа CHECK_TRANSFER

Программа предназначена для проверки непрерывной передачи данных в трёх режимах:

• Из ПЛИС в SODIM и в компьютер
• Из компьютера в SODIMM и в ПЛИС
• Одновременная передача в двух направлениях

На мой взгляд проверка скорости работы без проверки данных особого смысла не имеет. Поэтому я с помощью OpenCL реализовал на ПЛИС узел генератора тестовой последовательности и узел проверки тестовой последовательности.

Стандарт OpenCL предусматривает обмен между устройством и компьютером только через глобальную память устройства. Обычно это динамическая память на SODIMM. И здесь возникает очень интересный вопрос о возможности передачи данных с предельными скоростями. На модуле ADM-PCIe-KU3 применены два SODIM DDR3-1600. Скорость обмена для одного SODIMM около 10 Гбайт/с. Скорость обмена по шине PCI Express v3.0 x8 – около 5 Гбайт/с (пока получилось намного меньше). Т.е. существует возможность записывать в память один блок поступающий от PCI Express и одновременно считывать второй блок для обработки внутри ПЛИС. А что делать если надо ещё возвращать результат? PCI Express обеспечивает двунаправленный поток на высокой скорости. Но у памяти шина одна, и скорость будет делиться между чтением и записью. Вот здесь и нужен второй SODIMM. У нас существует возможность указать в каком именно модуле будет размещён буфер для обработки.

Операционная система

SDAccel может работать только под некоторыми системами Linux. В списке доступных систем CentOS 6.8, CentOS 7.3, Ubuntu 16.04, RedHat 6.8, RedHat 7.3; Первые эксперименты я начинал на CentOs 6.7; Далее попробовал использовать Ubuntu 16.04, но там не всё заработало. На данный момент я использую CentOS 7.3 и очень доволен этой системой. Однако при настройке SDAccel есть ряд тонкостей. Главная проблема – по умолчанию сетевой интерфейс имеет имя “enp6s0”. Такое имя не понимает сервер лицензий Xilinx. Ему требуется обычный “eth0”.
Настройка здесь: https://github.com/dsmv/sdaccel/wiki/note_04---Install-CentOS-7-and-SDAccel-2017.1

Qt 5.9.1 устанавливается но не работает. Для него требуется более новый компилятор gcc и git. Это тоже решается, подробности здесь: https://github.com/dsmv/sdaccel/wiki/note_05---Install-Qt-5.9.1-and-Git-2.9.3

Системы разработки

Для разработки я использую две системы:

• SDAccel 2017.1 – для разработки kernal и небольших тестовых программ HOST
• Qt 5.9.1 – для разработки более сложных программ. Qt используется только для разработки программ HOST.

Организация проекта на GitHub

Репозитарий dsmv/sdaccel предназначен для разработки примеров для SDAccel. В данный момент там есть только одна программа check_transfer. Для проекта используются ряд возможностей GitHub:

• README.md – первый файл, который виден посетителю.
• WiKi – описание программы
• Development Notes – заметки по ходу разработки
• Issues – список задач
• Projects – управление проектом
• А также есть документация на программу сформированная Doxygen

Основные каталоги программы

• useful – полезные скрипты для настройки системы
• qt – каталог для исходников Qt
• sdx_wsp/check_transfer — рабочий каталог SDAccel

В данном проекте исходные тексты для Qt и SDAссel одни и те же, хотя и находятся в разных каталогах. Однако предполагается, что на Qt будут разрабатываться намного более сложные программы.

Два режима вывода

(Нажмите на картинку для увеличения)

На рисунке показан внешний вид терминала во время работы программы. Обратите внимание на таблицу. Это таблица с выводом текущего состояния теста. Во время работы очень интересно узнать, а что собственно происходит. Тем более что предусмотрен режим без ограничения по времени. Таблица очень помогает. К сожалению, есть проблемы. SDAccel сделан на основе Eclipse. Мне не удалось научиться запускать программу из среды во внешнем терминале. А во встроенном терминале таблица не работает. Пришлось сделать режим запуска без таблицы. Кстати система Nsight Eclipse Edition для программирования устройств NVIDIA тоже не умеет запускать программы во внешнем терминале. Или может я что-то не знаю?

Мегабайты или Мебибайты ?

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

Давайте рассмотрим некоторые фрагменты кода программы.

Kernel gen_cnt

Код ядра gen_cnt() очень простой. Функция заполняет массив заданного размера тестовым блоком данных.

__kernel
__attribute__ ((reqd_work_group_size(1,1,1)))
void gen_cnt(
                __global ulong8    *pOut,
                __global ulong8    *pStatus,
                const   uint  size
              )
{
    uint    blockWr;
    ulong8  temp1;
    ulong8  checkStatus;
    ulong8  addConst;
    checkStatus = pStatus[0];
    temp1       = pStatus[1];
    addConst    = pStatus[2];
    blockWr     = checkStatus.s0 >> 32;
  __attribute__((xcl_pipeline_loop))
  for ( int ii=0; iicode>

Переменная temp1 имеет тип ulong8. Это стандартный тип OpenCL который представляет собой вектор из восьми 64-х разрядных чисел. Обращаться к элементам вектора можно по именам s0..s7 или так temp1.s[ii]. Это достаточно удобно. Ширина вектора 512 бит. Это соответствует ширине внутренней шины для контроллера SODIMM. Одним из элементов оптимизации как раз и заключается в обмене с памятью только 512 битными данными. По указателю pStatus находится блок со статусной информацией, из него считывается текущее значение и константы. Для каждого 64-х битного поля используется своя константа. Это позволяет сделать не только простой счётчик но и что то более сложное. Хотя пока что программа делает только простой счётчик. В конце функции производится запись текущего значения данных и число заполненных блоков.

check_cnt_m2a и check_read_input

Для реализации проверки я написал две функции, одна check_read_input — читает данные из динамической памяти и записывает их в pipe. Вторая – check_cnt_m2a – читает данные из pipe и проверяет их. Наверное в данном случае разделение на два kernel и их связь через pipe является избыточным. Но мне было интересно проверить эту технологию.

Код здесь

Структура программы HOST

Программа основана применении виртуальных классов TF_Test и TF_TestThread; На основе этих классов разработаны два класса тестирования

• TF_CheckTransferOut — проверка передачи от устройства в компьютер
• TF_CheckTransferIn – проверка передачи из компьютера в устройство

Базовый класс TF_Test содержит функции:

Название	Назначение
Prepare()	Подготовка
Start()	Запуск
Stop()	Останов
StepTable()	Шаг отображения таблицы
isComplete()	Работа теста завершена
GetResult()	Вывод результата

Функция main() создаёт по одному экземпляру каждого класса и начинает выполнение.
Каждый класс тестирования создаёт свой поток выполнения, в котором происходит обмен с модулем. Функция main вызывает Prepare() для каждого класса. Внутри этой функции как раз и создаётся поток, выделяется память и проводится вся подготовка. После того как оба класса готовы вызывается старт, что приводит к запуску главного цикла тестирования. При нажатии Ctrl-C или при окончании заданного времени тестирования вызывается Stop(). Классы останавливают работу и с помощью функции isComplete() информируют об этом main(). После остановки вызывается GetResult() для получения результата. В процессе выполнения теста функция main() вызывает StepTable каждые 100 мс для обновления таблицы. Это позволяет обновлять статусную информацию без вмешательства в обмен данными.
Такой подход оказался очень удобным для построения тестовых программ. Здесь все тесты строятся по одинаковому шаблону. В результате их можно запускать параллельно, а можно и поодиночке. В данной программе легко организуется режим как одиночного запуска одного из тестов, так и одновременный запуск.

Режимы выполнения OpenCL программы

Система SDAccel предоставляет три режима выполнения программы:

• Emulation-CPU — всё выполняется на HOST процессоре
• Emulation-HW — функции OpenCL выполняются на симуляторе Vivado
• System — работа на реальной аппаратуре.

Более подробно — в предыдущей статье.

Интересно сравнить скорости работы в трёх средах. Сравнение очень показательное:

Emulation-CPU	Emulation-HW	System
200 МБ/с	0.1 МБ/с	2000 МБ/с

Числа я округлил что бы лучше видеть порядок. Собственно разница в скорости между Emulation-CPU и Emulation-HW показывает что в разработке прошивок ПЛИС надо переходить на C/C++ или что-то аналогичное. Выигрыш на четыре порядка это очень много, это перекрывает все недостатки С++. При этом надо отметить, что разработка на VHDL/Verilog не исчезнет, и эти языки скорее всего придётся применять для достижения предельных характеристик. Очень перспективным выглядит возможность создания OpenCL kernel на VHDL/Verilog, это позволит сочетать высокую скорость разработки и предельные характеристики ПЛИС. Но это уже тема отдельного исследования и отдельной статьи.

Результат трассировки

Вот что получилось. Обратите внимание на количество DSP для gen_cnt. Для реализации восьми 64-х разрядных счётчиков потребовалось 128 DSP блоков. Это по 16 блоков на счётчик. Скорее всего это результат работы оптимизатора по раскрытию цикла.

Различия в методах оптимизации для FPGA и GPU

Для достижения предельных результатов должны применяться разные методы оптимизации. GPU имеет фиксированную структуру. Если условно говоря один процессорный элемент GPU может выполнять одну операцию, то что бы параллельно выполнить 100 операций надо задействовать 100 процессорных элементов. А вот в ПЛИС это не является единственным вариантом. Да, мы можем написать один kernel и разместить несколько экземпляров в ПЛИС. Но это приводит к большим накладным расходам. Xilinx рекомендует использовать не более 16 kernel, а точнее портов памяти. Зато внутри одного элемента нет ограничений на распараллеливание. Собственно пример gen_cnt это и показывает. Там сразу в коде записаны восемь 64-х разрядных сумматоров. Кроме того сработал оптимизатор и развернул цикл. Для GPU этот пример надо написать по другому, например сделать один kernel для получения 64-х разрядного отсчёта и запустить сразу восемь экземпляров.

Что может показать Emulation-HW

Этот режим может показать что происходит на шинах доступа к памяти. На картинке показан процесс чтения данных из памяти функцией check_read_input().

(Нажмите что бы увеличить)

Во первых здесь видно с какой большой задержкой приходят данные. Задержка от первого запроса до появления первых данных 512 нс. Во вторых видно что чтение идёт блоками по 16 слов (размером 512 бит). При разработке на VHDL я бы использовал больший размер блока. Но видимо контроллер умеет объединять блоки и это не приводит к замедлению. В третьих видно что есть разрывы в получении данных. Они тоже объяснимы. Частота работы OpenCL 250 МГц, частота шины памяти для SODIMM DDR3-1600 составляет 200 МГц. Разрывы точно соответствуют переходу от шины 200 МГц к шине 250 МГц.

Результаты

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

Одиночные тесты

Компьютер	Ввод [MiB/s]	Вывод [MiB/s]
Intel Core-i5, PCIe v2.0 x8	2048	1837
Intel Core-i7, PCIe v3.0 x8	2889	2953

Двунаправленный тест

Компьютер	Ввод [MiB/s]	Вывод [MiB/s]
Intel Core-i5, PCIe v2.0 x8	1609	1307
Intel Core-i7, PCIe v3.0 x8	2048	2057

Для сравнения, на нашем модуле с аналогичной ПЛИС рекордная скорость ввода составила 5500 MiB/s, хотя по ряду причин пришлось её снизить до 5000. Так что возможности для увеличения скорости обмена есть.

Что дальше

Работа будет продолжаться.

• Исследование возможностей SDAccel 2017.2
• Реализация узла свёртки на основе библиотеки FPFFTK от Александра Капитанова ( capitanov )
• Разработка собственных DSA пакетов, в том числе с поддержкой 10G Ethernet
• И главное — разработка собственного модуля, название уже есть — DSP135P

P.S. Хочу выразить благодарность Владимиру Каракозову за помощь в разработке шаблона программы тестирования.

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