Хранилища данных *

Мы периодически тестируем новое оборудование и ПО для использования в наших сервисах. Всегда хочется больше возможностей за разумные деньги. Сегодня расскажу, как мы разбирались в устройстве Western Digital ActiveScale P100 и пытались примерить его под наше S3-хранилище.

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


Это ActiveScale P100 в апреле 2019 перед установкой в дата-центре OST.

Сейчас наш S3 работает на Cloudian HyperStore 7.1.5. Эта версия обеспечивает 98% совместимости с API Amazon. В нынешнем решении есть все необходимое для нас как сервис-провайдера и наших клиентов, поэтому в альтернативах мы искали никак не меньше.

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



По мнению экспертов Gartner, к 2020 году более 50% всех данных, генерируемых предприятиями, будут обрабатываться за пределами традиционных ЦОД или облачной среды (сегодня этот показатель составляет лишь 10%). В такой архитектуре будут работать 5,6 млрд устройств интернета вещей (IoT). При этом объёмы продуцируемых устройствами данных исчисляются терабайтами, а интерпретировать и анализировать их зачастую нужно в реальном времени.

Чтобы помочь партнёрам и клиентам изучить этот тренд, Seagate объединилась с консорциумом компаний, которые специализируются на периферийных вычислениях, и выпустила отчёт «Data at the Edge». В нём также использовались результаты исследования, проведённого IDC. Целью отчёта было проиллюстрировать некоторые проблемы с данными, которые сегодня актуальны для компаний, и показать, как компаниям лучше управлять своими ИТ-ресурсами.

Часть 1 Разворачиваем среду для работы с микросервисами. Часть 1 установка Kubernetes HA на bare metal (Debian)

Здравствуйте, уважаемые читатели Хабра!

В прошлой публикации я рассказал, как развернуть отказоустойчивый кластер Kubernetes. Но дело в том, что в Kubernetes удобно деплоить stateless приложения, которым не требуется сохранять свое состояние или работать с данными. Но в большинстве случаев нам требуются сохранять данные и не терять их при рестартах подов.
Для этих целей в Kubernetes используются тома (volume). Когда мы работаем с облачными решениями Kubernetes, то проблем особо нет. Нам лишь нужно у Google, Amazon или иного облачного провайдера заказать требуемый объем и, руководствуясь документаций , подключить полученные тома к подам.
Когда же мы имеем дело с bare metal, тут дела обстоят немного сложнее. Сегодня я хочу рассказать об одном из решений основанном на использовании ceph.

В данной публикации я расскажу:

• как развернуть распределенное хранилище Ceph
• как использовать Ceph при работе с Kubernetes

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

Раньше приложения «не помнили» ни действия, что выполняют сценарии, ни результаты вычислений, так что разработчики были вынуждены сохранять значения в сторонних сервисах или на своем бэкенде. Если вы когда-либо работали с local storage в браузере, то наша новая функциональность весьма похожа на это, т.к. позволяет приложениям запоминать пары «ключ-значение», которые уникальны для каждого приложения в вашем аккаунте. Работа хранилища стала возможна благодаря новому модулю ApplicationStorage – под катом вас ждет краткое руководство по его использованию, welcome!

Бывшая угольная шахта, в которой размещатся хранилище Arctic World Archive. Фото: Guy Martin / Bloomberg Businessweek

Свободное программное обеспечение — краеугольный камень современной цивилизации и общее наследие всего человечества. Миссия программы GitHub Archive — сохранить этот код для будущих поколений, чтобы история Александрийской библиотеки никогда не повторилась.

Для этого GitHub заведёт много резервных копий на разных носителях, в том числе долгосрочное хранилище Arctic Code Vault на Шпицбергене. Оно размещается в бывшей угольной шахте на глубине 250 метров в вечной мерзлоте и рассчитано на срок хранения минимум 1000 лет.

Снимок программного кода человечества сделают 2 февраля 2020 года.

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



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

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

ФЗ-152 «О защите персональных данных» распространяется на всех существующих субъектов: физических и юридических лиц, федеральные органы государственной власти и местного самоуправления. Фактически, этот закон распространяется на любые организации, обрабатывающие информацию и личные данные граждан РФ, независимо от формы собственности и размера организации.

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

Компания Rancher Labs, специализирующаяся на решениях и услугах для Kubernetes, объявила о передаче своего Open Source-хранилища для постоянных данных Longhorn в некоммерческую организацию CNCF, ответственную за развитие Kubernetes, Prometheus и ряда других проектов.

О проекте и его статусе

Longhorn был представлен в апреле 2017 года и называется распределённым блочным хранилищем для кластеров Kubernetes. Среди его главных особенностей — отказоустойчивость (нет единой точки отказа) и ориентированность на применение в enterprise, инкрементальные снапшоты, бэкапы на дополнительные хранилища (NFS или совместимые с S3), автоматизированные обновления без простоя в работе, простой в использовании GUI.

Всем привет!

Я уже рассказывал в этом блоге об организации модульной системы мониторинга для микросервисной архитектуры и о переходе с Graphite+Whisper на Graphite+ClickHouse для хранения метрик в условиях высоких нагрузок. После чего мой коллега Сергей Носков писал о самом первом звене нашей системы мониторинга — разработанном нами Bioyino, распределённом масштабируемом агрегаторе метрик.

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

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

Проблема разрозненного планирования

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

Эти планы имеют разные формат, разную степень детализации, и, что самое важное, разные и противоречащие друг другу цифры.

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

Выстраивание бизнес-процесса

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

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

(Часто используют термины: S&OP — Sales and Operations Planning, IBP — Integrated Business Planning).

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

Sonatype Nexus – платформа, с помощью которой разработчики могут проксировать, хранить и управлять зависимостями Java (Maven), образами Docker, Python, Ruby, NPM, Bower, RPM-пакетами, gitlfs, Apt, Go, Nuget, а также распространять свое программное обеспечение.

Зачем нужен Sonatype Nexus?

• Для хранения приватных артефактов;
• Для кеширования артефактов, которые скачиваются из интернета;

Привет, Хабр! Представляю вашему вниманию перевод поста Стивена Вольфрама "The Wolfram Function Repository: Launching an Open Platform for Extending the Wolfram Language".

Предпосылки состоятельности языка Wolfram

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

Вместо предисловия

или как так получилось, что появилась эта статья

в котором рассказывается, зачем и почему проводилось это тестирование

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

Масштаб сети Amazon Web Services — это 69 зон по всему миру в 22 регионах: США, Европа, Азия, Африка и Австралия. В каждой зоне находится до 8 ЦОД — Центров Обработки Данных. В каждом ЦОД тысячи или сотни тысяч серверов. Сеть построена так, что все маловероятные сценарии перебоев в работе принимаются в расчет. Например, все регионы изолированы друг от друга, а зоны доступности разнесены на расстояния в несколько километров. Даже если перерубить кабель, то система перейдет на резервные каналы, а потери информации составят единицы пакетов данных. О том, на каких еще принципах построена сеть и как она устроена, расскажет Василий Пантюхин.



Василий Пантюхин начинал Unix-админом в .ru-компаниях, 6 лет занимался большими железками Sun Microsystem, 11 лет проповедовал дата-центричность мира в EMC. Естественным путем эволюционировал в приватные облака, потом подался в публичные. Сейчас, как архитектор Amazon Web Services, техническими советами помогает жить и развиваться в облаке AWS.

В предыдущей части трилогии об устройстве AWS Василий углубился в устройство физических серверов и масштабирование базы данных. Nitro-карты, кастомный гипервизор на базе KVM, база данных Amazon Aurora — обо всем этом в материале «Как AWS «варит» свои эластичные сервисы. Масштабирование серверов и базы данных». Прочитайте, чтобы погрузиться в контекст, или посмотрите видеозапись выступления.

В этой части речь пойдет о масштабировании сети — одной из сложнейших систем в AWS. Эволюция от плоской сети к Virtual Private Cloud и ее устройство, внутренние сервисы Blackfoot и HyperPlane, проблема шумного соседа, а в конце — масштабы сети, backbone и физические кабели. Обо всем этом под катом.

Дисклеймер: всё, что ниже — личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.

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

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

Разделы:

• Алгоритмы и структуры данных. Ключевой раздел. Изучишь его — всё остальное тоже получится. Важно набить руку в написании кода и использовании основных структур и алгоритмов.
• Базы и хранилища данных, Business Intelligence. От алгоритмов переходим в хранению и обработке данных.
• Hadoop and Big Data. Когда база не входит на винчестер, или когда данные нужно анализировать, но Excel уже не может их загрузить начинаются большие данные. На мой взгляд, переходить к этому разделу нужно только после глубокого изучения двух предыдущих.

«Flying Cart», Afu Chan

Я работаю в Mail.ru Cloud Solutons архитектором и разработчиком, в том числе занимаюсь нашим облаком. Известно, что распределенной облачной инфраструктуре нужно производительное блочное хранилище, от которого зависит работа PaaS-сервисов и решений, построенных с их помощью.

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

Расскажу, как это было — возможно, эта история, проблемы, с которыми мы столкнулись, и наши решения будут полезны тем, кто тоже использует Ceph. Кстати, вот видеоверсия этого доклада.

Когда нет денег на железное хранилище от именитого вендора, или деньги есть, но негде взять железо для тестов, нам на помощь приходят Virtual Storage Appliance, или сокращённо — VSA. Виртуализированный контроллер столь желанного хранилища, позволяющий получить практически все функции своего железного собрата, кроме ну совсем уж экзотических и реализуемых только на физическом железе. VSA есть практически у всех (а может, и просто у всех) вендоров классических СХД: HPE, Dell EMC, NetApp, IBM и т.д. Бывают и обратные ситуации, вроде Nutanix и StarWind, но сегодня не о них. Для порядка не забудем открытые разработки во главе с FreeNAS, чей функционал вызывает уважение.

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

Сегодня мы рассмотрим работу с Dell EMC UnityVSA, начиная с первых шагов по развертыванию, включая создание файловой системы, настройки NAS и NDMP, а закончим интеграцией с Veeam Backup & Replication. Почему именно эта VSA? Просто потому что подобных материалов на Хабре я не нашёл и решил устранить эту несправедливость.

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



Облако AWS это мегасуперсложная система, которая эволюционно развивается с 2006 года. Часть этого развития застал Василий Пантюхин — архитектор Amazon Web Services. Как архитектор он видит изнутри не только конечный результат, но и сложности, которые преодолевает AWS. Чем больше понимания работы системы, тем больше доверия. Поэтому Василий поделится секретами облачных сервисов AWS. Под катом устройство физических серверов AWS, эластичная масштабируемость БД, кастомная база данных Amazon и методы повышения производительности виртуальных машин с одновременным уменьшением их цены. Знание архитектурных подходов Amazon поможет эффективнее использовать сервисы AWS и, возможно, даст новые идеи по построению собственных решений.

HPE InfoSight – облачный сервис НРЕ, позволяющий проактивно выявлять возможные проблемы с надёжностью и с производительностью массивов HPE Nimble и HPE 3PAR. При этом сервис может также сразу рекомендовать и способы устранения возможных проблем, причём в ряде случаев устранение проблем может выполняться проактивно, в автоматическом режиме.

Про HPE InfoSight мы уже рассказывали на HABR, см., например, здесь или здесь.

В этом посте я хочу рассказать об одной новой фиче HPE InfoSight — Планировщике ресурсов (Resource Planner).