Меня зовут Лев, я главный администратор сайта объявлений о продаже и аренде недвижимости Onrealt. Хочу поделиться впечатлениями о сотрудничестве с компанией FirstDEDIC.
onrealt.ru



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

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

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

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

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

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

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

Наша инфраструктура
Изначально мы арендовали 5 серверов. Все серверы были объединены в VLAN (виртуальная локальная сеть) для конечной реализации нашей структуры.


Сервер для работы с базами данных
На данном сервере разместили основные базы данных — MySQL и Memcached для хранения сессий. Чтобы надёжно хранить большой объём данных и быстро с ним работать, мы выбрали следующую конфигурацию: два процессора E5-2620v4 2.1-3.3 ГГц (8 ядер), 256 Гб оперативной памяти, два SSD 1920 Гб в зеркальном рейде.

Сервер для репликации базы данных и бекапов
Основная задача данного сервера — хранение резервной копии базы данных и репликация части таблиц для оптимизации выборок MySQL.

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

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

Основной веб-сервер
Задача данного сервера — обработка входящих запросов к сайту и к API для приложений.

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

Сервер для хранения файлов
Наш сайт содержит множество объявлений, а объявления в свою очередь — много фотографии. В итоге нам необходимо хранить внушительный объём файлов.

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

Чего мы добились
Наш сервис был запущен в конце декабря 2017 года, а уже в 2018 году ежемесячная посещаемость выросла до 900 тысяч. В 2019 году — до 1,6 млн, в 2020 уже до 2,4 млн уникальных посетителей в месяц.


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

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

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

https://firstdedic.ru

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

Один из таких клиентов — Антон Кинстлер, руководитель IT-отдела интернет-магазина мебели «1HMM». И сегодня он расскажет о том, с какими трудностями столкнулась его команда, когда компания решила выйти в онлайн, и какие жизненные уроки из этого вынесла.
1hmm.ru


Предыстория
Наша история началась с маленького магазинчика в городе Верхний Уфалей Челябинской области. В 2011 году был открыт оптовый склад в Челябинске, в 2013-м создали интернет-магазин, а в апреле получили первый заказ через него. Это был многостраничный сайт на 1С-Битрикс: Управление сайтом редакции «Бизнес», и в тот момент на него было заведено около тысячи позиций.

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


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

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

Урок первый. Как мы просчитались с ресурсами
На старте у нас не было большого трафика на сайт, и мы решили использовать недорогой виртуальный хостинг в Екатеринбурге. Что мы не учли, так это «тяжесть» самого проекта. Дело в том, что помимо большого ассортимента у нас на каждый регион — так исторически сложилось — свой тип цены. Соответственно, у нас десятки миллионов цен (предложений). Поэтому, несмотря на небольшой трафик, мы почти сразу упёрлись в потолок виртуального хостинга. Сайт тормозил, страницы открывались медленно, мы теряли клиентов и деньги. Пришлось срочно «переобуваться» и искать другие варианты.

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

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

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

Сейчас у нас нет проблем с масштабированием — просто пишем в поддержку, что нам нужен еще один сервер, и его поднимают.

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

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

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

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

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

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

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

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

https://firstdedic.ru

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

Установка и первоначальная настройка
Жизненный цикл любой БД начинается с установки. Но перед этим необходимо подготовить инфраструктуру: оборудование, операционную систему (ОС), сеть, политики безопасности, пользователей и т. д. С одной стороны, это разовое действие, с другой, если через месяц для нового проекта понадобится БД — все придется делать заново.

Управляемая БД разворачивается по нажатию нескольких кнопок: нужно выбрать тип, задать параметры ВМ (CPU, RAM и др.) и подождать несколько минут. Шаги для развёртывания баз данных при самостоятельной установке или с управляемой БД:


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

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

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

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

Примечание
Команда Yandex.Cloud не просто администрирует БД, мы также получаем опыт из разработки. Системные администраторы и разработчики совместно улучшают БД: решают инциденты и совершенствуют сам сервис.

• Мы разработали ClickHouse — высокопроизводительную аналитическую БД, которая обрабатывает миллиарды строк в секунду. Мы создавали ее для внутренних задач, а сейчас ею пользуются более 2000 компаний по всему миру: в e-commerce, мобильной и игровой разработке, рекламе и аналитике.
• Мы участвуем в разработке других открытых проектов. Например, мы создали пулер соединений Odyssey для PostgreSQL, участвуем в развитии системы бекапирования WAL-G и других расширений для PostgreSQL.
• Мы используем управляемые БД внутри собственных продуктов: Почты, Такси, Диска, Драйва и др. Поэтому мы понимаем на деле, какие проблемы возникают у пользователей управляемых БД, и стараемся сами их решать.

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

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

Ниже перечислены задачи обслуживания БД при самостоятельном администрировании и при использовании сервиса по управлению базой данных.


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

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

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


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

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

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

Кроме привычных всем бекапов, в некоторых СУБД есть механизм point-in-time recovery (PITR). Эта полезная функция позволяет восстановить данные на любой момент, а не только на момент создания копии. Например, бекап создается ночью в 00:00. Утром БД начинает наполняться данными, а в обед junior-разработчик случайно удаляет одну из таблиц. Если восстановить предыдущую копию — то потеряются утренние данные. Механизм PITR позволяет указать точное время, на которое нужно восстановить данные: он сам восстановит последнюю копию и применит все транзакции, которые прошли после ее создания.


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

Полностью управляемый сервис, а не ВМ с шаблоном
Мы предоставляем полностью управляемые БД: вы получаете доступ к БД как пользователь, а мы следим, чтобы она работала как часы. Вы создаете схемы и таблицы, обращаетесь к данным, анализируете производительность запросов. Но у вас нет root-доступа, вы не можете менять системные настройки и управлять ВМ, на которой запущена СУБД.

Кажется, что вы получаете меньше гибкости, ведь вы не можете управлять всеми настройками. Но чаще всего клиентам нужна готовая и стабильная БД, а не конструктор, который легко сломать. Именно благодаря таким ограничениям мы гарантируем стабильную работу СУБД.

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

В Yandex.Cloud вы получаете на 100% управляемый сервис. А еще мы единственный облачный провайдер в России, у которого есть Terraform для управляемых БД. Через него можно делать все то же самое, что через консоль управления, API и CLI.

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

Примеры графиков мониторинга — потребление ресурсов, количество запросов и другие:


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

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

Доступность выше, чем у ВМ
Еще одна особенность управляемых БД — соглашение об уровне сервиса (SLA). Мы гарантируем, что БД будет доступна определенное количество времени. Если мы не выполним обещание, то компенсируем вам стоимость сервиса.


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

При аренде БД на ВМ провайдер также гарантирует доступность по SLA. Но, как правило, SLA для ВМ ниже, чем для управляемой БД. Например, наше SLA для ВМ — 99,95%. Когда ВМ простаивает, это означает, что БД недоступна на чтение и на запись. А в управляемой БД эти операции разделены, и если БД недоступна на запись, то вполне вероятно, что она доступна хотя бы на чтение благодаря репликам.

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

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


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

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

Сколько это стоит
Мы посчитали стоимость владения и управления тремя видами ресурсов: on-premise, ВМ на базе Yandex Compute Cloud и сервисом по управлению базами данных. Мы выбрали эквивалентное по мощности оборудование и сравнили, сколько это стоит в каждом из вариантов.

Расчеты приведем на горизонте трех лет, т. е. амортизацию оборудования в on-premise-решении посчитаем за три года.

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

Сравнение стоимости управления и владения различными вариантами работы с БД:


On-premise требует больше всего времени, денег и усилий, потому что вам придется:

• Заниматься оборудованием: покупать его, следить за ним, поддерживать бесперебойную работу и периодически менять, когда оно устареет или сломается. Если проект развивается, то со временем мощности станет недостаточно и потребуется новое оборудование. Если же сразу взять мощность с запасом — оборудование будет простаивать.
• Пример: сервер HP с 12 ядрами стоимостью ≈ 800 000 ₽. С учетом амортизации за три года получается ≈ 22 000 ₽ в месяц.
• Согласно исследованию некоммерческой организации NRDC, утилизация on-premise оборудования от трех до четырех раз ниже, чем облачного. С учетом данной поправки стоимость владения оборудованием составит как минимум ≈ 22 000 × 3 = ≈ 66 000 ₽ в месяц.
• Искать сотрудников, платить зарплату и социальные взносы. При этом потребуется как минимум два специалиста, чтобы они могли подменять друг друга во время отпуска и болезни. Скорее всего, кроме БД, эти сотрудники будут заниматься и другими задачами, поэтому для примера примем, что на администрирование БД они тратят только 50% времени.
• Зарплата специалиста — ≈ 100 000 ₽, социальные взносы — 30 000 ₽. Потребуется два специалиста, каждый из которых администрирует БД 50% времени. В итоге получаем ≈ 130 000 ₽ в месяц.
• Итого ≈ 196 000 ₽ в месяц.

ВМ на базе Compute Cloud стоит дешевле и требует меньше усилий

• Не нужно заниматься оборудованием: за ним следим мы.
• Стоимость развертывания ВМ в Yandex.Cloud — ≈ 27 500 ₽ в месяц.
• Нужно искать сотрудников, платить зарплату и социальные взносы. При этом потребуется как минимум два специалиста, чтобы они могли подменять друг друга во время отпуска и болезни. Скорее всего, кроме БД, эти сотрудники будут заниматься и другими задачами, поэтому для примера примем, что на администрирование БД они тратят только 50% времени.
• Зарплата специалиста — ≈ 100 000 ₽, социальные взносы — 30 000 ₽. Потребуется два специалиста, каждый из которых администрирует БД 50% времени. В итоге получаем ≈ 130 000 ₽ в месяц.
• Итого ≈ 157 500 ₽ в месяц.

Управляемая БД требует меньше всего усилий и денег, потому что вам не нужно:

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

Пример: управляемая БД (24 vCPU, 96 RAM, 240 ГБ SSD) стоит ≈ 42 000 ₽ в месяц.

Итог: экономия от управляемыми БД по сравнению с on-premise может доходить 80%, а по сравнению с ВМ на базе Compute Cloud до 70% (в основном за счет персонала).

Краткий вывод
В статье мы рассмотрели преимущества управляемых БД перед самостоятельным развертыванием в on-premise и в ВМ.
Сервис по управлению базами данных на платформе Yandex.Cloud позволяет:

• Упростить установку, настройку и сопровождение системы;
• Подключить дополнительные инструменты, например систему мониторинга или визуализации данных;
• Экономить по сравнению с решениями on-premise и на базе ВМ, в основном за счет персонала и оборудования;
• Быстрее тестировать гипотезы и разрабатывать новые продукты, подключая необходимые ресурсы по клику и снижая время на time-to-market (запуск новых продуктов на рынок).

С 2014 года Qrator Labs разрабатывает сервис BGP-мониторинга и аналитики под названием Qrator.Radar. Одна из его основных функций — мониторинг определенных аномалий BGP, которые могут привести к инциденту, который мы в дальнейшем будем называть либо утечкой маршрута BGP, либо захватом BGP.

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

Наша компания начала собирать модель отношений BGP за пару лет до появления RFC 7908, пытаясь определить, что такое утечка маршрута BGP. Два основных различия между этими временами событий были описаны как:

• Маршруты перенаправляются через неправильные ASN / ссылки (утечки маршрутов), описываются как типы 1-4 RFC 7908;
• Маршруты перенаправляются на неправильные ASN (Hijack), описанные как типы 5 и 6 RFC 7908.

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

Во время перехвата BGP трафик, предназначенный для вашей сети, перенаправляется третьей стороне и остается там.

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

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

Чтобы обнаружить причину утечки маршрута, вам необходимо выяснить взаимосвязь между каждым из двух подключенных операторов и выяснить такие маршруты BGP (от сборщика BGP), которые нарушают формальную модель Гао-Рексфорда, для получения дополнительной информации см. с «отношениями AS» CAIDA.
Чтобы обнаружить угоны, вам необходимо знать, какие префиксы принадлежат каким интернет-провайдерам, и в большинстве случаев, когда появляется незарегистрированная пара префиксов интернет-провайдера — создайте сигнал тревоги или примите меры.
www.caida.org/data/as-relationships/

Чтобы предотвратить / смягчить захват, существует два стандартных подхода в рамках единой структуры проверки происхождения префикса. Вы можете зарегистрировать объект Route в IRR или создать объект ROA. Наша команда описала различия между этими подходами во время RIPE79. Однако общее — они оба указывают, какие префиксы принадлежат каким операторам (самими операторами), и пытаются заблокировать маршруты от интернет-провайдера с незарегистрированными префиксами (транзитными интернет-провайдерами).

Чтобы предотвратить / смягчить чистые утечки маршрутов, мы принимаем участие в создании открытой политики BGP. Другой подход — одноранговая блокировка — блокировка маршрутов с неожиданными соседями / интернет-провайдерами в AS_PATH.
datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/
archive.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf
datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/

Проект ASPA IETF стоит немного в стороне от чистого предотвращения перехвата / утечки маршрутов, потому что он больше касается блокирования плохих AS_PATH (случаев утечки маршрутов и перехватов без / с плохой манипуляцией AS_PATH).

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

Подписание ROA против фильтрации ROA
Еще одно распространенное заблуждение связано с РОА. В алгоритмах ROA есть две стороны: подписывающая сторона — оператор, который предоставляет достоверную информацию о принадлежащих ему префиксах; и есть фильтрующая сторона — транзитный оператор, который отфильтровывает плохие маршруты в соответствии с информацией, предоставленной подписавшей стороной.

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

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

Мы успешно очистили достаточно дисков для метаданных. Теперь мы можем восстанавливать кольца. Фото: до vs после.

У нас есть 20% данных всего с одной копией. Сначала мы восстанавливаем избыточность данных. Затем мы даем доступ RO. Потом RW.

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




www.webinar.gcorelabs.com

В предыдущей статье подробно описывалось разделение ответственности для различных моделей использования облачных сервисов и что Yandex.Cloud делает для обеспечения безопасности. Этот материал посвящён возможностям клиентов облака.

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

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

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

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

Управление доступом пользователей
Управление учётными записями — это одна из важнейших возможностей клиентов облака для обеспечения безопасности. Для IaaS, PaaS и SaaS управление учётными записями и доступом является общей ответственностью, требующей настройки контроля доступа на основе ролей и применения различных способов аутентификации, контроля и мониторинга. В Yandex.Cloud на данный момент пользователям доступны следующие виды аккаунтов:

• Аккаунты на Яндексе. Для аутентификации необходимо использовать логин и пароль либо ПИН-код и приложение Яндекс.Ключ, если настроена двухфакторная аутентификация.
• Федеративные аккаунты. Сервис IAM принимает от стороннего поставщика удостоверений (identity provider) подписанный SAML-токен, который содержит информацию об аутентифицированном пользователе.
• Сервисные аккаунты — особый тип аккаунтов, которые используются для доступа к ресурсам Yandex.Cloud от имени приложения.

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

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

Сетевая безопасность и контроль сети
Сетевой контроль на стороне клиента включает в себя настройку и использование сетевых средств безопасности, таких как VPN, балансировщики нагрузки (load balancers), шлюзы и прочее.

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

Для защиты виртуальных машин и выделения зон разного уровня безопасности пользователям также доступен механизм групп безопасности (security groups). Для повышения доступности инфраструктуры в Yandex.Cloud есть возможность управлять входящим и исходящим интернет-трафиком, в том числе с помощью балансировщика нагрузки Yandex Network Load Balancer, а также сегментировать виртуальные сети среды Yandex.Cloud. Балансировщик нагрузки может быть интегрирован с сервисом Yandex DDoS Protection, который защитит ваш сервис от DDoS-атак. Для защиты от атак на уровне L7 рекомендуется использовать виртуальные образы или облачные сервисы с web application firewall (WAF).

Связь с локальной инфраструктурой можно обеспечивать с помощью VPN-инстанса, сетевых образов из Cloud Marketplace или Yandex Cloud Interconnect.

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

Защита данных
Для шифрования данных на управляемых пользователем ключах у клиентов Yandex.Cloud есть возможность применять сервис Yandex Key Management Service. Сервис предназначен для управления криптографическими ключами пользователя и предоставляет возможность шифрования данных при сохранении пользовательского контроля над ключами шифрования. Отдельного внимания заслуживает интеграция сервиса KMS с Yandex Object Storage: в этом случае пользователю достаточно указать ключ KMS, на котором необходимо шифровать данные бакета, и все данные будут защищены с помощью указанного ключа, а просмотр или модификация данных станут невозможны без прав доступа на указанных ключ. Таким образом, можно контролировать использование данных.

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

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

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

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

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

Разделяемая ответственность
Ответственность провайдера и клиента различается в зависимости от модели использования облачных сервисов (IaaS — инфраструктура как услуга, PaaS — платформа как услуга, SaaS — программное обеспечение как услуга) и имеющихся у облачного провайдера защитных механизмов и политик: возможностей соблюдения законодательства, стратегии управления рисками, модели угроз и других факторов.


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

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

При использовании управляемых сервисов (PaaS/SaaS) забот у конечного пользователя становится гораздо меньше, так как провайдер уже обеспечивает защиту компонент PaaS/SaaS-сервисов. Например, в случае Yandex Managed Service for ClickHouse провайдер защищает виртуальные машины сервиса, выполняет резервное копирование базы данных и шифрует пользовательские данные. В то же время клиент обязан классифицировать данные, обеспечить разграничение доступа к данным, настроить процессы для их защиты, а также отвечает за управление своими пользователями и конечными устройствами.

Безопасность на стороне Yandex.Cloud
С одной стороны, распределение ответственности удобно для клиентов. Им нужно меньше заботиться о безопасности, в сравнении с защитой системы при ее расположении на собственных мощностях. С другой стороны, данные и система все еще принадлежит конкретному клиенту, поэтому он не может безоглядно доверять провайдеру, просто полагаясь на его заверения. Точнее, все зависит от уровня экспертиз в части безопасности, которая есть (или нет) у конкретного клиента. Если такая экспертиза находится на зрелом уровне, то компания в состоянии оценить риски, уточнив особенности защиты на стороне провайдера и изучив определенные подтверждения рассказам провайдера (например сертификаты соответствия). Для удобства клиентов, Yandex.Cloud публикует определенную информацию о некоторых аспектах информационной безопасности платформы. Также мы всегда открыты для общения в режиме 1-1 для обсуждения деталей.

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

• Безопасность дата-центров
• Безопасность инфраструктуры
• Защита на уровне данных
• Соответствие стандартам
• Безопасность дата-центров

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

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

Безопасность физических машин и сервисных виртуальных машин обеспечивается на нескольких уровнях: используется ряд межсетевых экранов, а также дополнительные средства защиты (AppArmor, Seccomp, Osquery 4 и система мониторинга и оповещения о подозрительном поведении).

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

Защита данных. SDLC и defence in depth. Шифрование
Безопасность Yandex.Cloud организована таким образом, что одной угрозе противостоит набор средств защиты на разных уровнях. Такой подход удорожает любую потенциальную атаку и позволяет оперативно выявлять и предотвращать деятельность злоумышленников. Техническая команда платформы соблюдает процесс безопасной разработки (security development lifecycle, SDLC), выстраивая основу безопасности облачных сервисов с самых ранних этапов проекта. Дополняющая эти базовые принципы концепция эшелонированной обороны (defense in depth) обеспечивает многоступенчатую защиту, которая препятствует действиям злоумышленников и способствует раскрытию их деятельности еще при подготовке атаки.

Для шифрования разработаны несколько уровней:

• Шифрование на уровне storage.
• Шифрование на уровне баз данных Yandex Database. Данные шифруются непосредственно перед отправкой в storage.
• Шифрование резервных копий данных в Managed Services for Databases (MDB). Все резервные копии, создаваемые MDB, шифруются перед отправкой в постоянное хранилище.
• Шифрование данных при передаче.

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

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

• Это перепроверка самих себя и возможность подтвердить определенные тезисы в части безопасности клиентам.
• Предоставление возможности клиентам приведения в соответствии (например, с 152-ФЗ или PCI DSS) их систем, при размещении в облаке.

В начале 2020 года Yandex.Cloud стала первой в России и СНГ публичной облачной платформой, выстроившей управление информационной безопасностью по стандарту ISO/IEC 27017:2015 и обеспечившей защиту персональных данных пользователей по международному стандарту ISO/IEC 27018:2019. Соответствие платформы требованиям международных нормативных документов подтверждено независимым аудитором — Британским институтом стандартов (BSI). Таким образом, наша платформа соответствует требованиям трех международных стандартов информационной безопасности: ISO/IEC 27001:2013, ISO/IEC 27017:2015, ISO/IEC 27018:2019.

В конце 2020 года Yandex.Cloud получила сертификат соответствия PCI DSS 3.2.1. PCI DSS содержит набор требований для защиты данных держателей карт. Так как требованиям стандарта соответствуют как ЦОДы, так и облачные сервисы, клиенты получили возможность размещать в облаке платежные шлюзы и другие системы, обрабатывающие данные платежных карт.

Ну и наконец, платформа прошла аудит по требованиям ФЗ-152 и теперь соответствует более высокому уровню защищенности персональных данных — УЗ-1, что позволяет клиентам хранить и обрабатывать в том числе специальные категории персональные данных, например медицинские данные.

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

Заключение
Мы рассказали про аспекты безопасности, за которые отвечает Yandex.Cloud. В следующей статье мы расскажем про возможности обеспечения безопасности, которые есть у клиентов.

Команда Yandex.Cloud разработала плагин для виртуальной инфраструктуры рабочих столов. С его помощью VDI Citrix интегрируется с облачной платформой. Плагин поддерживает гибридные инсталляции и позволяет перенести часть инфраструктуры в облако тем, кто уже работает с CVAD on-premise и нуждается в дополнительных мощностях для виртуальных рабочих мест и приложений.

Плагин позволяет управлять инфраструктурой в Yandex.Cloud с помощью инструмента Machine Creation Services — MCS. Также решение подходит для развертывания CVAD с нуля в облаке.

Плагин предоставляется бесплатно. Его разработка — результат партнерства Yandex.Cloud и Citrix.

Как это работает
Развертывание CVAD с нуля в облаке Yandex.Cloud
Для внедрения CVAD на собственной IT-инфраструктуре предприятию недостаточно иметь штат квалифицированных специалистов для настройки и поддержки VDI. Необходимы капитальные вложения в серверы, СХД, сетевое оборудование. Это приводит к увеличению бюджета и требует времени на согласование закупки оборудования.

В облаке решение Citrix разворачивается быстро и стоит дешевле, чем on-premise. Всю инфраструктуру предоставляет и обслуживает провайдер, а платить нужно только за использованные ресурсы Yandex.Cloud.

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

Гибридное решение: on-premise + Yandex.Cloud
Когда решение CVAD развернуто on-premise, с ростом нагрузки возникает потребность в дополнительном оборудовании. IT-департаменту предприятия трудно точно спрогнозировать потребность в ресурсах. Задачу усложняет необходимость держать резервные мощности для пиковых нагрузок. Избыточная оценка приводит к неоправданным тратам на оборудование.

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

С плагином можно создавать гибридные инсталляции из физических и виртуальных ресурсов и управлять инфраструктурой VDI с помощью привычных инструментов. Подготовка и развертывание мастер-образов происходят автоматически с помощью инструментов Citrix Studio и PowerShell SDK, используемых в инсталляциях CVAD. Вся работа ведется в привычной среде Citrix — дополнительное обучение не требуется.

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

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

Почему Yandex.Cloud
Платформа Yandex.Cloud — масштабируемое и надежное решение для реализации любых IT-проектов. В облаке размещены сайты и приложения самого Яндекса. Гибкость платформы позволяет мгновенно наращивать и освобождать ресурсы, когда нагрузка меняется. Благодаря модели pay as you go (PAYG) вы не платите за неиспользуемые и простаивающие ресурсы — только за реально использованные мощности.

Все сервисы платформы, а не только дата-центры, соответствуют требованиям закона о защите персональных данных ФЗ-152 и имеют самый высокий уровень защиты — УЗ-1. Это позволяет предприятиям федерального и международного уровня размещать в Yandex.Cloud персональные данные. Система управления информационной безопасностью (СУИБ) сертифицирована по стандартам ISO 27001, ISO 27017 и ISO 27018. Сертификат высшего уровня безопасности PCI DSS — Level 1 — позволяет клиентам Yandex.Cloud защищать данные держателей банковских карт. Подробную информацию вы можете найти на странице Безопасность.

Фактический уровень SLA Yandex.Cloud за последние три года не опускается ниже 99,9996%.

Получить плагин и внедрить гибридное решение Citrix cloud.yandex.ru/blog/posts/2021/03/citrix-plugin#contact-form

Schlumberger и Yandex.Cloud заключили соглашение о сотрудничестве, в рамках которого платформа искусственного интеллекта (ИИ) и цифровых инструментов DELFI будет размещена на Yandex.Cloud. Партнерство Schlumberger и Yandex.Cloud позволит российским энергетическим компаниям воспользоваться новыми цифровыми сервисами и технологиями в области искусственного интеллекта и больших данных для повышения эффективности бизнеса.

Среда DELFI объединяет ведущие программные решения от компании Schlumberger, включая программную платформу Petrel E& P, платформу для скважин Techlog и инструментарий для моделирования пласта высокого разрешения INTERSECT, и расширяет их возможности с помощью искусственного интеллекта и высокопроизводительных вычислений, которые становятся возможными благодаря облачным технологиям.

Эти цифровые технологии выгодны в сегментах разведки и добычи, поскольку они позволяют работать с крупными и сложными моделями, производить цифровые расчеты моделей и их анализ за меньшее время, по сравнению с традиционными вычислительными решениями. Например, время выполнения 400 расчетов модели геологической среды, для пользователей DELFI, было сокращено с 11 дней до 46 минут. Такое повышение производительности приводит к значительному сокращению времени вывода продукта на рынок для операторов нефтегазовой отрасли, что позволяет им намного быстрее окупать свои инвестиции.

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

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

Сервис Yandex.Cloud был выбран из-за его обширной и постоянно растущей сети центров обработки данных по всей России, поддерживаемых собственными технологиями и сервисами для хранения, обработки и анализа данных с расширенными цифровыми возможностями, включая искусственный интеллект. Сервис Yandex.Cloud также соответствует международным и российским стандартам защиты и безопасности данных, в том числе требованиям 152-ФЗ, стандарту безопасности платежных карт PCI DSS и сертификатам соответствия международным стандартам информационной безопасности ISO 27001, ISO 27017 и ISO 27018.

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

прокомментировал Олег Коверзнев, операционный директор Yandex.Cloud.