Странные управленческие решения внутри хостинга

Звонит как-то вендор и говорит, что в возврате бракованного железа — не их жёсткий диск.


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

Гарантийный отдел ковыряется с диском, а потом звонят:
— А зачем вы подменили диск?

Мы такие:
— В смысле подменили?
— Мы вам продавали другой. А тут корпус тот, а внутри — другой. Какие-то следы от отвёртки.

Дичь полнейшая! Мы начали было ругаться, но потом стали разбираться. Начали смотреть на камеры и увидели, что наш сотрудник очень подозрительно себя вёл, когда работал с этим диском в стойке. Как в плохих комедиях про жуликов: постоянно осматривался по сторонам, отходил в сторону, возвращался. Оказалось, что он подменил диск. Честно, я не знаю зачем. Его финансовая выгода минимальная, скорее всего, даже не окупает время работы по замене корпуса.

У нас было ещё несколько странных ситуаций, и сейчас я о них расскажу.

Форекс-трейдер
VDS часто покупаются для торговли на биржах. Ну, на нормальных биржах: я имею в виду тех, где важно географическое расположение сервера для минимизации задержек. Но есть и биржи уровня Форекса. Вернее их даже биржами назвать нельзя. Это на сленге трейдеров — кухня. Напомню, что многие из них попали в список компаний с признаками нелегальной деятельности, который завёл ЦБ. У меня есть глубокое личное убеждение, основанное на здравом смысле и математике, что система работает как качели для вытаскивания денег из не самых разбирающихся в вопросе клиентов. Возможно, это не так, но свою точку зрения я могу аргументировать и обосновать при необходимости. Но в истории важно другое. Звонит мой знакомый, который взял у нас сервер в Швейцарии. И вот он начинает в открытую меня и всех наших сотрудников обвинять в том, что мы залезаем к нему на сервер в процессе торгов и вмешиваемся в его форекс-сделки.

По его словам, он придумал великую стратегию, а убыточные сделки берутся рынком, плюсовые же вовремя не берутся, игнорируются. И в этом виноваты мы. Точнее, сначала он обратился с задачей, что его не устраивает производительность сервера. С его слов, она радикально падала в момент выхода новостей. В 16:30, когда выходит мировая статистика. В этот момент времени все трейдеры, кто работает с помощью автоматических торговых систем, начинают многократно усиливать свою активность. Если, грубо говоря, внутри дня он делает десять сделок, то в эти 16:30 и одну минуту он может сделать сто сделок. Естественно, это создаёт пик нагрузки, причём не локально, а на принимающем сервере. Но трейдер этого не понимает, он думает, что у нас сервер именно в 16:30, когда ему надо выставить заявку или закрыть заявку, тормозит. А это совпадает с самым нужным временем. И не верится, что это просто совпадение.

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

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

Игровые серверы школьников
Школьники довольно часто размещают у нас игровые серверы. Это, скажем так, сложные клиенты, потому что они выбирают третий по цене тарифный план. Первый — это промо за 30 рублей в месяц (по цене IP), второй — урезанная версия стандартных конфигураций за 130 рублей и третий уже полноценный сервер — от 300 рублей в месяц.

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

Поддержка вежливо объясняет суть проблемы и предлагает подключить защиту от DDOS-атак за 400 рублей (причём первый месяц бесплатно). По нашей практике, потом можно будет играть совершенно спокойно. На что клиент начинает нас обвинять в том, что это мы специально дидосим его, чтобы он нам заплатил ещё. Далее закономерно встаёт вопрос о возврате средств, и обычно мы средства возвращаем и с лёгкостью расстаёмся с таким клиентом.

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

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

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

И вот пишет клиент, что наш сервер не отвечает.

Мы просим трассировку. Клиент делает, присылает. Мы сообщаем, что RDP блокирует его отель, и желаем приятного отпуска в Таиланде. Клиент немного в панике, но мы поясняем, что его Wi-Fi-точка названа именно по отелю. И даём ссылку на то, как это обойти. В тот раз помогло.

Регистрации под ботами
Очень странная ситуация была с тестовыми периодами на наших 32-ядерных машинах. Кто-то научился брать американские номера, парсить голос, русский текст и цифры. Как только криптовалюты совершали очередной прыжок, начинались авторегистрации, а дальше серверы использовались (судя по характеру нагрузки) для майнинга криптовалют. Не знаю, что это было, но майнить биткоин на VDS без видеокарты — идея откровенно так себе. Процессор уходит в потолок, три дня они пытаются что-то там сделать, потом период заканчивается. Мы обновили капчи, но на следующей волне скачка курса биткоина снова начались авторегистрации. Я откровенно не понимаю, какой в этом смысл, ведь аренда американского номера стоит дороже, чем возможный профит с майнинга на процессоре три дня. Сейчас эти волны мы наконец-то победили.

Блокировки по IP
Мы выдаём один статический IP клиенту при аренде сервера. Это не карусель динамических адресов, не замены раз в месяц, а конкретный IP, привязанный к клиенту. Сначала мы проверяем его чистоту и отсутствие во всяких чёрных списках, а потом даём клиенту.

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

Ещё накручивают отзывы и просмотры на Амазоне. Потом — в поддержке: «Ребята, это мой не первый аккаунт, можете, пожалуйста, сменить мне IP-адрес, потому что меня забанило?»

Бывает так, что админ настраивает клиенту работу на сервере, но забывает уточнить вопрос про лицензии. Звонит генеральный директор, у которого 25 сотрудников, и они все сидят на удалённом рабочем столе, у нас размещали соответственно. Весь замес в том, что системный администратор, который это настраивал, был на аутсорсе. Он настроил кучу виртуальных рабочих мест. Человек платил около 35 тысяч. У него там размещалось 25 сотрудников, и 120 дней человек вообще не знал никакой проблемы с подключением к удалённому рабочему столу. А цимес в том, что Майкрософт даёт триалку на размещение этого удалённого сервера рабочих столов 120 дней ровно. Человек четыре месяца, получается, пользуется, и тут внезапно посреди пятого месяца обнаруживает, что у него ни один сотрудник не может зайти. Диктует нам ошибку, мы всё прекрасно понимаем, что у него там происходит. И предлагаем ему два варианта:
— Вы либо удаляете эту службу, которая не даёт вам подключиться вообще в принципе, либо платите за каждую лицензию.
— В общем, ребят, я не буду платить тройную цену от сервака.
Неудивительно, потому что лицензия стоит 91 тысячу рублей, а у него сервак стоит 36 тысяч.
— Ребята, надо, короче, решать. Давайте так: мне по-любому нужно это бесплатно. Что если мы оформим договор на другое лицо, и таким образом у меня будет ещё 120 дней? А что если вы измените человека, у меня сейчас есть знакомый, он зарегистрируется?
— А вы точно понимаете, что сейчас у официального партнёра MS спрашиваете, как их же обмануть?
— Да! Ребята, какие ещё варианты есть?

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

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

Это ничего не объясняло, но дальше удалось поговорить. Сотрудник сказал, что внимательно всё прочитал и не хочет, чтобы это случилось с ним. Поэтому увольняется.

Никаких выводов и действий. Просто, возможно, он счастлив где-то ещё.

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

В итоге уголовку он не получил, полицейские оказались добрыми. Оставили всего до утра к КПЗ и отпустили домой к жене и детям. Как бы конец истории, но непонятно, что делать дальше, потому что в беседе он пояснил, что нет гарантии того, что ровно такое же не повторится. Например, в офисе. Или в серверной. Или на переговорах с клиентом или ЦОДом.

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

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

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

Письмо приходит, в нём просьба поменять основную почту доступа.

Мы соответственно меняем почту.

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

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

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

Внимание. Смена валюты.



Уведомляем Вас, что с 15.06.2021 основная валюта в нашей биллинг-панели и на сайте будет изменена с долларов на евро. Средства на Вашем балансе будут конвертированы в евро по среднему курсу на 15.06.2021.

Мы — компания, которая зарегистрирована в Нидерландах (Zomro B.V.). Все расчеты мы выполняем в евро, так как здесь находится основной штат сотрудников, здесь мы размещаем всё наше оборудование, покупаем комплектующее, сервера, платим за электроэнергию и каналы. Для нас важно иметь основную валюту — евро, в биллинге и на сайте. Так как курсовые ралли между долларом и евро сказываются на нашей финансовой эффективности. Связи с чем, мы вынуждены обновить цены в соответствии реальной рыночной ситуацией для некоторых услуг. Данный этап в нашей истории поможет продолжить развитие компании, повышать качество услуг и улучшать техническую поддержку. Мы очень рассчитываем на Ваше понимание.

Дайджест новостей за апрель, май и платформы данных



Дайджест новостей за май
Исследование EY и Yandex.Cloud: облака в российских компаниях все чаще закупают не айтишники, а бизнес
Совместно с Ernst & Young мы провели исследование и выяснили, каких перемен добиваются компании, которые уже в облаке, и как из технологии облака становятся бизнес-платформой. Подробнее о том, как облака меняют российский бизнес, как компании выбирают провайдера и почему мигрируют не все, в спецпроекте Прививка облаком: как одна технология меняет крупные российские компании.

Yandex.Cloud ещё раз подтвердила высокий уровень безопасности
Платформа Yandex.Cloud прошла добровольную аттестацию информационных систем персональных данных (ИСПДн). Этим мы ещё раз подтвердили высокий уровень безопасности данных, размещённых в облаке, и дали нашим клиентам возможность аттестовать собственные системы. Ещё раз подтвердили высокий уровень безопасности данных и получили аттестат безопасности на 3 года.

Новая программа поддержки образования и науки в области Computer Science
Мы запустили инициативу «Программа содействия образованию и науке в области Computer Science», в рамках которой поддерживаем учебные и научные учреждения с помощью грантов на сервис для ML-разработки и анализа данных Yandex DataSphere. Узнать больше об условиях и подать заявку на грант можно на сайте программы.

Бесплатный курс по визуализации данных совместно с Нетологией
Совместно с командой Нетологии мы запустили бесплатный курс-симулятор «Визуализация данных: от скучных графиков к интерактивным дашбордам». На нём вы попробуете себя в роли аналитика в крупной компании, построите интерактивную карту клиентов в DataLens, соберёте отчёт-конструктор расходов в Excel, сравните показатели в Power BI, а в конце наведёте красоту в Tableau.

Российские ученые научили нейросеть прогнозировать урожай вместе с Yandex.Cloud
Биологический факультет МГУ вместе с консорциумом в составе ФНЦ имени Мичурина, Тамбовского государственного университета и агроинженерного центра ВИМ создали в Yandex.Cloud полноценную систему мониторинга и прогнозирования урожая.

Подробнее МАЙ
cloud.yandex.ru/blog/posts/2021/06/digest-may

Дайджест новостей за апрель
Yandex.Cloud в Казахстане
Казахстан стал первой страной после запуска платформы Yandex.Cloud в России, в которой стратегия развития ориентирована на запросы местных компаний. Среди первых клиентов платформы в Казахстане инвестиционно-строительный холдинг BI Group, оператор сотовой связи Kcell, HR-tech платформа Clockster и сервис для автоматизации работы отдела кадров HR Messenger.

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

Yandex.Cloud Solution Library for AWS
Мы знаем, что многим компаниям важна возможность работать с двумя облачными провайдерами одновременно. Для разработчиков, которые хотят развернуть проект в Yandex.Cloud и Amazon Web Services, мы подготовили набор рекомендаций и примеров кода для основных сценариев и задач, собранных в публичном репозитории на GitHub.

Быстрые нереплицируемые диски
У нас появились быстрые сетевые хранилища — нереплицируемые диски. Устройство нереплицируемых дисков существенно проще стандартных сетевых хранилищ SSD. Благодаря этому производительность выше в несколько раз.

Подтвердили соответствие требованиям безопасности Центробанка России
Мы стали первой российской публичной облачной платформой, подтвердившей соответствие стандарту ГОСТ Р 57580.1-2017. Теперь наши клиенты смогут размещать в облаке системы для обработки банковской тайны и проведения любых финансовых операций. Это поможет компаниям сэкономить время и деньги на создании и сертификации собственной инфраструктуры.

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

Анализ логов Object Storage при помощи DataLens
В Yandex.Cloud появился механизм логирования действий с бакетом в Object Storage. В блоге мы описали пример визуализации логов при помощи DataLens.

Иконки сервисов
По вашей просьбе мы выложили на сайт логотип Yandex.Cloud и иконки сервисов и элементы для создания архитектурных схем для инструментов Visio и Draw.io.

Подробнее Апрель
cloud.yandex.ru/blog/posts/2021/05/digest-april

Дайджест новостей платформы данных
cloud.yandex.ru/blog/posts/2021/06/mdb-digest

Платформа Yandex.Cloud прошла добровольную аттестацию на соответствие требованиям 152‑ФЗ



Yandex.Cloud прошла добровольную аттестацию информационных систем персональных данных (ИСПДн). Этим мы ещё раз подтвердили высокий уровень безопасности данных, размещённых в облаке, и дали нашим клиентам возможность аттестовать собственные системы.

Для подтверждения соблюдения федерального закона 152-ФЗ «О персональных данных» обычно достаточно заключения о соответствии, полученного в рамках самостоятельной оценки, либо с привлечением организации с лицензией ФСТЭК. В начале года платформа Yandex.Cloud прошла такой внешний аудит и подтвердила соответствие высшему уровню защищённости персональных данных — УЗ-1. Наши клиенты получили возможность обрабатывать в облаке любые категории персональных данных, включая биометрические и специальные (сведения о здоровье, вероисповедании, личных взглядах и другие чувствительные данные).
storage.yandexcloud.net/yc-compliance/conformance_ru_certificate.pdf

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

Разница между заключением о соответствии и аттестатом заключается в более строгом регулировании вопросов проведения аудита. Компания, оказывающая услуги по аттестации, в соответствии с приказом ФСТЭК РФ № 21 и постановлением Правительства России № 1119 должна иметь лицензию на осуществление деятельности по технической защите конфиденциальной информации и пройти процедуру аккредитации ФСТЭК России. Затем создаётся аттестационная комиссия, состоящая из экспертов и специалистов в области информационной безопасности, которая может проводить оценку соответствия организационных и технических мер, а также испытания технических и программных средств защиты персональных данных.

В результате добровольной аттестации платформа Yandex.Cloud ещё раз подтвердила высокий уровень безопасности данных, размещённых в облаке, и получила аттестат безопасности на 3 года.
cloud.yandex.ru/security#standards

Новости Биллинга: бюджеты и коннектор DataLens



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



Ещё одна новость: в Биллинге появилась интеграция с DataLens. Это простой и удобный способ понять, на что расходуются средства в облаке.

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

К существующим разрезам (облако, сервис и продукт) добавляются каталоги, ресурсы и метки. Это позволит находить ответы на такие вопросы, как:
  • на какую виртуальную машину уходит больше всего средств,
  • как распределяются затраты и потребление по проектам.
Актуальность данных близка к реальному времени. Вы можете выгрузить данные в CSV/XLSX и автоматически их обработать. Так, например, вы можете генерировать и рассылать счета клиентам.

Для того, чтобы воспользоваться новыми возможностями, создайте новое подключение DataLens с типом Yandex Cloud Billing.


Используйте предустановленный Yandex Cloud Billing Dashboard или настройте дашборд под свои запросы.


Подробная инструкция по работе с дашбордом в документации.
cloud.yandex.ru/docs/billing/operations/dashbord

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



Недавно Yandex.Cloud и Ernst & Young провели первое исследование применения облачных сервисов российскими компаниями. А также их мотивов и барьеров к внедрению.
yandex-cloud.vedomosti.ru

Сначала исследователи провели глубинные интервью с 15 руководителями крупных компаний из разных отраслей рынка. Полученные данные и гипотезы проверили и скорректировали с помощью опроса представителей более 700 российских компаний.

Компании изначально идут в облака под давлением рынка, а приходят к обновлению бизнес-процессов.
«Так, мы выявили, что возросшая потребность создавать цифровые продукты приводит компании к облаку как к более комплексному технологическому решению», — Антон Устименко, партнер EY.

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

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

Это подтверждают данные о том, кто инициирует применение облаков: в 48% опрошенных компаний инициатива была именно за бизнесом. В 24% компаний из исследования ответственность за «облачный» бюджет также уже перенесена на бизнес-подразделения.

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

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

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

Подробнее читайте в исследовании
forms.yandex.ru/surveys/10030087.6a61a6b656ef5862ba5bd663a929f4e27d381071/

Новые возможности интерфейса СУБД Yandex Database



Диагностика с помощью системных таблиц
Для проведения внутренней интроспекции состояния базы данных пользователи платформы с помощью нового веб-интерфейса могут осуществлять запросы в специальные системные таблицы (system views). Обращения выполняются с помощью YQL-запросов.

Анализ данных из системных таблиц позволяет выполнять диагностику по таблицам, запросам и данным БД:
  • получить информацию о размерах и нагрузке на партиции таблиц;
  • посмотреть топ долгих запросов, запросов с наибольшим потреблением CPU или читающих наибольшее количество данных;
  • посмотреть подробную информацию о выполняющихся запросах с одинаковым текстом.

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


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


Yandex Query Language (YQL)
Теперь при выполнении YQL-запроса можно посмотреть на результаты его исполнения, статистику выполнения, а также его EXPLAIN PLAN.


Навигация по базе данных
Мы переработали инструменты навигации по базе данных и добавили контекстные меню для всех объектов, с помощью которых вы можете:
  • скопировать полный путь к таблице, а затем вставить его в редактор YQL-запросов;
  • вызвать просмотр информации об объекте;
  • сформировать DML-запрос для записи;
  • сформировать DML-запрос для выборки данных;
  • удалить объект.


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

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

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


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

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

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


Мы улучшили предварительный просмотр таблиц: теперь доступно отображение столбцов с типом JSON и постраничное листание. И прямо из интерфейса вы можете добавить строку в таблицу, что очень удобно для экспериментов с данными.

Новости Yandex DataLens



Бесплатный тариф DataLens теперь доступен без привязки карты
Мы существенно упростили подключение Yandex DataLens для новых пользователей. Даже если у вас пока еще нет облака и платёжного аккаунта Yandex.Cloud, для быстрой визуализации данных вам достаточно:
  • Перейти на datalens.yandex.ru.
  • Указать аккаунт на Яндексе.
  • Активировать бесплатный тариф DataLens следуя инструкциям на стартовой странице.
Пользуясь бесплатным тарифом, вы можете полноценно работать с DataLens, настраивая подключения к собственным источникам данных.

Создание платежного аккаунта и привязка карты (или реквизитов вашего юридического лица) потребуются, если вам нужны:
  • платные продукты в маркетплейсе DataLens;
  • платный тариф «Стандарт» для DataLens и расширение лимита внешних сессий согласно тарифам;
  • другие сервисы Yandex.Cloud, включая управляемые базы данных для надежного хранения и обработки данных в облаке.
Google Sheets в качестве источника
Мы реализовали один из самых популярных запросов для DataLens в нашем сообществе. Теперь при создании нового подключения DataLens вы можете выбрать Google Sheets.


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

Особенности коннектора
  • Поддерживается полный набор функций DataLens.
  • На данный момент поддерживаются только документы с доступом по ссылке (доступ «Anyone with the link»).
  • Используется тот лист таблицы, который был указан в ссылке. Для указания конкретного листа необходимо скопировать ссылку из адресной строки, а не из управления доступом (содержит #gid=… в ссылке).
  • При загрузке используется кеш, время жизни — до 5 минут.
  • На данный момент используется представление данных листа через Google Charts — этим обусловлено определение имён колонок, обработка типов значений и представление других возможностей Google Sheets.
Коннектор к детализации биллинга вашего облака
Еще один новый тип подключения — детализация биллинга. Он позволяет анализировать детальные данные о потреблении облачных ресурсов (инфраструктурные сервисы, управляемые базы данных и другие платные сервисы).

К существующим разрезам, доступным в консоли Yandex.Cloud (это облако, сервис и продукт), добавлены данные по каталогам, ресурсам и меткам. А это, в свою очередь, позволяет делать расширенную ad-hoc аналитику по потреблению и находить ответы на такие вопросы, как:
  • на какую виртуальную машину уходит больше всего средств,
  • как распределяются затраты и потребление по проектам.
Актуальность данных близка к реальному времени. Вы можете выгрузить данные в CSV/XLSX и автоматически их обработать. Так, например, вы можете генерировать и рассылать счета клиентам.

Коннектор позволяет развернуть стандартный дашборд и доработать его под свои нужны. Для того, чтобы воспользоваться новыми возможностями, создайте новое подключение DataLens с типом Yandex Cloud Billing.

Иерархии и drill-down
Долгожданные иерархии с drill-down теперь в DataLens!
Создать и настроить иерархию можно в несколько кликов на уровне чарта, нажав на кнопку +.

Интерактивный пример встроенного чарта:


В качестве источника использовали документ Google Sheet.
  • Клик по строке в таблице — переход на уровень ниже с фильтрацией.
  • Путь над таблицей отображает сделанные переходы по узлам дерева.
  • Клик по значению, указанному в пути — возврат к выбранному уровню иерархии.
  • Клики по стрелкам — переход вниз/вверх по иерархии.
Цвет и размер шрифта в индикаторах
Для чартов типа индикатор теперь можно указать цвет шрифта из существующей палитры, а также выбрать один из 4 предустановленных размеров.


Несколько счетчиков при подключении к Яндекс.Метрике и AppMetrica
Теперь в режиме прямого доступа можно подключаться к нескольким счетчикам Яндекс Метрики и AppMetrica.

В датасетах Метрики появились измерения Счетчик и Счетчик (id) по которым можно группировать данные. Если вы давно создавали датасет и у вас нет таких полей, нажмите в датасете кнопку Обновить поля и сохраните его.


Подробнее
cloud.yandex.ru/blog/posts/2021/06/datalens-digest-june-2021

6 причин перейти на управляемый Kubernetes


Kubernetes можно установить на своем оборудовании, либо использовать managed-решение от облачного провайдера. При самостоятельной установке on-premise вы можете более гибко контролировать процесс настройки, но есть риск столкнуться с определенными сложностями.

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

В статье мы расскажем про шесть причин перейти на Yandex Managed Service for Kubernetes®, чтобы избежать сложностей развертывания и администрирования кластера Kubernetes on-premise. Заметим, что это не все преимущества, которые дает управляемый Kubernetes, а только самые значимые, на наш взгляд.

Легко установить и настроить кластер
Kubernetes — сложная система, для установки и настройки которой нужны определенные знания и навыки. Чтобы получить стабильную и безопасную систему, важно правильно установить и настроить кластер: права доступа, сетевые настройки, мониторинг, резервное копирование, файловое хранилище и многое другое.

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


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

Кластер создается в веб-интерфейсе несколькими кликами. Облачный провайдер выполнит за вас все основные настройки и интеграции, настроит резервное копирование, подключит мониторинг и настроит сеть.


Кроме UI-интерфейса Yandex.Cloud также предлагает возможность создания и управления кластером через API, CLI, SDK и Terraform. Главное преимущество такого способа — автоматизация рутинных задач по созданию и управлению ресурсами кластера. Облачный провайдер берет на себя большую часть задач по установке и настройке кластера, что ускоряет процесс развертывания и исключает необходимость иметь профильных специалистов в штате компании.

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

В Managed Service for Kubernetes облачный провайдер сам обновит ваш кластер. Мы предварительно тестируем новые версии Kubernetes и только после этого устанавливаем их на кластеры клиентов. Вам остается лишь проверить корректность работы сервисов и приложений в новой версии Kubernetes. Как клиент может контролировать процесс обновления:
  • Вы выбираете расписание установки обновления. Можно указать конкретные дни недели и время. Например, в ночь с пятницы на субботу, чтобы в случае непредвиденных ситуаций еще оставалось время до понедельника. При этом перед установкой обновления мы вас обязательно оповестим.
  • Вы можете отключить автообновление и устанавливать каждое обновление отдельно, по мере необходимости. Это полезно, когда нет возможности заранее выделить единое время для установки всех обновлений.

У Kubernetes есть три релизных канала для обновления:
  • Rapid. Содержит самые свежие версии Kubernetes. На канале часто появляются минорные обновления с новой функциональностью и улучшениями. Рекомендуем для непродуктивных сред — разработки и тестирования — потому что тут раньше всего появляется функционал, который скоро появится в продуктивном канале regular.
  • Regular. Хорошо протестированные версии. Сюда они попадают из канала rapid. Мы рекомендуем использовать канал для большинства продуктовых сред.
  • Stable. Самые стабильные версии, которые включают в основном исправления ошибок и проблем безопасности. Сюда они попадают из канала regular. Этот канал мы рекомендуем, если вы хотите как можно реже обновлять кластер. Например, в Kubernetes работают второстепенные приложения, которые не нужно постоянно дорабатывать и тестировать. Также этот канал подойдет, если у вас долгий цикл разработки приложений.


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

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

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

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

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

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


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

Работает с RBAC и IAM
Большие компании используют системы учетных записей, такие как Active Directory или G Suite. И для того чтобы интегрировать их с кластером Kubernetes, необходимо устанавливать и настраивать дополнительные инструменты.

В Managed Service for Kubernetes вы можете подключить систему и использовать свои учетные записи без дополнительных настроек. Для этого на уровне IAM настраивается федерация через протокол SAML. И тогда учетные записи ваших пользователей интегрируются с платформой Yandex.Cloud и им можно назначать роли.

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

разработчику из всех ресурсов платформы необходим доступ только к кластеру Kubernetes. Для этого внутри облака ему выдаются минимальные права, достаточные лишь для подключения к кластеру. А внутри Kubernetes при помощи RBAC ему добавляются необходимые полномочия на объекты кластера.

Удобный UI «из коробки»
У Kubernetes нет стандартного графического интерфейса управления. Существуют сторонние разработки от сообщества, которые нужно устанавливать, настраивать и предоставлять к ним доступ.

Мы разработали собственный интерфейс управления, доступный всем пользователям Managed Service for Kubernetes. Он уже интегрирован с Yandex IAM, что позволяет легко раздавать полномочия. Вы можете использовать наш дашборд вместо одного из сторонних или вместе с ним. Вот несколько его ключевых возможностей:
  • Детализация узлов, деплойментов, подов и сети. По каждому из этих объектов можно увидеть текущее состояние, посмотреть перечень событий и логов. Это позволяет отлаживать приложения без необходимости устанавливать дополнительные инструменты в кластер. Из детализации деплоймента можно увидеть, какие поды создались на его основе, и сразу перейти к ним.
  • Детализация потребления ресурсов. По каждому узлу или поду можно увидеть, сколько тратится CPU, памяти и сетевых ресурсов.
  • Настройка детализации. В каждой детализации можно добавлять или убирать поля для отображения.
  • Гибкий фильтр событий. В кластере генерируется довольно много событий, поэтому мы создали гибкий фильтр. Можно фильтровать по пространству имен, уровню или сущности.
Мы постоянно дорабатываем дашборд, поэтому в будущем у него появятся новые возможности. Нашим клиентам ничего не нужно устанавливать или обновлять, они сразу будут получать новые возможности.


Краткие итоги
Мы рассмотрели шесть главных преимуществ Managed Service for Kubernetes® перед классическими on‑premise‑кластерами Kubernetes.

Но это не все, что может предложить Yandex.Cloud для решения задач Kubernetes. С помощью платформы вы можете решать и другие задачи, например находить уязвимости в образах контейнеров, шифровать секреты в etcd‑хранилище или интегрироваться с инструментами CI/CD. Более подробно об этих и других возможностях вы можете узнать из нашего вебинара «Kubernetes. Managed на все 100%».

Эксперимент в облачном хранилище для повышения уровня выращивания чиа



Любой, кто обращает внимание на рынок жестких дисков так же внимательно, как Backblaze, уже знает все о быстром росте популярности Chia — «зеленой» альтернативы Биткойну — и о том, какое влияние она оказывает на мировые поставки жестких дисков. Если вы еще не слышали о Чиа, ознакомьтесь с краткой записью ниже, чтобы получить дополнительную информацию. Но этот пост предназначен для многих фермеров чиа, которые уже погрузились в сельское хозяйство и теперь сталкиваются с пустыми полками в поисках решений для хранения на своих участках.

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

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

Ключи к победе в испытаниях чиа
Участки Чиа не просто бездействуют. Сеть Chia регулярно выдает запросы на соответствие и проверки качества. Проверки качества важны для достижения успеха, но проблемы — когда каждые 512 участков проверяется каждые 10 минут — являются причиной того, что вы занимаетесь сельским хозяйством.

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

Это создает две проблемы, которые могут мешать вам спать по ночам, если вы пытаетесь фармить чиа:
  • Проблема 1: Где хранить участки в масштабе.
  • Учитывая, что текущее расчетное сетевое пространство, занятое участками Chia, составляет 20 эксабайт (и растет экспоненциально!), Случай показывает, что только один из ваших участков будет выигрывать примерно раз в 96 лет. Это все равно, что ждать всю жизнь кукурузного початка, а не весело. Итак, вы хотите иметь много участков, чтобы улучшить свои шансы, но вам нужно где-то их хранить, что вы можете себе позволить и которое может расти вместе с вашим сельским хозяйством.
  • Проблема 2: Управление сложностью масштабирования хранилища.
  • Если вы решите проблему хранения, вам также понадобится способ быстро и надежно сделать все графики доступными для чтения и быстрого представления в сети, когда вы выиграете испытание. Вам нужно будет уметь управлять этой сложностью каждую секунду каждый день, пока вы хотите быть фермером. Если вы ждете 96 лет, чтобы получить хоть один кукурузный початок, пропустить день сбора урожая было бы обидно.
Это ключи к победе в матче: достижение масштаба и умелое управление им.

Статус-кво: отдельные фермеры чиа используют жесткие диски для хранения
Для жесткого диска 7200 об / мин с задержкой чтения примерно 10 мс получение проверки качества или полной проверки занимает около 70 мс на подходящую диаграмму. Поскольку ядро ​​Chia кэширует первые семь операций чтения, жесткий диск должен выполнить только 64 поиска при выдаче запроса.

Если диск емкостью 18 ТБ, который может содержать 166 графиков по 108 ГБ на график (при k = 32), достаточно удачлив, чтобы содержать график, который является тем волшебным «одним из 512», жесткий диск достаточно быстро выполняет необходимые операции чтения, потому что Chia была разработана для использования жестких дисков для земледелия. Но жесткие диски могут выполнять только одну из этих операций за раз, поэтому рабочий стол должен выполнять операции последовательно. Даже если вы используете твердотельный накопитель, вам все равно придется выполнять операции последовательно. Опять же, это не проблема для отдельных дисков, поскольку жесткие диски и твердотельные накопители могут выполнять операции очень быстро в отведенное время.

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


Как использовать облачное хранилище для масштабирования участков
Программное обеспечение Chia не было разработано для ведения сельского хозяйства с использованием общедоступного облачного объектного хранилища, и первые тесты, которые мы провели на графиках Chia, хранящихся в облачном хранилище B2, подтвердили это: требуется несколько минут, а не 30 секунд, необходимых для своевременного прохождения проверки качества. В отличие от решения с локальным хранилищем, где данные проверки качества могут кэшироваться ядром, при настройке облачного хранилища производительность снижается до такой степени, что это влияет на вероятность успешного выполнения пользователями задач.

Backblaze B2 Cloud Storage предоставляет объектное хранилище, в котором данные хранятся в виде дискретных объектов, что исключает необходимость использования какой-либо вложенной или иерархической файловой структуры. Это делает B2 Cloud Storage идеальным для масштабирования и использования в качестве исходного хранилища, но как отдельный продукт хранилище объектов не подходит для хранения графиков Chia. Без оптимизации кэширования для повышения производительности и способа одновременного чтения графиков B2 Cloud Storage не смог бы эффективно служить в случае фермерского хозяйства Chia. Но B2 Cloud Storage спроектировано так, чтобы использовать преимущества параллельных операций или потоков, предлагая некоторые преимущества по сравнению со стандартным физическим диском, если они правильно настроены для этого варианта использования (кашля * я писал здесь про потоки! Кашля *).

Наша команда подумала, что было бы интересно создать инструмент, обеспечивающий обходной путь для варианта использования Chia, по четырем веским причинам:
  • Во-первых: потому что Backblaze Storage Cloud предоставляет оба ключа для успешного выращивания чиа: нет необходимости в выделении ресурсов, и фермеры из чиа могут загружать новые участки с высокой скоростью и масштабом. Backblaze Storage Cloud обслуживает почти 500 миллиардов файлов с исключительной надежностью и доступностью.
  • Во-вторых: стоимость хранения участков Chia в Backblaze B2 является привлекательной с финансовой точки зрения и составляет 5 долларов США за ТБ в месяц. Согласно Chia Calculator, использование облачного хранилища B2 для хранения участков было бы прибыльным, в зависимости от темпов роста сетевого пространства и текущей цены монеты Chia.
  • В-третьих: команда инженеров и инженеров Tiger, включая меня, думала, что это будет интересным и полезным (и увлекательным) экспериментом.
  • Наконец: та же команда считала, что мы могли бы включить Chia-сельское хозяйство участков, хранящихся в B2 Cloud Storage, взломав код того, как распараллеливать операции в Chia.
  • Помня об этом, наша команда Tiger приступила к работе. Инструмент для монтирования Backblaze B2 в качестве файловой системы был необходим, поскольку Chia изначально не поддерживает API Backblaze B2 Native или S3 Compatible. После некоторого тестирования наша команда остановилась на B2_fuse, поскольку наши инженеры, которые будут над этим работать, уже были знакомы с исходным кодом.

Выбрав B2_fuse, наши инженеры добавили алгоритм предварительной выборки для кэширования операций чтения, чтобы решить проблему ядра, упомянутую выше. Это улучшило бы производительность, но поскольку считывание с жесткого диска по-прежнему выполнялось по одному, оставалось место для дополнительных улучшений. Очевидно, что параллельное выполнение операций значительно повысило бы вероятность успеха, и после некоторых копаний один из наших инженеров нашел PR (запрос на вытягивание), который добавлял параллельное чтение и еще не был объединен в проект Chia.

Благодаря оптимизации кэширования в B2_fuse и добавленной функциональности параллельного чтения время проверки для графика Chia, хранящегося в облачном хранилище B2, сократилось до секунд. Это обеспечивает загрузку участков Chia в Backblaze B2 и их представление в сети Chia для ведения сельского хозяйства без необходимости использования дорогостоящего сервера в центре обработки данных.

Наши успешные тесты были проведены с использованием вычислительного экземпляра, работающего в регионе Запада США, с учетной записью Backblaze B2, который также находится в регионе Запада США. Попробуйте, и вы увидите целое поле метафорических культур — все готово к тому, когда придет вызов «один из 512».
Если вы хотите попробовать это решение, настройте учетную запись Backblaze B2 сейчас и получите обновленную версию B2_fuse (или внесите свой вклад в проект) вместе с инструкциями о том, как получить PR с параллельными чтениями здесь: github.com/Backblaze-B2-Samples/b2fs4chia

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