Облачные вычисления *

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



Вторая часть

Год назад мировые дата-центры потребляли 2% всей генерируемой на планете электроэнергии. По прогнозам аналитиков, эта цифра вырастет до 5% к 2020 году. При этом примерно половина всей этой энергии расходуется на охлаждение. Эти затраты и призваны сократить системы ИИ.

Сегодня поговорим о последних разработках в этой области.

Что такое Istio? Это так называемый Service mesh, технология, которая добавляет уровень абстракции над сетью. Мы перехватываем весь или часть трафика в кластере и производим определенный набор операций с ним. Какой именно? Например, делаем умный роутинг, или реализуем подход circuit breaker, можем организовывать «canary deployment», частично переключая трафик на новую версию сервиса, а можем ограничивать внешние взаимодействия и контролировать все походы из кластера во внешнюю сеть. Есть возможность задавать policy правила для контроля походов между разными микросервисами. Наконец, мы можем получить всю карту взаимодействия по сети и сделать унифицированный сбор метрик полностью прозрачно для приложений.

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

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

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

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

Прим. перев.: Эта статья опубликована в официальном блоге Kubernetes и написана двумя сотрудниками Intel, принимающими непосредственное участие в разработке CPU Manager — новой возможности в Kubernetes, о появлении которой мы писали в обзоре релиза 1.8. В настоящий момент (т.е. для K8s 1.11) эта фича имеет статус бета-версии, а подробнее о её предназначении читайте далее в заметке.

Публикация рассказывает о CPU Manager — бета-фиче в Kubernetes. CPU Manager позволяет лучше распределять рабочие нагрузки в Kubelet, т.е. на агенте узла Kubernetes, с помощью назначения выделенных CPU на контейнеры конкретного пода.

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

• Вместо предисловия
• Забегая вперед: попробуйте FPGA в работе
• О стандарте OpenCL для программирования FPGA
• Среда OpenCL для создания исполняемого кода
• Ближе к делу: строим фрактал
• Заключение

Cоавтор статьи: Mike Cheng

Google Cloud Platform теперь в своем портфолио имеет образы виртуальных машин, разработанные специально для тех, кто занимается Deep Learning. Сегодня мы поговорим о том что эти образы из себя представляют, какие преимущества они дают разработчикам и исследователям, ну и само собой о том, как создать виртуальную машину на их базе.

Наверное каждый, кто хоть раз озадачивался поиском высокопроизводительного software-defiined хранилища рано или поздно слышал про DRBD, а может даже и имел дело с ним.

Правда на пике популярности Ceph и GlusterFS, которые работают в принципе неплохо, а главное сразу и из коробки, все просто немного подзабыли про него. Тем более что предыдущая версия не поддерживала репликацию более чем на два узла, и из-за чего часто встречались проблемы со split-brain, что явно не добавило ему популярности.

Решение и правда не новое, но вполне конкурентоспособное. При относительно небольших затратах на CPU и RAM, DRBD предоставляет реально быструю и безопасную синхронизацию на уровне блочного устройства. За все это время LINBIT — разработчики DRBD не стоят на месте и постоянно дорабатывают его. Начиная с версии DRBD9 перестает быть просто сетевым зеркалом и становится чем-то бОльшим.

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

Например DRBD9 поддерживает до 32 реплик, RDMA, diskless-ноды, а новые инструменты оркестрации позволяют использовать снапшоты, online-миграцию и много чего другого.

Несмотря на то что DRBD9 имеет инструменты интеграции с Proxmox, Kubernetes, OpenStack и OpenNebula, на данный момент они находится в некотором переходном режиме, когда новые инструменты еще не везде поддерживаются, а старые уже очень скоро будут объявлены как deprecated. Речь идет о DRBDmanage и Linstor.

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

В мае появился «магический квадрант» Gartner 2018 года для IaaS-рынка: Magic Quadrant for Cloud Infrastructure as a Service, Worldwide. Команда Mail.Ru Cloud Solutions сделала выжимку по самым интересным темам, которой мы делимся с вами — возможно, кому-то будет полезно. Как бизнес использует облака и чего ожидает? Каковы тенденции года на рынке облачных услуг? Как сегодня выглядит «магический квадрант» для IaaS? В заключительной части поста мы делимся нашим видением ситуации на отечественном рынке.

• Что такое IaaS
• Эффект от внедрения IaaS
• Технологические тенденции
• Общие тенденции на рынке IaaS
  
  • Размывание границ IaaS и PaaS
  • Мультиоблако
  • Консолидация рынка IaaS и локальные провайдеры
  • Конкуренция IaaS с частными облаками
• Что учитывать пользователям при выборе IaaS
• Что учитывать провайдерам IaaS в своей стратегии
• Магический квадрант
• О ситуации на российском рынке облаков

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

Суть облачных вычислений

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

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

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

Помимо возможной экономии на капитальных затратах есть и другие существенные преимущества:

На сегодняшний день ЦЕРН является одним из крупнейших пользователей Kubernetes в мире. Согласно недавней статистике, в этой европейской организации, стоящей за Большим адронным коллайдером (БАК) и рядом других известных научно-исследовательских проектов, запущено 210 кластеров K8s, обслуживающих одновременное выполнение сотен тысяч задач. Эта история успеха — о них.

Продолжается прием заявок на участие в IBM WatsonBuild – международном конкурсе по созданию приложений и сервисов на базе IBM Watson.
К участию приглашаются партнеры-разработчики когнитивных решений с применением API-интерфейсов Watson (требуется использование как минимум одного сервиса IBM Watson). Все разработки ведутся в среде IBM Cloud.

Mail.Ru Cloud Solutions и российское сообщество OpenStack приглашают вас принять участие в конференции, посвященной восьмилетию проекта OpenStack: https://bit.ly/2IUjosD Мероприятие пройдет в следующую пятницу, 13 июля. В этом году OpenStack-сообщество соберётся в офисе Mail.Ru Group, чтобы отпраздновать очередную годовщину проекта обсуждением открытых инфраструктурных решений. Под катом — подробная программа, тезисы нескольких докладов и ссылка на регистрацию.

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

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

Для продвинутых сразу скажу, что в этой статье речь пойдет про bin packing, а остальным, кто хочет узнать, как с помощью относительно несложных расчетов сэкономить до 30% серверных ресурсов, добро пожаловать под кат.

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

При оценке эффективности перехода в облака Заказчики зачастую склонны сравнивать стоимость владения облаками и железом в лоб. Например, если покупаем 5 серверов с 40 процессорными ядрами и 256 ГБ RAM, то и у облачного провайдера запрашиваем аналогичные ресурсы (40*5=200 vCPU + 256*5=1280 ГБ vRAM), а потом сравниваем затраты за 3 года или даже 5 лет.
К сожалению, в большинстве случаев такой подход не будет объективным, поскольку не учитывает ряд важных нюансов, напрямую влияющих на стоимость владения.

1. Не учитываются ресурсы, требуемые для обеспечения отказоустойчивости

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



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

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

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

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

Пример от Натана Бенаича, вице-президента компании Point Nine Capital:

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

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

Джон Мелас-Кириази, инвестор Spark Capital, повторяет это мнение:

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

Многие ссылаются на Закон Мура как на причину «порядка величины» улучшений в облачном ценообразовании. Другие заходят ещё дальше и создают свои собственные теории. Например, Закон Безоса, предложенный Грегом О'Коннором (CEO AppZero) в виде идеи о том, что «за всю историю облака цена единицы вычислительной мощности снижается на 50 процентов примерно каждые три года».

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

Но действительно ли цены на облако падают?

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

Вчера компания Amazon Web Services объявила о полноценном запуске своего облачного сервиса на базе Kubernetes — EKS (Amazon Elastic Container Service for Kubernetes). Впервые он был анонсирован в ноябре прошлого года (вскоре после того, как AWS присоединилась к стоящему за Kubernetes фонду CNCF), но тогда он имел статус предварительного доступа. Что скрывается за EKS?

Google Colaboratory — это не так давно появившийся облачный сервис, направленный на упрощение исследований в области машинного и глубокого обучения. Используя Colaboratory, можно получить удаленный доступ к машине с подключенной видеокартой, причем совершенно бесплатно, что сильно упрощает жизнь, когда приходится обучать глубокие нейросети. Можно сказать, что она является некоторым аналогом гугл-документов для Jupyter Notebook.

В Colaboratory предустановлены Tensorflow и практически все необходимые для работы Python-библиотеки. Если какой-то пакет отсутствует, он с легкостью устанавливается на ходу через pip или apt-get. Но что если необходимо собрать проект из исходников и подключиться к GPU? Оказывается, это может быть не настолько просто, что я выяснил в ходе сборки SSD-Caffe. В этой публикации я дам краткое описание Colaboratory, опишу встреченные трудности и способы их решения, а также приведу несколько полезных приемов.

Весь код доступен в моем Colaboratory Notebook.