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

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

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

В этой статье разберём, почему Edge не просто модный buzzword (или всё-таки он), как периферийные вычисления оказались в центре внимания: от убийства лагов до защиты данных, от кейсов Tesla до умных электросетей. Детали под катом!

Вы наверняка слышали об OpenStack. Блин, да о нем говорят на каждом более-менее связанном мероприятии. Все кому не лень пропагандируют OpenStack. Модно, молодежно, все уже есть, Open Source, вливайся давай. И вот наслушавшись тонны маркетингового булшита, вы решаетесь: Будем ставить OpenStack!

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

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

И вот появляется Apache Iceberg — файловый формат, который уже используют в Netflix, Apple, LinkedIn и Stripe для хранения петабайтов данных с минимальными издержками на поддержку. Но что делает его таким особенным? Почему его называют «Data Lake без боли»? И самое главное — как заставить Apache Iceberg работать на вас? Давайте разбираться.

Модераторы сабреддита «PC Master race» призвали владельцев мощных игровых видеокарт присоединиться к научным облачным вычислениям Стэнфордского проекта Folding@Home, который прямо сейчас занимается расчетом моделей сразу по восьми направлениям для борьбы с COVID-19. Инициативу сообщества Reddit уже поддержала компания Nvidia, которая призвала через твиттер своих потребителей предоставить ученым вычислительные мощности своих видеокарт:


Важно отметить, что сабреддит «PC Master race» не пытается хайпануть на теме коронавируса: поддержка Folding@Home и первый систематизированный мега-тред, посвященный проекту, был опубликован еще 4 месяца назад, когда о коронавирусе даже не слышали. Кроме того, пользователи упоминали F@H в сабреддите на протяжении последних пяти лет.

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

Когда вы указываете в Dockerfile:

FROM ubuntu

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

В процессе pull можно заметить, что он состоит из 5 слоёв:

docker pull ubuntu

ubuntu:latest: The image you are pulling has been verified
511136ea3c5a: Pull complete
3b363fd9d7da: Downloading 8.641 MB/197.2 MB 3m18s
607c5d1cca71: Download complete
f62feddc05dc: Download complete
8eaa4ff06b53: Download complete

Чтобы понять содержание каждого слоя, можно выполнить команду:

docker history --no-trunc ubuntu > history.txt

либо посмотреть исходный Dockerfile на GitHub. Каждый слой соответствует отдельной строке в Dockerfile:

511136ea3c5a — это отправная точка, пустой образ под названием scratch (строка FROM scratch).

3b363fd9d7da — «вливание» официального образа Ubuntu из файла ubuntu-trusty-core-cloudimg-amd64-root.tar.gz

На Хабре неоднократно обсуждали различные «облачные хостинги» (вот о clodo недавно написали), но про Оверсан-Скалакси мне упоминаний найти не удалось. В вечных поисках надежного и быстрого хостинг-провайдера я остановился на Linode.com. Данный хостинг очень надежен, быстр и цены хороши. Однако ДЦ в Лондоне находится на значительном расстоянии, пинг не всегда устраивает (хочется ведь, чтобы все было «со скоростью света»), да и не самый удобный способ масштабирования.

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

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

Итак, посмотрим, что же нам предлагает Оверсан-Скалакси. На главной странице первым делом бросается в глаза «ползунок», который позволяет примерно рассчитать стоимость хостинга:

Однажды коллега поделился размышлениями об API для распределённых вычислительных кластеров, а я в шутку ответил: «Очевидно, что идеальным API был бы простой вызов telefork(), чтобы твой процесс очнулся на каждой машине кластера, возвращая значение ID инстанса». Но в итоге эта идея овладела мной. Я не мог понять, почему она такая глупая и простая, намного проще, чем любой API для удалённой работы, и почему компьютерные системы, кажется, не способны на такое. Я также вроде бы понимал, как это можно реализовать, и у меня уже было хорошее название, что является самой трудной частью любого проекта. Поэтому я приступил к работе.

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

На видео показано, что рендеринг на 64-ядерной VM в облаке завершается за 8 секунд (плюс 6 секунд на телефорк туда и обратно). Тот же рендеринг локально в контейнере на моём ноутбуке занимает 40 секунд:

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

Игнат — руководитель одной из групп в нашей службе технологий распределенных вычислений. Окончил мехмат МГУ и Школу анализа данных, в Яндексе с 2009 года.



Под катом — подробная расшифровка лекции и слайды.

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

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

Взлеты и падения на рынке труда в IT за первые 50 лет его существования предоставили карикатуристу Джону Клосснеру множество идей. Давайте взглянем в прошлое и посмотрим, что изменилось (и не изменилось) за эти годы.

Февраль 2013: Управление ожиданиями

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


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

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

Однако, такое простое задание как поделится файлами с незарегистрированным пользователем будет весьма накладно: придется давать ссылку на каждый файл (предварительно поместив их в папку Public), который требуется передать. Поэтому Вы наверняка воспользуетесь либо одним из известных файлообменников или же простой электронной почтой. Но почему бы не организовать такой файл-хостинг с удобным интерфейсом у себя в Dropbox?

В рамках проходящей в данный момент выставки CES 2019 подразделение IBM Research провело анонс первой в мире квантовой системы, пригодной для коммерческого применения.

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

Лайфхак по 152-ФЗ

Для начала небольшое, но важное отступление.

Недавно знакомый из торговой компании попросил посмотреть их договор с веб-студией. Те собирались дорабатывать сайт магазина. Первым делом я открыл техзадание и увидел, что ребята планируют зарегистрировать владельца сайта в Роскомнадзоре как оператора персональных данных. Я подумал: «Они это серьезно?» И сам же ответил: «К сожалению, да».

Произошло, пожалуй, самое крупное падение сервиса Битрикс24 за свою историю.В общей сложности на протяжении 3 дней у пользователей Российского сегмента возникали трудности с доступностью www.bitrix24.ru, www.bitrix24.by и www.bitrix24.kz Общее количество зарегистрированных в сервисе компаний составляет около 3 000 000.

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

Чуть больше года назад я опубликовал сравнение российских облачных операторов: статья многим понравилась и была полезна. Примерно через полгода я начал получать много отзывов и просьб о том, что неплохо было бы сделать новый обзор, актуализировав данные по ценам, добавив в запрос дополнительные сервисы и дополнив его новыми компаниями. В этот раз в сравнение вошли уже 34 компании (в прошлом году их было более, чем в 2 раза меньше), включая зарубежные сервисы Amazon и Rackspace, а сбор информации занял более двух месяцев.



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

На фоне продолжающейся истории с запуском "Единого реестра запрещённых сайтов" получают свое развитие и другие интересные события.
Сразу несколько интернет-провайдеров в ноябре внезапно прекратили предоставление услуг файлообмена во внутри-домовых сетях на основе протокола DC++. Первоначально провайдеры закрыли данные сервисы якобы на «профилактику», а через непродолжительное время заявили о полном их закрытии в целях соблюдения закона "О защите детей от запрещенной информации» и разместили на своих сайтах приблизительно такие анонсы:

21 апреля в 01:41 по тихоокеанскому времени произошёл серьёзный сбой в одном из дата-центров Amazon Web Services, «облака» для многих сайтов. Некоторые крупные проекты (Reddit, Quora, Foursquare) ушли в офлайн или сильно пострадали. Я уже видел кучу дезинформации с намёком на то, что проблемы пострадавших сайтов связаны только с ленью инженеров этих проектов, но в данном случае причина в другом. И вот почему.

У AWS две концепции относительно доступности: регионы (Regions) и зоны доступности (Availability Zones, AZ). Есть пять регионов: два в США (западное и восточное побережье), один в Европе (Ирландия) и два в Азии (Токио, Сингапур). В каждом регионе расположены несколько AZ, которые должны быть изолированы друг от друга и не иметь общей точки сбоя, кроме стихийного бедствия или чего-нибудь подобного масштаба.

Компании, предоставляющие сервисы большим корпорациям или группам людей, часто работают 24/7 по принципу «Follow the Sun» — когда одни часовые пояса только просыпаются, другие уже работают или ложатся спать. Эта волна идёт вокруг земного шара, следуя за восходом Солнца (её «фронт» идет как раз в 8 — 10 часов утра). Это же время — пора пиковой нагрузки на электрические сети.

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

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

Ну и вот теперь показываю вам.

Задача: понять, насколько одинаковый тариф с одинаковым количеством vCPU и RAM выражается в реальную производительность у разных провайдеров.

Забегая вперёд — у меня нет вопросов к Селектелу, Клауд.ру (Сберу) и Яндексу (почти). У них переподписки, вроде, нет. А вот дальше начинается дичь.

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

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

Входные требования следующие:

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