Русский
Русский
English
Статистика
Реклама

Хранение данных

Утечка данных в Украине. Параллели с законодательством ЕС

23.07.2020 20:24:01 | Автор: admin


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

Украина стремится в ЕС, и это подразумевает принятие европейских стандартов защиты персональных данных.

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

В ЕС, в отличие от Украины, действует регламент по защите персональных данных GDPR.

Утечка свидетельствует о нарушениях принципов описанных в:
Статье 25 GDPR Защита персональных данных проектируемая и по умолчанию;
Статье 32 GDPR. Безопасность обработки;
Статье 5 п.1.f GDPR. Принцип целостности и конфиденциальности;

В ЕС штрафы за нарушение GDPR рассчитываются индивидуально, на практике оштрафовали бы на 200,000+ евро.

Что стоит изменить в Украине


Практика полученная в процессе сопровождения IT и онлайн бизнеса как в Украине, так и за пределами, показала проблемы и достижения GDPR.
Ниже шесть изменений которые стоит внедрить в Украинское законодательство.

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

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

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

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

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

Цитаты с первоисточника на украинском языке тут
  • вдомост про нацональнсть, освту, смейний стан, релгйн переконання, стан здоровя, адреса, дата та мсце народження (ч.2 ст. 11 Закону Украни Про нформацю);
    вдомост про мсце проживання (ч.8 ст. 6 Закону Украни Про свободу пересування та вльний вибр проживання в Укран);
  • вдомост про особисте життя громадян, одержан з звернень громадян (ст.10 Закону Украни Про звернення громадян);
  • вдомост про особисте життя громадян, одержан з звернень громадян (ст.10 Закону Украни Про звернення громадян);
  • первинн дан, отриман в процес проведення Перепису населення (ст. 16 Закону Украни Про Всеукранський перепис населення);
  • вдомост, що подаються заявником на визнання бженцем або особою, яка потребу додаткового захисту (ч.10 ст. 7 Закону Украни Про бженцв та осб, як потребують додаткового або тимчасового захисту);
  • нформаця про пенсйн внески, пенсйн виплати та нвестицйний прибуток (збиток), що облковуться на ндивдуальному пенсйному рахунку учасника пенсйного фонду, пенсйн депозитн рахунки фзичних осб, договори страхування довчно пенс (ч.3 ст. 53 Закону Украни Про недержавне пенсйне страхування);
  • нформаця про стан пенсйних активв, облкованих на накопичувальному пенсйному рахунку застраховано особи (ч.1 ст. 98 Закону Украни Про загальнообов'язкове державне пенсйне страхування);
  • вдомост щодо предмета договору на виконання науково-дослдних або дослдно-конструкторських та технологчних робт, хд х виконання та результати (ст. 895 Цивльного кодексу Украни)
  • нформаця яка може сприяти дентифкац особи неповнолтнього правопорушника або яка стосуться факту самогубства неповнолтнього (ч. 3 ст. 62 Закону Украни Про телебачення та радомовлення);
  • нформаця про померлого (ст. 7 Закону Украни Про поховання та похоронну справу);
    вдомост про оплату прац працвника (ст. 31 Закону Украни Про оплату прац Вдомост про оплату прац надаються лише у випадках передбачених законодавством, або за згодою чи на вимогу працвника);
  • заявки та матерали на видачу патентв ( ст.19 Закону Украни Про охорону прав на винаходи корисн модел);
  • вдомост, що мстяться в текстах судових ршень та дають можливсть дентифкувати фзичну особу, зокрема: мена (м'я, по батьков, прзвище) фзичних осб; мсце проживання або перебування фзичних осб з зазначенням адреси, номерв телефонв чи нших засобв звязку, адреси електронно пошти, дентифкацйних номерв (коди); рестрацйн номери транспортних засобв (ст. 7 Закону Украни Про доступ до судових ршень).
  • дан про особу взяту пд захист у кримнальному судочинств ( ст. 15 Закону Украни Про забезпечення безпеки осб, як беруть участь у кримнальному судочинств);
  • матерали заявки фзично чи юридично особи на рестрацю сорту рослин, результати експертизи сорту рослин (ст. 23 Закону Украни Про охорону прав на сорти рослин);
  • дан про працвника суду або правоохоронного органу, взятого пд захист (ст. 10 Закону Украни Про державний захист працвникв суду правоохоронних органв);
  • сукупнсть вдомостей про фзичних осб як постраждали вд насильства (персональн дан), що мстяться в Рестр, нформацю з обмеженим доступом. (ч.10 ст.16 Закону Украни Про запобгання та протидю домашньому насильству");
  • нформаця, що стосуться митно вартост товарв, що перемщаються через митний кордон Украни (ч.1 ст. 263 Митного кодексу Украни);
  • нформаця, що мститься в заяв про державну рестрацю лкарського засобу та додатка до них (ч.8 ст. 9 Закону Украни Про лкарськ засоби);


#Уйти от оценочных понятий
В GDPR много оценочных понятий. Оценочные понятия в стране без прецедентного права (имеется в виду Украина) скорее пространство для ухода от ответственности, чем польза для населения и страны в целом.

#Ввести понятие DPO
Data protection officer (DPO) независимый эксперт по защите данных. В законодательстве необходимо четко и без оценочных понятий регламентировать необходимость обязательного назначения эксперта на должность DPO. Как делают в Евросоюзе написано тут.

#Определить уровень ответственности за нарушение в сфере персональных данных, дифференцировать штрафы в зависимости от размера (прибыли) компании.

  • 34 тысячи гривен
    Культуры защиты персональных данных в Украине до сих пор нет, действующий Закон О защите персональных данных говорит что нарушение влечет за собой ответственность, установленную законом. Штраф по админ кодексу за незаконный доступ к персональным данным и за нарушение прав субъектов до 34,000 грн.
  • 20 миллионов евро
    Штраф за нарушение GDPR самый большой в мире до 20,000,000 евро, или до 4% от общего годового оборота компании за предыдущий финансовый год. Первый штраф в 50 миллионов евро за нарушения конфиденциальности данных, касающихся граждан Франции, получил Google.
  • 114 миллионов евро
    GDPR в мае праздновал 2-х летие и собрал 114 миллионов евро штрафов. Под прицелом у регуляторов чаще компании-гиганты с миллионами пользовательских данных.

    Гостиничной сети Marriott International и авиакомпании British Airways в этом году грозят многомиллионные штрафы за допущенные утечки данных, которые, по предварительным данным, опередят Google в бою за самые высокие штрафы. Регуляторы Великобритании предупредили, что планируют наказать их на общую сумму примерно в 366 миллионов долларов.
    Штрафы с шестью нулями выписываются глобальным компаниям, услугами которых пользуемся каждый день. Однако, это не говорит о том, что небольшие малознакомые компании не подпадают под наказания.
    Австрийская почтовая компания получила штраф в размере 18 миллионов евро за создание и продажу профилей 3 миллионов человек, в которых содержалась информация об адресах, личных предпочтениях и политической принадлежности.
    Платежный сервис в Литве не удалил персональные данные клиентов, когда нужда в обработке отпала и получил штраф 61,000 евро.
    Некоммерческая организация в Бельгии проводила прямую маркетинговую рассылку на электронную почту даже после того, как получатели отказался от получения рассылки, и получила штраф 1000 евро.
    1000 евро ничто по сравнению ущербом репутации.

#Не в штрафах щастье
Кто захочет узнать про меня инфу, и так узнает, несмотря на закон так говорят в Украине и странах СНГ, к сожалению, многие.
А вот в заблуждение насчет украдут фото паспорта и возьмут кредит на мое имя верит все меньше людей, ведь даже с оригиналом чужого паспорта в руках юридически это сделать нереально.

Люди делятся на 2 лагеря:
  • параноики которые верят в религию персональных данных, думают прежде чем поставить галочку и дать согласие на обработку данных.
  • те кому плевать, или люди которые на автомате сливают свои персональные данные в сеть, не задумывается о последствиях. А потом у них карточки кредитные воруют, подписывают на рекуррентные платежи, уводят аккаунты в мессенджерах, почты взламывают или снимают с кошелька криптовалюту.

Свобода и демократия


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

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

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

P.S. Пишу в соц. сетях про юриспруденцию и IT бизнес. Мне будет приятно, если подпишитесь на один из моих акаунтов. Это, безусловно, добавит мотивации развивать профиль и работать над контентом.

Facebook
Instagram
Подробнее..

Новый tech новая этика. Исследование отношения людей к технологиям и приватности

30.07.2020 12:15:48 | Автор: admin
Мы в коммуникационной группе Dentsu Aegis Network ежегодно проводим исследование Digital Society Index (DSI). Это наш глобальный ресерч в 22 странах мира, включая Россию, о цифровой экономики и ее влиянии на общество.

В этом году мы, конечно, не могли обойти стороной COVID-19 и решили посмотреть на то, как пандемия повлияла на цифровизацию. В итоге DSI 2020 вышел в двух частях: первая посвящена тому, как люди стали использовать и воспринимать технологии на фоне коронавирусных событий, вторая как они теперь относятся к приватности и оценивают уровень своей уязвимости. Делимся результатами нашего исследования и прогнозами.

image

Предыстория


Как один из крупнейших игроков digital и проводник технологий для брендов, группа Dentsu Aegis Network верит в важность развития цифровой экономики для всех (наш девиз digital economy for all). Для того, чтобы оценить ее текущее состояние с точки зрения удовлетворения социальных потребностей, в 2017 году на глобальном уровне мы инициировали проведение исследования Digital Society Index (DSI).

В 2018 году было опубликовано первое исследование. В нем мы впервые оценили цифровые экономики (тогда было 10 исследуемых стран и 20 тысяч респондентов) с точки зрения того, насколько обычные люди вовлечены в цифровые сервисы и позитивно настроены по отношению к digital-среде.

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

В 2019 году в связи с расширением выборки до 24 стран Россия опустилась на предпоследнее место в рэнкинге. А само исследование вышло под девизом Люди на первом месте (Human Needs in a Digital World), фокус сместился в сторону изучения удовлетворенности людей технологиями и цифрового доверия.

В рамках DSI 2019 мы выявили большую глобальную тенденцию люди стремятся вернуть цифровой контроль. Вот несколько триггерных в этом отношении цифр:
44% людей предприняли шаги по сокращению объема данных, которыми они делятся в интернете
27% установили программное обеспечение для блокировки рекламы
21% активно ограничивают количество времени, которое они проводят в интернете или у экрана смартфона,
а 14% удалили учетную запись в соцсети.

2020: техлэш или техлав?


Опрос DSI 2020 проводился в марте-апреле 2020 года, на которые пришелся пик пандемии и ограничительных мер по всему миру, среди 32 тысяч человек в 22 странах, включая Россию.

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

Техлав (techlove):
  • По сравнению с прошлым годом люди стали чаще использовать цифровые сервисы: почти три четверти опрошенных во всех странах (более 50% в России) заявили, что теперь активнее прибегают к банковским услугам и покупкам онлайн.
  • 29% респондентов (и в мире, и в России) признались, что именно технологии позволили им не потерять связь с семьей, друзьями и окружающим миром во время карантина. Еще столько же (среди россиян таких больше около 35%) отметили, что цифровые сервисы помогали расслабиться и отдохнуть, а также приобрести новые навыки и знания.
  • Сотрудники стали чаще использовать цифровые навыки в своей работе (это характерно почти для половины опрошенных в 2020 году против одной трети в 2018 году). На данный показатель мог повлиять массовый переход на дистанционный формат работы.
  • Люди стали больше верить в способность технологий решать социальные проблемы, такие как вызовы COVID-19 для здравоохранения и других сфер. Доля оптимистов в отношении значимости технологий для общества выросла до 54% против 45% в 2019 году (в России аналогичная динамика).

Техлэш (techlash):
  • 57% людей на глобальном уровне (53% в России) по-прежнему считают, что темпы технологических изменений слишком быстрые (показатель практически не изменился с 2018 года). Как следствие, они стремятся к цифровому балансу: почти половина респондентов (и в мире, и в нашей стране) намерены выделять время на отдых от гаджетов.
  • 35% людей, как и в прошлом году, отмечают негативное влияние цифровых технологий на здоровье и благополучие. Заметен разрыв между странами в этом вопросе: наибольшую обеспокоенность высказывают в Китае (64%), более оптимистично настроены в России (только 22%) и Венгрии (20%). Помимо прочего респонденты указывают, что технологии заставляют их чувствовать себя более напряженными, им становится труднее отключиться от digital (13% в мире и 9% в России).
  • Только 36% в мире верят, что новые технологии, такие как искусственный интеллект и робототехника, будут создавать рабочие места в будущем. Россияне более пессимистичны в этом вопросе (среди них таких 23%).
  • Около половины опрошенных, как и годом ранее, уверены в том, что цифровые технологии увеличивают неравенство между богатыми и бедными. Отношение россиян к данной проблеме также остается неизменным, но в нашей стране аналогичного мнения придерживаются только 30%. В качестве примера можно привести использование мобильного интернета и цифровых сервисов. Покрытие и качество интернет-услуг респонденты оценивают гораздо выше, чем их доступность для всего населения (см. график в начале статьи).

Прайваси дизрапшн


Итак, результаты первой части демонстрируют, что пандемия ускорила цифровую революцию. Логично, что с ростом онлайн-активности увеличился объем данных, которым делятся пользователи. И (спойлер) их это сильно беспокоит:

  • Меньше половины опрошенных в мире (и только 19% в России самый низкий показатель на опрошенных рынках) верят, что компании защищают конфиденциальность их персональных данных.
  • 8 из 10 потребителей как на глобальном уровне, так и в нашей стране, готовы отказаться от услуг компании, если узнают, что их персональные данные были использованы неэтично.

Далеко не все считают, что бизнесу приемлемо использовать все разнообразие персональных данных для улучшения своих продуктов и сервисов. На использование даже самой базовой информации, такой как адрес электронной почты, согласны 45% в мире и 44% в России.
Данными о просмотренных интернет-страницах готовы делиться 21% потребителей на глобальном уровне, информацией из профилей социальных сетей 17%. Интересно, что россияне более открыты в предоставлении доступа к истории браузера (25%). В то же время социальные сети воспринимаются ими как более приватное пространство отдавать эти данные сторонним организациям хотят только 13%.

image

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

image

image

Негативное отношение людей к вопросам сохранения приватности идет вразрез с их реальным поведением в сети. И это более чем парадоксально:
  • Люди не уверены в добросовестности использования их персональных данных, но все чаще делятся ими, больше и активнее используя цифровые сервисы.
  • Большинство пользователей не хотят делиться персональными данными, но все равно делают это (часто не отдавая себе отчета).
  • Люди требуют, чтобы компании в явном виде запрашивали у них разрешение на использование персональных данных, однако практически не читают пользовательские соглашения.
  • Потребители ожидают персонализацию в продуктах и услугах, но к персонализированной рекламе настроены более осторожно.
  • Пользователи стремятся вернуть себе цифровой контроль, но верят, что в перспективе преимущества digital-сервисов, вероятнее всего, перевесят возможные риски.
  • Технологии во благо обществу главный запрос потребителей на перспективу.

О будущем


По мере роста использования цифровых продуктов, например, для работы и диагностики здоровья, объем персональных данных продолжит увеличиваться, вызывая опасения относительно прав и возможностей по их защите.
Мы видим несколько сценариев развития ситуации от создания этических регуляторов и специальных надзорных корпоративных политик (central control) до партнерства компаний и пользователей в монетизации персональных данных (free for all).

image

Заглядывая на 2-3 года вперед, почти половина опрошенных нами потребителей хочет получать финансовую выгоду в обмен на свои персональные данные. Пока это, пожалуй, футурология: за последний год только 1 из 10 пользователей на глобальном уровне продал свои персональные данные. Хотя в Австрии о таких кейсах заявила четверть респондентов.
Что еще важно для тех, кто создает цифровые продукты и сервисы:
  • 66% людей в мире (49% в России) ожидают, что компании будут использовать технологии во благо обществу в ближайшие 5-10 лет.
  • Прежде всего, это касается развития продуктов и услуг, которые улучшают здоровье и благополучие такие ожидания разделяют 63% потребителей на глобальном уровне (52% в России).
  • Несмотря на то, что потребители обеспокоены этической стороной использования новых технологий (например, распознавание лиц), почти половина респондентов в мире (52% в России) готовы оплачивать продукты и услуги, используя системы Face-ID или Touch-ID.


image

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

Сжатие видео на пальцах как работают современные кодеки?

30.07.2020 00:17:36 | Автор: admin


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

Для большей наглядности начнем с цифр. Пускай видеозапись будет вестись непрерывно, в разрешении Full HD (сейчас это уже необходимый минимум, во всяком случае, если вы хотите полноценно использовать функции видеоаналитики) и в режиме реального времени (то есть, с фреймрейтом 25 кадров в секунду). Предположим также, что выбранное нами оборудование поддерживает аппаратное кодирование H.265. В этом случае при разных настройках качества изображения (высоком, среднем и низком) мы получим примерно следующие результаты.

Кодек


Интенсивность движения в кадре


Использование дискового пространства за сутки, ГБ


H.265 (Высокое качество)


Высокая


138


H.265 (Высокое качество)


Средняя


67


H.265 (Высокое качество)


Низкая


41


H.265 (Среднее качество)


Высокая


86


H.265 (Среднее качество)


Средняя


42


H.265 (Среднее качество)


Низкая


26


H.265 (Низкое качество)


Высокая


81


H.265 (Низкое качество)


Средняя


39


H.265 (Низкое качество)


Низкая


24



Но если бы сжатия видео не существовало в принципе, мы бы увидели совсем иные цифры. Попробуем разобраться, почему. Видеопоток представляет собой не что иное, как последовательность статичных картинок (кадров) в определенном разрешении. Технически каждый кадр является двумерным массивом, содержащим информацию об элементарных единицах (пикселях), формирующих изображение. В системе TrueColor для кодирования каждого пикселя требуется 3 байта. Таким образом, в приведенном примере мы бы получили битрейт:

19201080253/1048576 = ~148 Мб/с

Учитывая, что в сутках 86400 секунд, цифры выходят поистине астрономические:

14886400/1024=12487 ГБ

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

К счастью, современные алгоритмы сжатия видео помогают существенно экономить дисковое пространство: так, использование кодека H.265 позволяет сократить объем видео в 90 (!) раз. Добиться столь впечатляющих результатов удалось благодаря целому стеку разнообразных технологий, которые давно и успешно применяются не только в сфере видеонаблюдения, но и в гражданском секторе: в системах аналогового и цифрового телевидения, в любительской и профессиональной съемке, и многих других ситуациях.

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

А вот со снижением детализации все оказывается уже совсем не так однозначно. Технически квантование (то есть, разбиение диапазона сигнала на некоторое число уровней с последующим их приведением к заданным значениям) работает великолепно: используя данный метод, размер видео можно многократно уменьшить. Но так мы можем упустить важные детали (например, номер проезжающего вдалеке автомобиля или черты лица злоумышленника): они окажутся смазаны и такая запись будет для нас бесполезной. Как же поступить в этой ситуации? Ответ прост, как и все гениальное: стоит взять за точку отсчета динамические объекты, как все тут же становится на свои места. Этот принцип успешно используется со времен появления кодека H.264 и отлично себя зарекомендовал, открыв ряд дополнительных возможностей для сжатия данных.

Это было предсказуемо: разбираемся, как H.264 сжимает видео


Вернемся к таблице, с которой мы начали. Как видите, помимо таких параметров, как разрешение, фреймрейт и качество картинки решающим фактором, определяющим конечный размер видео, оказывается уровень динамичности снимаемой сцены. Это объясняется особенностями работы современных видеокодеков вообще, и H.264 в частности: используемый в нем механизм предсказания кадров позволяет дополнительно сжимать видео, при этом практически не жертвуя качеством картинки. Давайте посмотрим, как это работает.

Кодек H.264 использует несколько типов кадров:

  • I-кадры (от английского Intra-coded frames, их также принято называть опорными или ключевыми) содержат информацию о статичных объектах, не меняющихся на протяжении длительного времени.
  • P-кадры (Predicted frames, предсказанные кадры, также именуемые разностными) несут в себе данные об участках сцены, претерпевших изменения по сравнению с предыдущим кадром, а также ссылки на соответствующие I-кадры.
  • B-кадры (Bi-predicted frames, или двунаправленные предсказанные кадры) в отличие от P-кадров, могут ссылаться на I-, P- и даже другие B-кадры, причем как на предыдущие, так и на последующие.

Что это означает? В кодеке H.264 построение видеоизображения идет следующим образом: камера делает опорный кадр (I-кадр) и уже на его основе (поэтому он и называется опорным) производит вычитание из кадра неподвижных частей изображения. Таким образом создается P-кадр. Затем из этого второго кадра вычитается третий и также создается P-кадр с изменениями. Так формируется серия разностных кадров, которые содержат только изменения между двумя последовательными кадрами. В результате мы получаем такую цепочку:

[НАЧАЛО СЪЕМКИ] I-P-P-P-P-P-P-P-P-P-P-P-P-P- ...

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

-P-P-P-P-P-P-P-I-P-P-P-P-P-P-P ...

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


Независимая обработка статических и динамических объектов позволяет сэкономить дисковое пространство

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


Кодек формирует кадры, предсказывая, куда будет двигаться объект

В свою очередь, использование двунаправленных предсказанных кадров позволяет в несколько раз сократить время доступа к каждому кадру в потоке, поскольку для его получения будет достаточно распаковать только три кадра: B, содержащий ссылки, а также I и P, на которые он ссылается. В данном случае цепочку кадров можно изобразить следующим образом.

[НАЧАЛО СЪЕМКИ] I-B-P-B-P-B-P-B-P-B-P-B-P-B-P-B-P-

Такой подход позволяет существенно повысить скорость быстрой перемотки с показом и упростить работу с видеоархивом.

В чем разница между H.264 и H.265?




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

Так, обновленная версия кодека стала использовать макроблоки дерева кодирования (Coding Tree Unit, CTU) переменного размера с разрешением до 6464 пикселей, тогда как ранее максимальный размер такого блока составлял лишь 1616 пикселей. Это позволило существенно повысить точность выделения динамических блоков, а также эффективность обработки кадров в разрешении 4K и выше.

Кроме того, H.265 обзавелся улучшенным deblocking filter фильтром, отвечающим за сглаживание границ блоков, необходимым для устранения артефактов по линии их стыковки. Наконец, улучшенный алгоритм прогнозирования вектора движения (Motion Vector Predictor, MVP) помог заметно снизить объем видео за счет радикального повышения точности предсказаний при кодировании движущихся объектов, чего удалось достичь за счет увеличения количества отслеживаемых направлений: если ранее учитывалось лишь 8 векторов, то теперь 36.

Помимо всего перечисленного выше, в H.265 была улучшена поддержка многопоточных вычислений: квадратные области, на которые разбивается каждый кадр при кодировании, теперь могут обрабатываться независимо одна от другой. Появилась и поддержка волновой параллельной обработки данных (Wavefront Parallelel Processing, WPP), что также способствует повышению производительности сжатия. При активации режима WPP обработка CTU осуществляется построчно, слева направо, однако кодирование каждой последующей строки может начаться еще до завершения предыдущей в том случае, если данных, полученных из ранее обработанных CTU, для этого достаточно. Кодирование различных строк CTU с временной задержкой со сдвигом, наряду с поддержкой расширенного набора инструкций AVX/AVX2 позволяет дополнительно повысить скорость обработки видеопотока в многоядерных и многопроцессорных системах.

Флэш-карты для видеонаблюдения: когда значение имеет не только размер


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

13830/1024 = 4

По нынешним меркам 4 терабайта для винчестера индустриального класса практически ничто: современные жесткие диски для видеонаблюдения имеют емкость до 14 терабайт и могут похвастаться рабочим ресурсом до 360 ТБ в год при MTBF до 1.5 миллионов часов. Что же касается карт памяти, то здесь все оказывается не так однозначно.

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

Как видно из нашей таблицы, даже при низком качестве изображения и при условии минимальной активности в кадре, всего за сутки будет записано около 24 ГБ видео. А это значит, что 128-гигабайтная карточка будет полностью перезаписана менее чем за неделю. Если же нам требуется получать максимально качественную картинку, то все данные на таком носителе будут полностью обновляться раз в сутки! И это лишь при разрешении Full HD. А если нам понадобится картинка в 4K? В этом случае нагрузка вырастет практически в два раза (в заданных условиях видео в максимальном качестве потребует уже 250 ГБ).

При бытовом использовании подобное попросту невозможно, поэтому даже самая бюджетная карта памяти способна прослужить вам несколько лет к ряду без единого сбоя. А все благодаря алгоритмам выравнивания износа (wear leveling). Схематично их работу можно описать следующим образом. Пусть в нашем распоряжении есть новенькая флеш-карта, только что из магазина. Мы записали на нее несколько видеороликов, использовав 7 из 16 гигабайт. Через некоторое время мы удалили часть ненужных видео, освободив 3 гигабайта, и записали новые, объем которых составил 2 ГБ. Казалось бы, можно задействовать только что освободившееся место, однако механизм выравнивания износа выделит под новые данные ту часть памяти, которая ранее никогда не использовалась. Хотя современные контроллеры тасуют биты и байты куда более изощренно, общий принцип остается неизменным.



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

Нетрудно догадаться, что wear leveling перестает играть хоть сколько-нибудь значимую роль в том случае, если флэш-карта постоянно перезаписывается целиком: здесь на первый план уже выходит выносливость самих чипов. Наиболее объективным критерием оценки последней является максимальное количество циклов программирования/стирания (program/erase cycle), или, сокращенно, циклов P/E, которое способно выдержать флеш-память. Также достаточно точным и в данном случае наглядным (так как мы можем заранее рассчитать объемы перезаписи) показателем является коэффициент TBW (Terabytes Written). Если в технических характеристиках указан лишь один из перечисленных показателей, то вычислить другой не составит особого труда. Достаточно воспользоваться следующей формулой:

TBW = (Емкость Количество циклов P/E)/1000

Так, например, TBW флеш-карты емкостью 128 гигабайт, ресурс которой составляет 200 P/E, будет равен: (128 200)/1000 = 25,6 TBW.

Давайте считать дальше. Выносливость карт памяти потребительского уровня составляет 100300 P/E, и 300 это в самом лучшем случае. Опираясь на эти цифры, мы можем с достаточно высокой точностью оценить срок их службы. Воспользуемся формулой и заполним новую таблицу для карты памяти емкостью 128 ГБ. Возьмем за ориентир максимальное качество картинки в Full HD, то есть в сутки камера будет записывать 138 ГБ видео, как мы выяснили ранее.

Ресурс карты памяти, циклов P/E


TBW


Время наработки на отказ


100


12,8


3 месяца


200


25,6


6 месяцев


300


38,4


1 год



Хотите использовать карты на 64 ГБ или писать видео в 4K? Смело делите рассчитанные сроки на два: в среднем потребительские карты памяти придется менять раз в полгода, причем в каждой камере. То есть каждые 6 месяцев вам придется закупать новую партию флеш-карт, нести дополнительные расходы на сервисное обслуживание и, конечно же, подвергать опасности охраняемый объект, так как камеры придется выводить из эксплуатации на время замены.

Наконец, еще один момент, на который следует обратить пристальное внимание при выборе карты памяти, ее скоростные характеристики. В описании практически всех современных флеш-карт можно встретить запись вида: Производительность: до 100 МБ/с при чтении, до 90 МБ/с при записи; запись видео: C10, U1, V10. Здесь C10 и U1 означают не что иное, как класс скорости записи видео, причем если заглянуть в справочные материалы, то классам C10, U1 и V10 соответствует 10 МБ/с. Откуда разница в 9 раз и почему маркировка тройная? На самом деле все достаточно просто.

В рассмотренном примере 100 и 90 МБ/с это номинальная скорость, то есть максимально достижимая производительность карты в операциях последовательного чтения и записи при условии использования с совместимым оборудованием, которое само по себе обладает достаточной производительностью. А показатели C10, U1 и V1 (10 МБ/с) это минимальная устойчивая скорость передачи данных в наихудших условиях тестирования. Данный параметр необходимо учитывать при выборе карт для камер видеонаблюдения по той простой причине, что если он окажется ниже битрейта видеопотока, то это чревато появлением на записи графических артефактов и даже выпадением целых кадров. Очевидно, что в случае с охранными системами подобное недопустимо: любые дефекты картинки чреваты потерей критически важных данных например, улик, которые могли бы помочь при поимке злоумышленника.

Что же касается наличия сразу трех маркировок, то причины этого сугубо исторические. C10 относится к самой первой из созданных SD Card Association классификаций, которая была составлена еще в 2006 году, получив простое и незамысловатое название Speed Class. Появление классификации UHS Speed Class, на которую указывает маркировка U1, связано с созданием интерфейса Ultra High Speed, который сегодня используется в подавляющем большинстве флеш-карт. Наконец, последняя классификация, Video Speed Class (V1), была разработана SD Card Association в 2016-м в связи с распространением устройств, поддерживающих запись видео сверхвысоких разрешений (4K, 8K и 3D).

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

Speed Class


UHS Speed Class


Video Speed Class


Минимальная устойчивая скорость записи


Разрешение видео


C2




2 МБ/с


Запись видео стандартного разрешения (SD, 720 на 576 пикселей)


C4




4 МБ/с


Запись видео высокой четкости (HD), включая Full HD (от 720p до 1080p/1080i)


C6



V6


6 МБ/с


C10


U1


V10


10 МБ/с


Запись видео Full HD (1080p) с фреймрейтом 60кадров в секунду



U3


V30


30 МБ/с


Запись видео с разрешением до 4K и фреймрейтом 60/120 кадров в секунду




V60


60 МБ/с


Запись видеофайлов с разрешением 8K и фреймрейтом 60/120 кадров в секунду




V90


90 МБ/с



Следует учитывать, что приведенные в таблице соответствия актуальны для любительских, полупрофессиональных и профессиональных видеокамер. В отрасли видеонаблюдения, где запись в реальном времени ведется с максимальной частотой 25 кадров в секунду, а для сжатия видеопотока применяются высокоэффективные кодеки H.264 и H.265, задействующие кодирование с предсказанием, в подавляющем большинстве случаев будет достаточно карт памяти, соответствующих классу U1/V10, так как битрейт в таких условиях практически никогда не превышает порог в 10 МБ/с.

Карты памяти WD Purple microSD для систем видеонаблюдения




С учетом всех перечисленных особенностей компания Western Digital разработала специализированную серию карт памяти WD Purple microSD, которая на данный момент включает в себя две продуктовые линейки: WD Purple QD102 и WD Purple SC QD312 Extreme Endurance. В первую вошли четыре накопителя объемом от 32 до 512 ГБ, во вторую три модели, на 64, 128 и 256 ГБ. По сравнению с потребительскими решениями, WD Purple были специально адаптированы под современные цифровые системы видеонаблюдения за счет внедрения ряда важных усовершенствований.

Главным преимуществом пурпурной серии является существенно больший по сравнению с бытовыми устройствами рабочий ресурс: карты линейки QD102 способны выдержать 1000 циклов программирования/стирания, тогда как QD312 уже 3000 циклов P/E, что позволяет многократно продлить срок их службы даже в режиме круглосуточной записи, и делает данные карточки идеально подходящими для эксплуатации на особо охраняемых объектах, где запись ведется в режиме 24/7. В свою очередь, соответствие классам скорости UHS Speed Class 1 и Video Speed Class 10 позволяет использовать карты WD Purple в камерах высокого разрешения, в том числе для записи в режиме реального времени.

Помимо этого, карты памяти WD Purple имеют и ряд других важных особенностей, о которых необходимо упомянуть:

  • влагостойкость (изделие способно выдержать погружение на глубину до 1 метра в пресную или соленую воду) и расширенный диапазон рабочих температур (от -25C до +85C) позволяют одинаково эффективно использовать карты WD Purple для оснащения как внутридомовых, так и уличных устройств видеофиксации независимо от погодных и климатических условий;
  • защита от воздействия статических магнитных полей с индукцией до 5000 Гс и устойчивость к сильной вибрации и ударам вплоть до 500 g полностью исключают вероятность утраты критически важных данных даже в случае повреждения видеокамеры;
  • функция удаленного мониторинга помогает оперативно отслеживать состояние каждой карты и эффективнее планировать проведение сервисных работ, а значит, дополнительно повысить надежность охранной инфраструктуры.

Для большей наглядности мы подготовили для вас сравнительную таблицу, в которой приведены основные характеристики карт памяти WD Purple.

Серия


WD Purple QD102


WD Purple QD312


Объем, ГБ


32


64


128


256


512


64


128


256


Форм-


фактор


microSDHC


microSDXC


Производи-тельность



До 100 МБ/с в операциях последовательного чтения,


до 65 МБ/с в операциях последовательной записи


Скоростной класс


U1/V10


Ресурс записи (P/E)



1000



3000


Ресурс записи (TBW)



32



64



128



256



512



192



384



768


Диапазон рабочих температур



От -25 C до 85 C


Гарантия


3 года


Подробнее..

СХД Qsan в системах видеонаблюдения

14.07.2020 10:11:05 | Автор: admin

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




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


От использования DVR (такие маленькие коробочки, совмещающие в себе софт видеонаблюдения и один или несколько HDD для хранения результатов) сейчас уже почти отказались из-за проблем с масштабированием по производительности, количеству камер и емкости. Поэтому в качестве хранилища выступает либо набор дисков, расположенных внутри сервера, либо внешняя СХД с файловым или блочным доступом.


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


  • Объем
  • Производительность
  • Надежность

Объем определяется из количества камер и их типа (считай, разрешения и применяемым ими кодеком), а также глубиной хранения. Любые вменяемые производители камер, а уж тем более вендоры ПО по работе с ними, имеют в открытом доступе калькуляторы для расчета необходимой емкости в зависимости от ваших потребностей. Но в любом случае даже скромный десяток камер с временем хранения в две недели затребует нескольких ТБ дискового пространства. С ростом количества камер и глубины архива потребность в хранилище легко может идти на сотни ТБ и даже ПБ.


С производительностью несколько сложнее. Более 95% времени на хранилище осуществляется запись данных в последовательном режиме (т.е. в максимально комфортном для накопителей). Вместе с тем, периодически происходит поиск по индексной базе и воспроизведение материала. Конечно же на показатель производительности напрямую влияет количество и тип камер. Но современный софт давно научился кэшировать входящие потоки на стороне сервера прежде всего с целью индексации событий и объектов, попавших в объективы камер. Поэтому непосредственная запись на устройство хранения осуществляется крупными порциями по несколько ГБ. Отсюда и требования к хранилищу по части скорости записи относительно невелики: лишь бы успеть записать подготовленный материал за то время, пока набирается следующий. Однако итоговая производительность должна учитывать конкурентные запросы на поиск и воспроизведение, из-за чего массив должен содержать в себе достаточное количество HDD для этого.


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


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


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


Если сравнивать между собой файловые и блочные протоколы доступа к СХД в контексте систем видеонаблюдения, то SAN системы будут иметь ряд преимуществ из-за более простой и потому более дешевой реализации системы хранения. Ведь чисто блочным СХД не требуются сверхмощное железо и продвинутые возможности встроенной ОС. Функционал типа дедупликации или тиринга будет бессилен перед сжатым видео, которое перезаписывается по кругу. Все это в конечном итоге положительно скажется на стоимости решения, разумеется, в пользу SAN.


Практические советы по построению систем видеонаблюдения


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


Если масштаб системы видеонаблюдения таков, что достаточно 1-2 серверов по обработке потоков, то абсолютно нерентабельно использовать в данной конфигурации внешние СХД (кроме случаев с требованиями к повышенной отказоустойчивости). Достаточно использовать внутренние RAID контроллеры и диски. При большем количестве серверов наличие СХД как раз, наоборот, позволит снизить стоимость решения за счет консолидации дисковых ресурсов.


При планировании построения дискового пространства в СХД стоит отказаться от желания сделать один большой массив на все случаи жизни из-за потенциальных проблем с производительностью и надежностью:


  • Производительность в RAID массивах хоть и масштабируется с увеличением количества HDD в группе, но постоянная конкурентная запись видеопотоков от множества серверов не всегда позволит получать требуемые скоростные показатели для каждого из них. Разумным решением будет создание отдельных RAID массивов для групп из 2-4 серверов.
  • С точки зрения надежности, при использовании HDD большой емкости необходимо использовать как минимум RAID6 с количеством дисков в группе не более 12-14. В случае использования большего числа дисков необходимо объединять такие группы в RAID60. Также следует учитывать, что, при постоянной записи на массив, ребилд для диска емкостью 10-14ТБ легко может занять 2 и более недели. И различные технологии ускорения вроде Fast Rebuild здесь, увы, не помогут. Если позволяют бюджеты, то для повышения надежности все же стоит рассматривать RAID10.

Интерфейс подключения СХД к серверам не играет большой роли с точки зрения производительности. Поэтому чаще всего используется максимально бюджетный вариант с iSCSI. Более того, в случае прямого подключения сервера к СХД вполне достаточно даже скорости 1GbE, благо дополнительные карты расширения с таким интерфейсом для СХД Qsan стоят дешевле портов 10GbE на коммутаторах. Но если подключение происходит все же с использованием коммутатора(ов), то 10GbE, конечно же, является предпочтительным.


В случае использования двухконтроллерных моделей СХД следует учитывать, что на стороне серверов должна быть поддержка MPIO. Акцент на этом моменте сделан не случайно: достаточно часто с целью удешевления на стороне видеосерверов используются клиентские версии ОС (Windows 7-10 и т.п.), которые не могут работать с MPIO.


Также не следует забывать, что блочный доступ подразумевает монопольное использование дискового ресурса конкретным сервером (кроме случаев кластеризации видеосерверов в виртуальных средах). Поэтому необходимо обязательно со стороны СХД настроить контроль доступа к публикуемым томам при помощи LUN Masking. В случае плановой или аварийной замены видеосервера будет достаточно изменить параметры LUN Masking для продолжения работы.


Если рассматривать выбор конкретной СХД для целей видеонаблюдения, то на эту роль вполне подойдут младшие модели (например, серию XCubeSAN XS12xx), поскольку предполагается работа с обычными HDD, latency которых просто несоизмеримы с производительностью контроллеров. При большом количестве дисков особенно выигрышно будут смотреться конфигурации с использованием полок высокой плотности сторонних производителей, благо Qsan официально поддерживает подобное. Переход на старшие линейки СХД оправдан лишь в тех случаях, когда суммарная потоковая запись на СХД предполагается выше, чем 3 ГБ/с, что характерно для очень больших инсталляций с несколькими десятками видеосерверов.


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

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

08.07.2020 14:22:16 | Автор: admin


Так выглядит избыточность.


Коды избыточности* широко применяются в компьютерных системах для увеличения надёжности хранения данных. В Яндексе их используют в очень многих проектах. Например, применение кодов избыточности вместо репликации в нашем внутреннем объектном хранилище экономит миллионы без снижения надёжности. Но несмотря на широкое распространение, понятное описание того, как работают коды избыточности, встречается очень редко. Желающие разобраться сталкиваются примерно со следующим (из Википедии):



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


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


* В англоязычной литературе коды избыточности часто называют erasure codes.


1. Суть кодов избыточности


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


В большинстве* кодов избыточности данные разбиваются на n блоков данных, для них считается m блоков кодов избыточности, всего получается n + m блоков. Коды избыточности строятся таким образом, чтобы можно было восстановить n блоков данных, используя только часть из n + m блоков. Далее мы рассмотрим только блочные коды избыточности, то есть такие, в которых данные разбиваются на блоки.



Чтобы восстановить все n блоков данных, нужно иметь минимум n из n + m блоков, так как нельзя получить n блоков, имея только n-1 блок (в этом случае пришлось бы 1 блок брать из воздуха). Достаточно ли n произвольных блоков из n + m блоков для восстановления всех данных? Это зависит от типа кодов избыточности, например коды Рида Соломона позволяют восстановить все данные с помощью произвольных n блоков, а коды избыточности LRC не всегда.


Хранение данных


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


Передача данных


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


* Есть также коды избыточности, в которых данные не разбиваются на блоки, например коды Хэмминга и коды CRC, широко применяемые для передачи данных в сетях Ethernet. Это коды для помехоустойчивого кодирования, они предназначены для обнаружения ошибок, а не для их исправления (код Хэмминга также позволяет частично исправлять ошибки).


2. Коды Рида Соломона


Коды Рида Соломона одни из наиболее широко распространённых кодов избыточности, изобретённые ещё в 1960-х и впервые получившие широкое применение в 1980-х для серийного выпуска компакт-дисков.


Ключевых вопросов для понимания кодов Рида Соломона два: 1) как создавать блоки кодов избыточности; 2) как восстанавливать данные с помощью блоков кодов избыточности. Найдем на них ответы.
Для упрощения далее будем считать, что n=6 и m=4. Другие схемы рассматриваются по аналогии.


Как создавать блоки кодов избыточности


Каждый блок кодов избыточности считается независимо от остальных. Для подсчёта каждого блока используются все n блоков данных. На схеме ниже X1-X6 блоки данных, P1P4 блоки кодов избыточности.



Все блоки данных должны быть одинакового размера, для выравнивания можно использовать нулевые биты. Полученные блоки кодов избыточности будут иметь тот же размер, что и блоки данных. Все блоки данных разбиваются на слова (например, по 16 бит). Допустим, мы разбили блоки данных на k слов. Тогда все блоки кодов избыточности тоже будут разбиты на k слов.



Для подсчёта i-го слова каждого блока избыточности будут использоваться i-е слова всех блоков данных. Они будут считаться по следующей формуле:



Здесь значения x слова блоков данных, p слова блоков кодов избыточности, все альфа, бета, гамма и дельта специальным образом подобранные числа, одинаковые для всех i. Сразу нужно сказать, что все эти значения не обычные числа, а элементы поля Галуа, операции +, -, *, / не привычные всем нам операции, а специальные операции, введённые над элементами поля Галуа.


Зачем нужны поля Галуа



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


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

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


Такие специальные числа давно изучает математика, их называют полями. Поле это множество элементов с определёнными для них операциями сложения, вычитания, умножения и деления.


Поля Галуа* это поля, для которых существует и единственен результат каждой операции (+, -, *, /) для любых двух элементов поля. Поля Галуа можно построить для чисел, являющихся степенью 2: 2, 4, 8, 16 и т. д. (на самом деле степенью любого простого числа p, но на практике нас интересуют только степени 2). Например, для слов размером 16 бит это поле, содержащее 65 536 элементов, для каждой пары которых можно найти результат любой операции (+, -, *, /). Значения x, p, альфа, бета, гамма, дельта из уравнений выше для расчётов будут считаться элементами поля Галуа.


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


* Это не строгое определение, скорее описание.


Как восстанавливать данные


Восстановление нужно тогда, когда из n + m блоков часть блоков отсутствует. Это могут быть как блоки данных, так и блоки кодов избыточности. Отсутствие блоков данных и/или блоков кодов избыточности будет означать, что в уравнениях выше неизвестны соответствующие переменные x и/или p.


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


Например, пусть блоки данных 1, 2, 3 и блок кодов избыточности 2 недоступны, тогда для i-й группы слов будет следующая система уравнений (неизвестные отмечены красным):



Мы имеем систему из 4 уравнений с 4 неизвестными, значит можем решить её и восстановить данные!


Из этой системы уравнений следуют ряд выводов про восстановление данных для кодов Рида Соломона (n блоков данных, m блоков кодов избыточности):


  • Данные можно восстановить при потере любых m блоков или меньше. При потере m+1 и более блоков данные восстановить нельзя: нельзя решить систему из m уравнений с m + 1 неизвестными.
  • Для восстановления даже одного блока данных нужно использовать любые n из оставшихся блоков, при этом можно использовать любой из кодов избыточности.

Что ещё нужно знать


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


  • Система уравнений для кодов Рида Соломона должна иметь (единственное) решение при любых комбинациях неизвестных (не более m неизвестных). Исходя из этого требования подбираются значения альфа, бета, гамма и дельта.
  • Систему уравнений нужно уметь автоматически строить (в зависимости от того, какие блоки недоступны) и решать.
  • Нужно построить поле Галуа: для заданного размера слова уметь находить результат любой операции (+, -, *, /) для любых двух элементов.

В конце статьи есть ссылки на литературу по этим важным вопросам.


Выбор n и m


Как на практике выбрать n и m? На практике в системах хранения данных коды избыточности используют для экономии места, поэтому m выбирают всегда меньше n. Их конкретные значения зависят от ряда факторов, в том числе:


  • Надёжность хранения данных. Чем больше m, тем большее количество отказов дисков можно пережить, то есть выше надёжность.
  • Избыточность хранения. Чем выше соотношение m / n, тем выше будет избыточность хранения, и тем дороже будет стоить система.
  • Время обработки запросов. Чем больше сумма n + m, тем дольше будет время ответа на запросы. Так как для чтения данных (во время восстановления) нужно прочитать n блоков, хранящихся на n разных дисках, то время чтения будет определяться самым медленным диском.

Кроме того, хранение данных в нескольких ДЦ накладывает дополнительные ограничения на выбор n и m: при отключении 1 ДЦ данные всё ещё должны быть доступны для чтения. Например, при хранении данных в 3 ДЦ должно выполняться условие: m >= n/2, в противном случае возможна ситуация, когда данные недоступны для чтения при отключении 1 ДЦ.


3. LRC Local Reconstruction Codes


Для восстановления данных с помощью кодов Рида Соломона приходится использовать n произвольных блоков данных. Это очень существенный минус для распредёленных систем хранения данных, ведь для восстановления данных на одном сломанном диске придётся читать данные с большинства остальных, создавая большую дополнительную нагрузку на диски и сеть.


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


LRC (Local Reconstruction Codes) коды избыточности, придуманные в Microsoft для применения в Windows Azure Storage. Идея LRC максимально проста: разбить все блоки данных на две (или более) группы и считать часть блоков кодов избыточности для каждой группы по отдельности. Тогда часть блоков кодов избыточности будет подсчитана с помощью всех блоков данных (в LRC они называются глобальными кодами избыточности), а часть с помощью одной из двух групп блоков данных (они называются локальными кодами избыточности).


LRC обозначается тремя числам: n-r-l, где n количество блоков данных, r количество глобальных блоков кодов избыточности, l количество локальных блоков кодов избыточности. Для чтения данных при недоступности одного блока данных нужно прочитать только n/l блоков это в l раз меньше, чем в кодах Рида Соломона.


Для примера рассмотрим схему LRC 6-2-2. X1X6 6 блоков данных, P1, P2 2 глобальных блока избыточности, P3, P4 2 локальных блока избыточности.



Блоки кодов избыточности P1, P2 считаются с помощью всех блоков данных. Блок кодов избыточности P3 с помощью блоков данных X1X3, блок кодов избыточности P4 с помощью блоков данных X4X6.


Остальное делается в LRC по аналогии с кодами Рида Соломона. Уравнения для подсчёта слов блоков кодов избыточности будут такими:



Для подбора чисел альфа, бета, гамма, дельта нужно выполнить ряд условий, гарантирующих возможность восстановления данных (то есть решения системы уравнения). Подробнее о них можно прочитать в статье.
Также на практике для подсчёта локальных кодов избыточности P3, P4 применяют операцию XOR.


Из системы уравнений для LRC следует ряд выводов:


  • Для восстановления любого 1 блока данных достаточно прочитать n/l блоков (n/2 в нашем примере).
  • Если недоступно r + l блоков, и при этом все блоки входят в одну группу, то данные восстановить нельзя. Это легко объяснить на примере. Пусть недоступны блоки X1X3 и P3: это r + l блоков из одной группы, 4 в нашем случае. Тогда у нас есть система из 3 уравнений с 4 неизвестными, которую нельзя решить.
  • Во всех остальных случаях недоступности r + l блоков (когда из каждой группы доступен хотя бы один блок) данные в LRC можно восстановить.

Таким образом, LRC выигрывает у кодов Рида Соломона в восстановлении данных после одиночных ошибок. В кодах Рида Соломона для восстановления даже одного блока данных нужно использовать n блоков, а в LRC для восстановления одного блока данных достаточно использовать n/l блоков (n/2 в нашем примере). С другой стороны, LRC проигрывает кодам Рида Соломона по максимальному количеству допустимых ошибок. В примерах выше коды Рида Соломона могут восстановить данные при любых 4 ошибках, а для LRC существует 2 комбинации из 4 ошибок, когда данные восстановить нельзя.


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


4. Другие коды избыточности


Помимо кодов Рида Соломона и LRC, есть много других кодов избыточности. Разные коды избыточности используют разную математику. Вот некоторые другие коды избыточности:


  • Код избыточности с помощью оператора XOR. Операция XOR выполняется над n блоками данных, и получается 1 блок кодов избыточности, то есть схема n+1 (n блоков данных, 1 код избыточности). Используется в RAID 5, где блоки данных и кодов избыточности циклически записываются на все диски массива.
  • Алгоритм even-odd, основанный на операции XOR. Позволяет построить 2 блока кодов избыточности, то есть схема n+2.
  • Алгоритм STAR, основанный на операции XOR. Позволяет построить 3 блока кодов избыточности, то есть схема n+3.
  • Pyramide codes ещё одни коды избыточности от Microsoft.

5. Использование в Яндексе


Ряд инфраструктурных проектов Яндекса применяет коды избыточности для надёжного хранения данных. Вот несколько примеров:


  • Внутреннее объектное хранилище MDS, о котором я писал в начале статьи.
  • YT MapReduce-система Яндекса.
  • YDB (Yandex DataBase) распределённая база данных newSQL.

В MDS используются коды избыточности LRC, схема 8-2-2. Данные с кодами избыточности пишутся на 12 разных дисков в разных серверах в 3 разных ДЦ: по 4 сервера в каждом ДЦ. Подробнее об этом читайте в статье.


В YT используются как коды Рида Соломона (схема 6-3), которые были реализованы первыми, так и коды избыточности LRC (схема 12-2-2), причём LRC предпочтительный способ хранения.


В YDB используются коды избыточности, основанные на even-odd (схема 4-2). Про коды избыточности в YDB уже рассказывали на Highload.


Применение разных схем кодов избыточности обусловлено разными требованиями, предъявляемыми к системам. Например, в MDS данные, хранимые с помощью LRC, размещаются сразу в 3 ДЦ. Нам важно, чтобы данные оставались доступными для чтения при выходе из строя 1 любого ДЦ, поэтому блоки должны быть распределены по ДЦ так, чтобы при недоступности любого ДЦ количество недоступных блоков было не больше допустимого. В схеме 8-2-2 можно разместить по 4 блока в каждом ДЦ, тогда при отключении любого ДЦ будет недоступно 4 блока, и данные можно будет читать. Какую бы схему мы ни выбрали при размещении в 3 ДЦ, в любом случае должно быть (r + l) / n >= 0,5, то есть избыточность хранения будет минимум 50%.


В YT ситуация другая: каждый кластер YT целиком располагается в 1 ДЦ (разные кластеры в разных ДЦ), поэтому там нет такого ограничения. Схема 12-2-2 даёт избыточность 33%, то есть хранить данные выходит дешевле, при этом они также могут переживать до 4 одновременных отключений дисков, как и схема в MDS.


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


6. Ссылки


  1. Серия статей про коды Рида Соломона и поля Галуа: http://personeltest.ru/aways/habr.com/ru/company/yadro/blog/336286/
    http://personeltest.ru/aways/habr.com/ru/company/yadro/blog/341506/
    В них доступным языком глубже рассматривается математика.
  2. Статья от Microsoft про LRC: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/LRC12-cheng20webpage.pdf
    В разделе 2 кратко объясняется теория, далее рассматривается опыт применения LRC на практике.
  3. Схема even-odd: https://people.eecs.berkeley.edu/~kubitron/courses/cs262a-F12/handouts/papers/p245-blaum.pdf
  4. Схема STAR: https://www.usenix.org/legacy/event/fast05/tech/full_papers/huang/huang.pdf
  5. Pyramid codes: https://www.microsoft.com/en-us/research/publication/pyramid-codes-flexible-schemes-to-trade-space-for-access-efficiency-in-reliable-data-storage-systems/
  6. Коды избыточности в MDS: http://personeltest.ru/aways/habr.com/ru/company/yandex/blog/311806
  7. Коды избыточности в YT: http://personeltest.ru/aways/habr.com/ru/company/yandex/blog/311104/
  8. Коды избыточности в YDB: https://www.youtube.com/watch?v=dCpfGJ35kK8
Подробнее..

Перевод Как написать собственную файловую систему на языке Rust

29.07.2020 14:20:10 | Автор: admin
Исходные данные и результаты работы программ должны где-то храниться для дальнейшего использования. Их хранение нужно организовать так, чтобы мы могли быстро получить нужную информацию. За эту задачу отвечает Файловая система (FS): она предоставляет абстракцию для устройств, на которых физически хранятся данные.

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



Файловая система и диск


Когда данные нужно сохранить на жестком диске (HDD) или твёрдотельном накопителе (SSD), они записываются небольшими секторами (или страницами в случае SSD). Диски не знают о том, что представляет собой тот или иной фрагмент данных. Диск всего лишь хранит массив секторов. А управлять и взаимодействовать с ними должна файловая система.

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

На следующем рисунке приведен пример того, как файловая система структурирует информацию на диске:



Далее мы разберёмся, какие бывают типы блоков.

Суперблоки и битовые карты (bitmaps)


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

Битовые карты являются одним из способов отслеживания того, какие блоки данных и индексные дескрипторы (иноды) являются свободными. Каждому сектору в файловой системе соответствует один бит карты. Если сектор занят, то значение соответствующего бита в битовой карте устанавливается в 1, если свободен в 0.

Инод


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

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



Для каждого сектора в битовой карте инодов с индексом, установленным в 1, в таблице будет соответствующий инод. Индекс сектора совпадает с индексом в таблице.

Блоки данных


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

Указатели на блоки данных


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



Чтобы получить представление о максимальном размере файла для каждого уровня, давайте возьмём фиксированный размер блока в 4 КиБ. Большинство файлов имеют небольшой размер, поэтому 12 прямых указателей позволят хранить файлы размером до 48 КиБ. Учитывая, что каждый указатель занимает 4 байта, один косвенный указатель позволит увеличить размер файла до 4 МиБ:

(12 + 1024) * 4 KiB

С введением двойных косвенных указателей размер файла вырастает до 4 ГиБ:

(12 + 1024 + 1024<sup>2</sup>) * 4 KiB

С добавлением тройных косвенных указателей мы получаем 4 TиБ:

(12 + 1024 + 1024<sup>2</sup> + 1024<sup>3</sup>) * 4 KiB

Поэтому такой подход может быть не очень эффективным для обработки больших файлов.

Например, файл размером 100 МБ потребует 25600 блоков. В случае фрагментации блоков на диске производительность может сильно пострадать.

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

Каталоги


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

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

Чтение и запись


Чтение


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

Запись


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

Моя файловая система (GotenksFS)


Я некоторое время изучал язык Rust и решил написать на нём свою собственную файловую систему. Я во многом опирался на ext4, а также использовал FUSE, свободный модуль для ядер UNIX-подобных ОС. Вместо диска я использовал обычный файл. Размер блока можно выставить в 1 КиБ, 2 КиБ или 4 КиБ. Файлы могут иметь размер до 4 ГиБ для блоков размером 4 КиБ. Потенциально файловая система может занимать до 16 ТиБ.

Начинаем


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

$ ./gotenksfs mkfs disk.img -s "10 GiB" -b 4096

После выполнения команды создаётся образ с общим размером 10 ГиБ, а каждый блок в файловой системе имеет размер 4 КиБ.

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

Монтирование


После создания образа нам нужно смонтировать его, чтобы мы могли начать его использовать. Для этого используем команду mount:

$ ./gotenksfs mount disk.img gotenks



Основные структуры


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

pub struct Superblock {    pub magic: u32,    pub block_size: u32,    pub created_at: u64,    pub modified_at: Option<u64>,    pub last_mounted_at: Option<u64>,    pub block_count: u32,    pub inode_count: u32,    pub free_blocks: u32,    pub free_inodes: u32,    pub groups: u32,    pub data_blocks_per_group: u32,    pub uid: u32,    pub gid: u32,    pub checksum: u32,}

Следующие два блока это битовые карты для данных и для инода. Для таблицы инодов используется набор из n блоков. А в последующие блоки будут записываться пользовательские данные.

Инод я сформировал так:

pub struct Inode {    pub mode: libc::mode_t,    pub hard_links: u16,    pub user_id: libc::uid_t,    pub group_id: libc::gid_t,    pub block_count: u32, // should be in 512 bytes blocks    pub size: u64,    pub created_at: u64,    pub accessed_at: Option<i64>,    pub modified_at: Option<i64>,    pub changed_at: Option<i64>,    pub direct_blocks: [u32; DIRECT_POINTERS as usize],    pub indirect_block: u32,    pub double_indirect_block: u32,    pub checksum: u32,}

Я реализовал поддержку двойных косвенных указателей то есть, для диска с размером блока 4 КиБ максимальная ёмкость файла составит 4 ГиБ. Количество прямых указателей я ограничил двенадцатью:

pub const DIRECT_POINTERS: u64 = 12;

При первом запуске FS она создаёт корневой каталог:

pub struct Directory {    pub entries: BTreeMap<OsString, u32>,    checksum: u32,}

Формируем группы блоков


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

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



Реализуем чтение и запись


Когда наш диск создан, можно заняться файловыми операциями. Создадим новый каталог с помощью mkdir:



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

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

Аргументами функции записи служат путь, буфер с данными, смещение и структура с информацией о файле, которая может содержать дескриптор файла вместе с другой, дополнительной, информацией о нём:

fn write(&mut self, path: &Path, buf: &[u8], offset: u64, file_info: &mut fuse_rs::fs::WriteFileInfo)


В этом случае вместо повторного обхода пути для поиска инода система использует дескриптор файла (FS предварительно инициализирует его при создании файла). И тогда FS сможет собрать структуру, вычислив точный адрес инода:

fn inode_offsets(&self, index: u32) -> (u64, u64) {    let inodes_per_group = self.superblock().data_blocks_per_group as u64;    let inode_bg = (index as u64 - 1) / inodes_per_group;    let bitmap_index = (index as u64 - 1) & (inodes_per_group - 1);    (inode_bg, bitmap_index)}fn inode_seek_position(&self, index: u32) -> u64 {    let (group_index, bitmap_index) = self.inode_offsets(index);    let block_size = self.superblock().block_size;    group_index * util::block_group_size(block_size)        + 2 * block_size as u64        + bitmap_index * INODE_SIZE        + SUPERBLOCK_SIZE}

Теперь, когда FS имеет информацию о том, какие блоки данных выделены для инода, она может использовать их для поиска точного адреса, чтобы записать туда данные. Новые блоки сначала добавляются в массив прямых указателей, и если размер файла превышает (12 * BLOCK_SIZE), FS выдаёт косвенный указатель (поле indirect_block). Для очень больших файлов система добавляет двойной косвенный указатель, используя поле double_indirect_block. Чтение из файла реализуется аналогично.

Ниже вы можете увидеть, как у меня работают чтение и запись:



Вывод


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

Важный момент реализация косвенных указателей для хранения больших файлов. Если вам интересно узнать о файловых системах больше, я бы рекомендовал почитать о таких вещах, как журналирование, копирование при записи (Copy-On-Write), Лог-структурированные файловые системы.

Код для моего проекта файловой системы GotenksFS находится по адресу https://github.com/carlosgaldino/gotenksfs



На правах рекламы


Эпичные серверы это надёжные серверы на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрой файловой системой, используем исключительно NVMe диски от Intel. Попробуйте как можно быстрее!

Подробнее..

Что лучше Oracle или Redis или Как обосновать выбор платформы

09.07.2020 10:15:09 | Автор: admin
Это ж надо, ни к кому не обращаясь, громко сказала она. Это ж надо! Так прямо и написано главной задачей общества является извлечение прибыли винтересах акционеров. Ну вы подумайте! Ничего не боятся!

Юлий Дубов, Меньшее зло


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



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

Мотивация


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

Естественно, хочется заплатить поменьше, а получить побольше. Однако необходимо решить, что важнее меньше заплатить или больше получить, и приписать каждому узлу вес. Допустим, что нам важнее качественное решение, чем дешёвое, и припишем узлу Стоимость вес 40%, а узлу Возможности 60%.



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

Отсекающие условия


Сайту db-engines.com известно около 500 систем управления базами данных. Естественно, если выбирать целевую платформу из такого количества вариантов, то может получиться обзорная статья, но не коммерческий проект. Для того, чтобы сократить пространство выбора, формулируются отсекающие критерии, и если платформа этим критериям не удовлетворяет, то она не рассматривается.

Отсекающие критерии могут относиться к технологическим особенностям, например:
  • ACID-гарантии;
  • реляционная модель данных;
  • поддержка языка SQL (обратите внимание, это не то же самое, что реляционная модель);
  • возможность горизонтального масштабирования.

Могут быть критерии общего характера:
  • наличие коммерческой поддержки в России;
  • открытый исходный код;
  • наличие платформы в Реестре Минкомсвязи;
  • наличие платформы в каком-нибудь рейтинге (например, в первой сотне рейтинга db-engines.com);
  • наличие экспертов на рынке (например, по результатам поиска названия платформы врезюме на сайте hh.ru).

В конце концов, могут быть критерии, специфичные для предприятия:
  • наличие специалистов в штате;
  • совместимость с системой мониторинга X или с системой резервного копирования Y, накоторую завязано всё сопровождение...

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

Оценка стоимости


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

Если системы примерно одного класса (например, MicrosoftSQLServer и PostgreSQL), то для простоты можно считать, что количество оборудования для того и другого решения будет примерно одинаковым. Это позволит не оценивать оборудование, сэкономив тем самым массу времени и сил. Если же приходится сравнивать совершенно разные системы (скажем, Oracle vs. Redis), то очевидно, что для корректной оценки необходимо сделать сайзинг (расчёт количества оборудования). Сайзинг несуществующей системы занятие весьма неблагодарное, поэтому такого сравнения всё же стараются недопускать. Сделать это просто: в отсекающих условиях пишутся нулевая потеря данных и реляционная модель или же наоборот нагрузка от 50 тысяч транзакций в секунду.

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

У разных вендоров могут быть разные метрики лицензирования: по количеству ядер, объёму данных или количеству узлов. Standby-база может быть бесплатной, а может лицензироваться так же, как и основная. Если только обнаружились какие-то различия в метриках, придётся детально описывать модельный стенд и считать стоимость лицензий для стенда.

Важный момент для корректного сравнения одинаковые условия поддержки. Скажем, поддержка Oracle стоит 22% от стоимости лицензии вгод, а за поддержку PostgreSQL можно неплатить. Корректно ли так сравнивать? Нет, потому что у ошибки, которая не может быть устранена собственными силами, совершенно разные последствия: в первом случае специалисты поддержки быстро помогут её устранить, а во втором случае есть риск задержки проекта или простоя готовой системы втечение неопределённого срока.

Уравнять условия расчёта можно тремя способами:
  1. Использовать Oracle без поддержки (в реальности такого не бывает).
  2. Купить поддержку на PostgreSQL например, у компании Postgres Professional.
  3. Заложить в расчёт риски, связанные с отсутствием поддержки.

Например, расчёт рисков может выглядеть так: в случае неустранимого сбоя базы данных простой системы составит 1 рабочий день. Планируемая прибыль от использования системы 40млрд монгольских тугриков в год, частота аварий оценивается как 1/400, таким образом, риск отсутствия сопровождения оценивается примерно в 100 млн монгольских тугриков в год. Очевидно, что планируемая прибыль и оценочная частота аварий величины виртуальные, но гораздо лучше иметь такую модель, чем не иметь никакой.

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

Допустим, что после всех расчётов стоимость эксплуатации платформы A в течение 5 лет оказалась 800 млн монгольских тугриков, стоимость эксплуатации платформы B 650млн тугриков, а стоимость эксплуатации платформы C 600млн тугриков. Платформа C как победитель получает за стоимость полновесный балл, а платформы A и B чуть меньше, пропорционально тому, во сколько раз они дороже. В данном случае 0.75и 0.92баллов соответственно.

Оценка возможностей


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

К функциям разработки можно отнести:
  • удобство манипуляции данными;
  • масштабирование;
  • наличие вторичных индексов.

Список критериев, как и их веса, очень субъективны. Даже при решении одной и той же задачи эти списки, веса пунктов и ответы будут существенно отличаться в зависимости от состава вашей команды. Так, например, Facebook для хранения данных использует MySQL, а Instagram построен на базе Cassandra. Вряд ли разработчики этих приложений заполняли такие таблицы. Можно лишь догадываться, что Марк Цукерберг выбрал полноценную реляционную модель, заплатив за это необходимостью прикладного шардирования, в то время как Кевин Систром заложил масштабирование средствами платформы, пожертвовав удобством доступа к данным.

К функциям администрирования относятся:
  • возможности системы резервного копирования;
  • удобство мониторинга;
  • удобство управления мощностями дисками и узлами;
  • возможности репликации данных.

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

Инструмент Комментарий Оценка
imp/exp Выгрузка и загрузка данных 0.1
begin/end backup Копирование файлов 0.3
RMAN Возможность инкрементального копирования 0.7
ZDLRA Только инкрементальное копирование, быстрейшее восстановление на точку 1.0

Если чёткие критерии оценки отсутствуют, имеет смысл попросить нескольких экспертов выставить оценки, а затем их усреднить.

Наконец, просто перечислим функции информационной безопасности:
  • наличие политик управления паролями;
  • возможность подключения внешних средств аутентификации (LDAP, Kerberos);
  • ролевая модель доступа;
  • возможности аудита;
  • шифрование данных на диске;
  • шифрование при передаче по сети (TLS);
  • защита данных от администратора.


Тестирование производительности


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

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

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

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

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

Результат


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



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

Энергоэффективность хранения данных спиновые моменты, намагниченности и эффект Холла

08.07.2020 10:20:45 | Автор: admin


Когда-то день начинался с чашечки кофе и утренней газеты. В наши дни любовь к кофе по утрам не утратила свою релевантность, а вот бумажные новостные издания были вытеснены смартфонами, планшетами и прочими гаджетами, подключенными к интернету. И в этом нет ничего плохого, ведь всемирная паутина позволяет нам получать информацию и общаться с людьми из разных уголков мира. С каждым днем объем данных, генерируемых в мире, неустанно увеличивается. Каждая статья, фото и даже твит из двух слов все это является частью огромного и вечно растущего информационного поля Земли. Но эти данные не эфирны, они не витают в облаках, а где-то хранятся. Местом хранения данных служат и наши гаджеты, и специализированные учреждения дата-центры. Здания, наполненные под завязку серверами, ожидаемо потребляют уйму энергии. Логично, что с увеличением мирового объема данных будет увеличиваться и объем потребляемой энергии. Сегодня мы с вами познакомимся с исследованием, в котором ученые из Майнцского университета (Германия) разработали новую методику записи данных на сервера, которая в теории может уменьшить энергопотребление в два раза. Какие физические и химические процессы задействованы в разработке, что показали эксперименты, и настолько ли велик потенциал данного труда, как о том говорят его авторы? Об этом мы узнаем из доклада ученых. Поехали.

Основа исследования


Корнем всего исследования является спинтроника наука, изучающая спиновый токоперенос. Спин в свою очередь это собственный момент импульса элементарной частицы. За последние годы интерес к спинтронике сильно возрос, что позволило открыть немало нового, в том числе и переключение тока с помощью спин-орбитальных моментов (SOT от spin-orbit torque) в магниторезистивных запоминающих устройств с произвольным доступом (MRAM).

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

SOT-индуцированное переключение реализуется в бислоях ферромагнетик-тяжелый металл (FM-HM), где существует значительное демпфирование (подавление колебаний), обусловленные протеканием электрического тока вдоль направления x. SOT возникают из-за спинового эффекта Холла в объеме HM материала и из-за обратного спин-гальванического эффекта на интерфейсе FM-HM.

Ранее проведенные исследования показали, что значение демпфированого SOT может быть достаточно большим, чтобы переключать направление намагничивания при низких плотностях тока (до 107108 А/см2).

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

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

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

Однако, по мнению авторов сего труда, именно в перпендикулярно намагниченных многослойных материалах кроется большой потенциал. В частности, перспективность использования систем с перпендикулярной магнитной анизотропией (PMA от perpendicular magnetic anisotropy) обусловлена повышенной термостабильностью, более высокими плотностями упаковки и улучшенным масштабированием.

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

Результаты исследования


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


Изображение 1

На изображении показана схема датчика Холла* крестового типа, используемого для измерений демпфирующих (DL) и полевых (FL) SOT полей в мультислое Вт (5 нм) / CoFeB (0.6 нм) / MgO (2 нм) / Ta (3 нм). Мультислой был выращен на подложке [Pb(Mg0.33Nb0.66O3)]0.68 (011) (сокращенно PMN-PT), которая использовалась для электрической генерации механических напряжений. На 1b показан снимок устройства, сделанный оптическим микроскопом.
Эффект Холла* возникновение поперечной разности потенциалов при размещении проводника с постоянным током в магнитное поле.

Устройства Холла бывают трех типов: а датчик Холла крестового типа; b разделитель тока; с датчик магнетосопротивления.
Одноосная деформация в плоскости была получена путем приложения вне-плоскостного электрического поля постоянного тока к пьезоэлектрической PMN-PT(011) подложке.

Обычно реакция пьезоэлектрической деформации на приложенное электрическое поле имеет гистерезисный характер. Однако электрические поля, которые превышают коэрцитивное* поле, характерное для материала, полюсует подложку и приводят к режиму, в котором генерируемая деформация характеризуется линейным откликом.
Коэрцитивная сила* значение напряженности магнитного поля, необходимого для полного размагничивания вещества.
Линейный режим поддерживается до тех пор, пока подложка не будет сдвинута в другом направлении путем приложения электрических полей, больших, чем противоположное коэрцитивное поле. Поэтому перед первыми измерениями, но после процесса структурирования, к PMN-PT подложке было применено полюсование посредством электрического поля +400 кВм-1.

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

Стоит также отметить, что пересечение Холла было изготовлено таким образом, чтобы его плечи были ориентированы вдоль направлений [011] и [100] подложки PMN-PT (011), которые соответствуют направлениям растяжения и сжатия соответственно.

Для начала была проведена характеризация магнитного гистерезиса системы при нулевом электрическом поле постоянного тока.

На изображении 1b показана аномальная линия напряжения Холла с вне-плоскостным магнитным полем (0 Гц), измеренная для W=CoFeB=MgO=Ta при 0 кВм-1 (красная линия), демонстрирующая переключение легкой оси (оси легкого намагничивания), характерное для множеств тонких мультислоев CoFeB.

Цикл вне-плоскостного намагничивания, измеренный при 400 кВм-1 (черная линия), накладывается поверх напряжения Холла (красная линия) и не показывает значительных изменений из-за генерируемой деформации. Это говорит о том, что система всегда имеет доминирующую перпендикулярную магнитную анизотропию.


Изображение 2

Графики выше показывают типичные внутри-плоскостные зависимости полей первой (V1) и второй (V2) гармоник напряжения Холла, когда к текущей линии был применен переменный ток с плотностью jс = 3.8 х 1010 А/м2.

Напряжение постоянного тока было установлено на 0, поэтому на кресте Холла не создавалось никакого напряжения. Графики продольного (2a) и поперечного (2b) полей демонстрируют ожидаемые симметрии: для продольного поля наклоны V2 и наклоны поля одинаковы для обоих направлений намагниченности вдоль +z (+Mz) или -z (-Mz), тогда как для поперечного поля их знак становится противоположным.

Далее ученые провели анализ поперечной (0HT) и продольной (0HL) компоненты поля SOT для обоих направлений намагниченности Mz и определили среднее значение этих компонент как функции приложенной плотности тока jc (2c).


Изображение 3

Графики выше показывают результаты зависимости от электрического поля. Было определено, что полевой (FL) SOT существенно не меняется при растягивающих и сжимающих деформациях ( и ). Напротив, на 3b видно, что растягивающая деформация увеличивает демпфирующий (DL) SOT в 2 раза при приложении 400 кВм-1 (0.03% напряжение).

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

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

Чтобы понять микроскопическое происхождение экспериментально наблюдаемой деформационной зависимости FL и DL SOT, были проведены функциональные расчеты по методике теории функционала плотности электронной структуры Fe1-xCox/W(001), состоящей из перпендикулярно намагниченного монослоя и немагнитных подложек.


Изображение 4

Как показано на , во время расчетов кристаллическая структура намеренно расширялась или сужалась, сохраняя постоянную площадь в плоскости элементарной ячейки, чтобы учесть эффект одноосной деформации. Эта деформация может быть определена количественно по соотношению = (aj aj)/aj, где aj и aj обозначают постоянную решетки вдоль j-направления в плоскости в расслабленном и искаженном состоянии соответственно. Как следствие, любая конечная деформация уменьшает исходную симметрию кристалла с C4v до C2v.

Основываясь на расчетах электронной структуры, была получена зависимость SOT от (4b), которая проявляет те же качественные характеристики, что и в фактическом эксперименте.

Поскольку FL и DL SOT происходят из разных электронных состояний, они обычно следуют различным зависимостям от структурных особенностей. Было установлено, что величина DL момента линейно возрастает по отношению к растягивающей деформации и линейно уменьшается по отношению к сжимающей. Например, расширение решетки на 1% вдоль направления электрического поля значительно увеличивает проводимость DL моментов (примерно на 35%).

Чтобы более точно оценить это наблюдение, было проведено сравнение () распределений в пространстве микроскопических вкладов в DL SOT для релаксированных и деформированных пленок. В отличие от занятых состояний вокруг точки М, которые являются едва важными, электронные состояния вблизи точек высокой симметрии , X и Y составляют основной источник проводимости DL. В частности, растягивающая деформация способствует сильным отрицательным вкладам вокруг X и Y, что приводит к общему увеличению проводимости.

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

В то время как dxy, dx2 y2 и dz2 не зависят от знака приложенной деформации , состояния dyz и dzxявно изменяются относительно деформации растяжения или сжатия. Примечательно, что эти орбитали также опосредуют гибридизацию с подложкой из тяжелого металла. Из этого следует, что их зависимость от структурных особенностей дает дополнительное понимание SOT в исследуемых тонких пленках.

В качестве примера ученые предлагаю рассмотреть деформационное изменение плотности состояний dyz в магнитном слое по сравнению со случаем с четырехкратной вращательной симметрией (4d).

В то время как плотность состояний * на уровне Ферми практически не зависит от деформации растяжения, состояния явно перераспределяются. Как показывает орбитальная поляризация на 4e, этот эффект обусловлен выраженными -управляемыми изменениями поляризации dyz вокруг точки X, что коррелирует с изменениями проводимости DL ().
Спиновый канал* одно из направления ориентации спина (вверх или вниз).

Индекс s = , обозначает спиновое состояние электронов в ферромагнетиках: спиновую подзону большинства электронов, спиновую подзону меньшинства электронов. Кроме того, индекс s =, обозначает спиновое состояние электрона в спиновых каналах проводимости.
Используя данные, полученные из расчетов электронной структуры, ученые обнаружили, что различная природа наблюдаемых экспериментально особенностей FL и DL моментов происходит из уникальных изменений орбитальной поляризации электронных состояний из-за искажений решетки.

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

Эпилог


Как заявляют авторы труда, помимо раскрытия ключевой роли гибридизированных состояний на интерфейсе FM-HM, результаты исследования предлагают четкую схему для рукотворных спин-орбитальных явлений. Используя сложное взаимодействие спинового и орбитального магнетизма, спин-орбитальной связи и симметрии, можно адаптировать величину SOT в многослойных устройствах, создавая орбитальную поляризацию состояний вблизи энергии Ферми по отношению к деформации.

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

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

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

Приложение деформации к исследуемой структуре W=CoFeB=MgO во время опытов привело к отчетливо различным изменениям FL и DL спинов. Причем как отмечают ученые, DL спин может быть увеличен в 2 раза, если деформацию растяжения прикладывать параллельно течению тока.

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

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

Благодарю за внимание, оставайтесь любопытствующими и хорошей всем рабочей недели, ребята. :)

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Apache Airflow делаем ETL проще

27.07.2020 12:16:39 | Автор: admin

Привет, я Дмитрий Логвиненко Data Engineer отдела аналитики группы компаний Везёт.


Я расскажу вам о замечательном инструменте для разработки ETL-процессов Apache Airflow. Но Airflow настолько универсален и многогранен, что вам стоит присмотреться к нему даже если вы не занимаетесь потоками данных, а имеете потребность периодически запускать какие-либо процессы и следить за их выполнением.


И да, я буду не только рассказывать, но и показывать: в программе много кода, скриншотов и рекомендаций.



Что обычно видишь, когда гуглишь слово Airflow / Wikimedia Commons


Введение


Apache Airflow он прямо как Django:


  • написан на Python,
  • есть отличная админка,
  • неограниченно расширяем,

только лучше, да и сделан совсем для других целей, а именно (как написано до ката):


  • запуск и мониторинг задач на неограниченном количестве машин (сколько вам позволит Celery/Kubernetes и ваша совесть)
  • с динамической генерацией workflow из очень легкого для написания и восприятия Python-кода
  • и возможностью связывать друг с друг любые базы данных и API с помощью как готовых компонентов, так и самодельных плагинов (что делается чрезвычайно просто).

Мы используем Apache Airflow так:


  • собираем данные из различных источников (множество инстансов SQL Server и PostgreSQL, различные API с метриками приложений, даже 1С) в DWH и ODS (у нас это Vertica и Clickhouse).
  • как продвинутый cron, который запускает процессы консолидации данных на ODS, а также следит за их обслуживанием.

До недавнего времени наши потребности покрывал один небольшой сервер на 32 ядрах и 50 GB оперативки. В Airflow при этом работает:


  • более 200 дагов (собственно workflows, в которые мы набили задачки),
  • в каждом в среднем по 70 тасков,
  • запускается это добро (тоже в среднем) раз в час.

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


Есть три исходных SQL Serverа, на каждом по 50 баз данных инстансов одного проекта, соответственно, структура у них одинаковая (почти везде, муа-ха-ха), а значит в каждой есть таблица Orders (благо таблицу с таким названием можно затолкать в любой бизнес). Мы забираем данные, добавляя служебные поля (сервер-источник, база-источник, идентификатор ETL-задачи) и наивным образом бросим их в, скажем, Vertica.

Поехали!


Часть основная, практическая (и немного теоретическая)


Зачем оно нам (и вам)


Когда деревья были большими, а я был простым SQL-щиком в одном российском ритейле, мы шпарили ETL-процессы aka потоки данных с помощью двух доступных нам средств:


  • Informatica Power Center крайне развесистая система, чрезвычайно производительная, со своими железками, собственным версионированием. Использовал я дай бог 1% её возможностей. Почему? Ну, во-первых, этот интерфейс где-то из нулевых психически давил на нас. Во-вторых, эта штуковина заточена под чрезвычайно навороченные процессы, яростное переиспользование компонентов и другие очень-важные-энтерпрайз-фишечки. Про то что стоит она, как крыло Airbus A380/год, мы промолчим.


    Осторожно, скриншот может сделать людям младше 30 немного больно




  • SQL Server Integration Server этим товарищем мы пользовались в своих внутрипроектных потоках. Ну а в самом деле: SQL Server мы уже используем, и не юзать его ETL-тулзы было бы как-то неразумно. Всё в нём в хорошо: и интерфейс красивый, и отчётики выполнения Но не за это мы любим программные продукты, ох не за это. Версионировать его dtsx (который представляет собой XML с перемешивающимися при сохранении нодами) мы можем, а толку? А сделать пакет тасков, который перетащит сотню таблиц с одного сервера на другой? Да что сотню, у вас от двадцати штук отвалится указательный палец, щёлкающий по мышиной кнопке. Но выглядит он, определенно, более модно:




Мы безусловно искали выходы. Дело даже почти дошло до самописного генератора SSIS-пакетов...


а потом меня нашла новая работа. А на ней меня настиг Apache Airflow.


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


Собираем кластер


Давайте не устраивать совсем уж детский сад, и не говорить тут о совершенно очевидных вещах, вроде установки Airflow, выбранной вами БД, Celery и других дел, описанных в доках.


Чтобы мы могли сразу приступить к экспериментам, я набросал docker-compose.yml в котором:


  • Поднимем собственно Airflow: Scheduler, Webserver. Там же будет крутится Flower для мониторинга Celery-задач (потому что его уже затолкали в apache/airflow:1.10.10-python3.7, а мы и не против);
  • PostgreSQL, в который Airflow будет писать свою служебную информацию (данные планировщика, статистика выполнения и т. д.), а Celery отмечать завершенные таски;
  • Redis, который будет выступать брокером задач для Celery;
  • Celery worker, который и займется непосредственным выполнением задачек.
  • В папку ./dags мы будет складывать наши файлы с описанием дагов. Они будут подхватываться на лету, поэтому передёргивать весь стек после каждого чиха не нужно.

Кое-где код в примерах приведен не полностью (чтобы не загромождать текст), а где-то он модифицируется в процессе. Цельные работающие примеры кода можно посмотреть в репозитории https://github.com/dm-logv/airflow-tutorial.

docker-compose.yml
version: '3.4'x-airflow-config: &airflow-config  AIRFLOW__CORE__DAGS_FOLDER: /dags  AIRFLOW__CORE__EXECUTOR: CeleryExecutor  AIRFLOW__CORE__FERNET_KEY: MJNz36Q8222VOQhBOmBROFrmeSxNOgTCMaVp2_HOtE0=  AIRFLOW__CORE__HOSTNAME_CALLABLE: airflow.utils.net:get_host_ip_address  AIRFLOW__CORE__SQL_ALCHEMY_CONN: postgres+psycopg2://airflow:airflow@airflow-db:5432/airflow  AIRFLOW__CORE__PARALLELISM: 128  AIRFLOW__CORE__DAG_CONCURRENCY: 16  AIRFLOW__CORE__MAX_ACTIVE_RUNS_PER_DAG: 4  AIRFLOW__CORE__LOAD_EXAMPLES: 'False'  AIRFLOW__CORE__LOAD_DEFAULT_CONNECTIONS: 'False'  AIRFLOW__EMAIL__DEFAULT_EMAIL_ON_RETRY: 'False'  AIRFLOW__EMAIL__DEFAULT_EMAIL_ON_FAILURE: 'False'  AIRFLOW__CELERY__BROKER_URL: redis://broker:6379/0  AIRFLOW__CELERY__RESULT_BACKEND: db+postgresql://airflow:airflow@airflow-db/airflowx-airflow-base: &airflow-base  image: apache/airflow:1.10.10-python3.7  entrypoint: /bin/bash  restart: always  volumes:    - ./dags:/dags    - ./requirements.txt:/requirements.txtservices:  # Redis as a Celery broker  broker:    image: redis:6.0.5-alpine  # DB for the Airflow metadata  airflow-db:    image: postgres:10.13-alpine    environment:      - POSTGRES_USER=airflow      - POSTGRES_PASSWORD=airflow      - POSTGRES_DB=airflow    volumes:      - ./db:/var/lib/postgresql/data  # Main container with Airflow Webserver, Scheduler, Celery Flower  airflow:    <<: *airflow-base    environment:      <<: *airflow-config      AIRFLOW__SCHEDULER__DAG_DIR_LIST_INTERVAL: 30      AIRFLOW__SCHEDULER__CATCHUP_BY_DEFAULT: 'False'      AIRFLOW__SCHEDULER__MAX_THREADS: 8      AIRFLOW__WEBSERVER__LOG_FETCH_TIMEOUT_SEC: 10    depends_on:      - airflow-db      - broker    command: >      -c " sleep 10 &&           pip install --user -r /requirements.txt &&           /entrypoint initdb &&          (/entrypoint webserver &) &&          (/entrypoint flower &) &&           /entrypoint scheduler"    ports:      # Celery Flower      - 5555:5555      # Airflow Webserver      - 8080:8080  # Celery worker, will be scaled using `--scale=n`  worker:    <<: *airflow-base    environment:      <<: *airflow-config    command: >      -c " sleep 10 &&           pip install --user -r /requirements.txt &&           /entrypoint worker"    depends_on:      - airflow      - airflow-db      - broker

Примечания:


  • В сборке композа я во многом опирался на известный образ puckel/docker-airflow обязательно посмотрите. Может, вам в жизни больше ничего и не понадобится.
  • Все настройки Airflow доступны не только через airflow.cfg, но и через переменные среды (слава разработчикам), чем я злостно воспользовался.
  • Естественно, он не production-ready: я намеренно не ставил heartbeats на контейнеры, не заморачивался с безопасностью. Но минимум, подходящий для наших экспериментиков я сделал.
  • Обратите внимание, что:
    • Папка с дагами должна быть доступна как планировщику, так и воркерам.
    • То же самое касается и всех сторонних библиотек они все должны быть установлены на машины с шедулером и воркерами.

Ну а теперь просто:


$ docker-compose up --scale worker=3

После того, как всё поднимется, можно смотреть на веб-интерфейсы:



Основные понятия


Если вы ничего не поняли во всех этих дагах, то вот краткий словарик:


  • Scheduler самый главный дядька в Airflow, контролирующий, чтобы вкалывали роботы, а не человек: следит за расписанием, обновляет даги, запускает таски.


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


  • DAG (он же даг) направленный ацикличный граф, но такое определение мало кому что скажет, а по сути это контейнер для взаимодействующих друг с другом тасков (см. ниже) или аналог Package в SSIS и Workflow в Informatica.


    Помимо дагов еще могут быть сабдаги, но мы до них скорее всего не доберёмся.


  • DAG Run инициализированный даг, которому присвоен свой execution_date. Даграны одного дага могут вполне работать параллельно (если вы, конечно, сделали свои таски идемпотентными).


  • Operator это кусочки кода, ответственные за выполнение какого-либо конкретного действия. Есть три типа операторов:


    • action, как например наш любимый PythonOperator, который в силах выполнить любой (валидный) Python-код;
    • transfer, которые перевозят данные с места на место, скажем, MsSqlToHiveTransfer;
    • sensor же позволит реагировать или притормозить дальнейшее выполнение дага до наступления какого-либо события. HttpSensor может дергать указанный эндпойнт, и когда дождется нужный ответ, запустить трансфер GoogleCloudStorageToS3Operator. Пытливый ум спросит: зачем? Ведь можно делать повторы прямо в операторе! А затем, чтобы не забивать пул тасков подвисшими операторами. Сенсор запускается, проверяет и умирает до следующей попытки.

  • Task объявленные операторы вне зависимости от типа и прикрепленные к дагу повышаются до чина таска.


  • Task instance когда генерал-планировщик решил, что таски пора отправлять в бой на исполнители-воркеры (прямо на месте, если мы используем LocalExecutor или на удалённую ноду в случае с CeleryExecutor), он назначает им контекст (т. е. комплект переменных параметров выполнения), разворачивает шаблоны команд или запросов и складывает их в пул.



Генерируем таски


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


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


from datetime import timedelta, datetimefrom airflow import DAGfrom airflow.operators.python_operator import PythonOperatorfrom commons.datasources import sql_server_dsdag = DAG('orders',          schedule_interval=timedelta(hours=6),          start_date=datetime(2020, 7, 8, 0))def workflow(**context):    print(context)for conn_id, schema in sql_server_ds:    PythonOperator(        task_id=schema,        python_callable=workflow,        provide_context=True,        dag=dag)

Давайте разбираться:


  • Сперва импортируем нужные либы и кое что ещё;
  • sql_server_ds это List[namedtuple[str, str]] с именами коннектов из Airflow Connections и базами данных из которых мы будем забирать нашу табличку;
  • dag объявление нашего дага, которое обязательно должно лежать в globals(), иначе Airflow его не найдет. Дагу также нужно сказать:
    • что его зовут orders это имя потом будет маячить в веб-интерфейсе,
    • что работать он будет, начиная с полуночи восьмого июля,
    • а запускать он должен, примерно каждые 6 часов (для крутых парней здесь вместо timedelta() допустима cron-строка 0 0 0/6 ? * * *, для менее крутых выражение вроде @daily);
  • workflow() будет делать основную работу, но не сейчас. Сейчас мы просто высыпем наш контекст в лог.
  • А теперь простая магия создания тасков:
    • пробегаем по нашим источникам;
    • инициализируем PythonOperator, который будет выполнять нашу пустышку workflow(). Не забывайте указывать уникальное (в рамках дага) имя таска и подвязывать сам даг. Флаг provide_context в свою очередь насыпет в функцию дополнительных аргументов, которые мы бережно соберём с помощью **context.

Пока на этом всё. Что мы получили:


  • новый даг в веб-интерфейсе,
  • полторы сотни тасков, которые будут выполняться параллельно (если то позволят настройки Airflow, Celery и мощности серверов).

Ну, почти получили.



Зависимости кто будет ставить?


Чтобы всё это дело упростить я вкорячил в docker-compose.yml обработку requirements.txt на всех нодах.


Вот теперь понеслась:



Серые квадратики task instances, обработанные планировщиком.


Немного ждем, задачи расхватывают воркеры:



Зеленые, понятное дело, успешно отработавшие. Красные не очень успешно.


Кстати, на нашем проде никакой папки ./dags, синхронизирующейся между машинами нет всё даги лежат в git на нашем Gitlab, а Gitlab CI раскладывает обновления на машины при мёрдже в master.

Немного о Flower


Пока воркеры молотят наши тасочки-пустышки, вспомним про еще один инструмент, который может нам кое-что показать Flower.


Самая первая страничка с суммарной информацией по нодам-воркерам:



Самая насыщенная страничка с задачами, отправившимися в работу:



Самая скучная страничка с состоянием нашего брокера:



Самая яркая страничка с графиками состояния тасков и их временем выполнения:



Догружаем недогруженное


Итак, все таски отработали, можно уносить раненых.



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


Нужно смотреть лог и перезапускать упавшие task instances.


Жмякнув на любой квадрат, увидим доступные нам действия:



Можно взять, и сделать Clear упавшему. То есть, мы забываем о том, что там что-то завалилось, и тот же самый инстанс таска уйдет планировщику.



Понятно, что делать так мышкой со всеми красными квадратами не очень гуманно не этого мы ждем от Airflow. Естественно, у нас есть оружие массового поражения: Browse/Task Instances



Выберем всё разом и обнулим нажмем правильный пункт:



После очистки наши такси выглядят так (они уже ждут не дождутся, когда шедулер их запланирует):



Соединения, хуки и прочие переменные


Самое время посмотреть на следующий DAG, update_reports.py:


from collections import namedtuplefrom datetime import datetime, timedeltafrom textwrap import dedentfrom airflow import DAGfrom airflow.contrib.operators.vertica_operator import VerticaOperatorfrom airflow.operators.email_operator import EmailOperatorfrom airflow.utils.trigger_rule import TriggerRulefrom commons.operators import TelegramBotSendMessagedag = DAG('update_reports',          start_date=datetime(2020, 6, 7, 6),          schedule_interval=timedelta(days=1),          default_args={'retries': 3, 'retry_delay': timedelta(seconds=10)})Report = namedtuple('Report', 'source target')reports = [Report(f'{table}_view', table) for table in [    'reports.city_orders',    'reports.client_calls',    'reports.client_rates',    'reports.daily_orders',    'reports.order_duration']]email = EmailOperator(    task_id='email_success', dag=dag,    to='{{ var.value.all_the_kings_men }}',    subject='DWH Reports updated',    html_content=dedent("""Господа хорошие, отчеты обновлены"""),    trigger_rule=TriggerRule.ALL_SUCCESS)tg = TelegramBotSendMessage(    task_id='telegram_fail', dag=dag,    tg_bot_conn_id='tg_main',    chat_id='{{ var.value.failures_chat }}',    message=dedent("""\         Наташ, просыпайся, мы {{ dag.dag_id }} уронили        """),    trigger_rule=TriggerRule.ONE_FAILED)for source, target in reports:    queries = [f"TRUNCATE TABLE {target}",               f"INSERT INTO {target} SELECT * FROM {source}"]    report_update = VerticaOperator(        task_id=target.replace('reports.', ''),        sql=queries, vertica_conn_id='dwh',        task_concurrency=1, dag=dag)    report_update >> [email, tg]

Все ведь когда-нибудь делали обновлялку отчетов? Это снова она: есть список источников, откуда забрать данные; есть список, куда положить; не забываем посигналить, когда всё случилось или сломалось (ну это не про нас, нет).


Давайте снова пройдемся по файлу и посмотрим на новые непонятные штуки:


  • from commons.operators import TelegramBotSendMessage нам ничто не мешает делать свои операторы, чем мы и воспользовались, сделав небольшую обёрточку для отправки сообщений в Разблокированный. (Об этом операторе мы еще поговорим ниже);
  • default_args={} даг может раздавать одни и те же аргументы всем своим операторам;
  • to='{{ var.value.all_the_kings_men }}' поле to у нас будет не захардкоженным, а формируемым динамически с помощью Jinja и переменной со списком email-ов, которую я заботливо положил в Admin/Variables;
  • trigger_rule=TriggerRule.ALL_SUCCESS условие запуска оператора. В нашем случае, письмо полетит боссам только если все зависимости отработали успешно;
  • tg_bot_conn_id='tg_main' аргументы conn_id принимают в себя идентификаторы соединений, которые мы создаем в Admin/Connections;
  • trigger_rule=TriggerRule.ONE_FAILED сообщения в Telegram улетят только при наличии упавших тасков;
  • task_concurrency=1 запрещаем одновременный запуск нескольких task instances одного таска. В противном случае, мы получим одновременный запуск нескольких VerticaOperator (смотрящих на одну таблицу);
  • report_update >> [email, tg] все VerticaOperator сойдутся в отправке письма и сообщения, вот так:


    Но так как у операторов-нотификаторов стоят разные условия запуска, работать будет только один. В Tree View всё выглядит несколько менее наглядно:



Скажу пару слов о макросах и их друзьях переменных.


Макросы это Jinja-плейсхолдеры, которые могут подставлять разную полезную информацию в аргументы операторов. Например, так:


SELECT    id,    payment_dtm,    payment_type,    client_idFROM orders.paymentsWHERE    payment_dtm::DATE = '{{ ds }}'::DATE

{{ ds }} развернется в содержимое переменной контекста execution_date в формате YYYY-MM-DD: 2020-07-14. Самое приятное, что переменные контекста прибиваются гвоздями к определенному инстансу таска (квадратику в Tree View), и при перезапуске плейсхолдеры раскроются в те же самые значения.


Присвоенные значения можно смотреть с помощью кнопки Rendered на каждом таск-инстансе. Вот так у таска с отправкой письма:



А так у таски с отправкой сообщения:



Полный список встроенных макросов для последней доступной версии доступен здесь: Macros Reference


Более того, с помощью плагинов, мы можем объявлять собственные макросы, но это уже совсем другая история.


Помимо предопределенных штук, мы можем подставлять значения своих переменных (выше в коде я уже этим воспользовался). Создадим в Admin/Variables пару штук:



Всё, можно пользоваться:


TelegramBotSendMessage(chat_id='{{ var.value.failures_chat }}')

В значении может быть скаляр, а может лежать и JSON. В случае JSON-а:


bot_config{    "bot": {        "token": 881hskdfASDA16641,        "name": "Verter"    },    "service": "TG"}

просто используем путь к нужному ключу: {{ var.json.bot_config.bot.token }}.


Скажу буквально одно слово и покажу один скриншот про соединения. Тут всё элементарно: на странице Admin/Connections создаем соединение, складываем туда наши логины/пароли и более специфичные параметры. Вот так:



Пароли можно шифровать (более тщательно, чем в варианте по умолчанию), а можно не указывать тип соединения (как я сделал для tg_main) дело в том, что список типов зашит в моделях Airflow и расширению без влезания в исходники не поддается (если вдруг я чего-то не догуглил прошу меня поправить), но получить креды просто по имени нам ничто не помешает.


А еще можно сделать несколько соединений с одним именем: в таком случае метод BaseHook.get_connection(), который достает нам соединения по имени, будет отдавать случайного из нескольких тёзок (было бы логичнее сделать Round Robin, но оставим это на совести разработчиков Airflow).


Variables и Connections, безусловно, классные средства, но важно не потерять баланс: какие части ваших потоков вы храните собственно в коде, а какие отдаете на хранение Airflow. C одной стороны быстро поменять значение, например, ящик рассылки, может быть удобно через UI. А с другой это всё-таки возврат к мышеклику, от которого мы (я) хотели избавиться.

Работа с соединениями это одна из задач хуков. Вообще хуки Airflow это точки подключения его к сторонним сервисам и библиотекам. К примеру, JiraHook откроет для нас клиент для взаимодействия с Jira (можно задачки подвигать туда-сюда), а с помощью SambaHook можно запушить локальный файл на smb-точку.


Разбираем кастомный оператор


И мы вплотную подобрались к тому, чтобы посмотреть на то, как сделан TelegramBotSendMessage


Код commons/operators.py с собственно оператором:


from typing import Unionfrom airflow.operators import BaseOperatorfrom commons.hooks import TelegramBotHook, TelegramBotclass TelegramBotSendMessage(BaseOperator):    """Send message to chat_id using TelegramBotHook    Example:        >>> TelegramBotSendMessage(        ...     task_id='telegram_fail', dag=dag,        ...     tg_bot_conn_id='tg_bot_default',        ...     chat_id='{{ var.value.all_the_young_dudes_chat }}',        ...     message='{{ dag.dag_id }} failed :(',        ...     trigger_rule=TriggerRule.ONE_FAILED)    """    template_fields = ['chat_id', 'message']    def __init__(self,                 chat_id: Union[int, str],                 message: str,                 tg_bot_conn_id: str = 'tg_bot_default',                 *args, **kwargs):        super().__init__(*args, **kwargs)        self._hook = TelegramBotHook(tg_bot_conn_id)        self.client: TelegramBot = self._hook.client        self.chat_id = chat_id        self.message = message    def execute(self, context):        print(f'Send "{self.message}" to the chat {self.chat_id}')        self.client.send_message(chat_id=self.chat_id,                                 message=self.message)

Здесь, как и остальное в Airflow, всё очень просто:


  • Отнаследовались от BaseOperator, который реализует довольно много Airflow-специфичных штук (посмотрите на досуге)
  • Объявили поля template_fields, в которых Jinja будет искать макросы для обработки.
  • Организовали правильные аргументы для __init__(), расставили умолчания, где надо.
  • Об инициализации предка тоже не забыли.
  • Открыли соответствующий хук TelegramBotHook, получили от него объект-клиент.
  • Оверрайднули (переопределили) метод BaseOperator.execute(), который Airfow будет подергивать, когда наступит время запускать оператор в нем мы и реализуем основное действие, на забыв залогироваться. (Логируемся, кстати, прямо в stdout и stderr Airflow всё перехватит, красиво обернет, разложит, куда надо.)

Давайте смотреть, что у нас в commons/hooks.py. Первая часть файлика, с самим хуком:


from typing import Unionfrom airflow.hooks.base_hook import BaseHookfrom requests_toolbelt.sessions import BaseUrlSessionclass TelegramBotHook(BaseHook):    """Telegram Bot API hook    Note: add a connection with empty Conn Type and don't forget    to fill Extra:        {"bot_token": "YOuRAwEsomeBOtToKen"}    """    def __init__(self,                 tg_bot_conn_id='tg_bot_default'):        super().__init__(tg_bot_conn_id)        self.tg_bot_conn_id = tg_bot_conn_id        self.tg_bot_token = None        self.client = None        self.get_conn()    def get_conn(self):        extra = self.get_connection(self.tg_bot_conn_id).extra_dejson        self.tg_bot_token = extra['bot_token']        self.client = TelegramBot(self.tg_bot_token)        return self.client

Я даже не знаю, что тут можно объяснять, просто отмечу важные моменты:


  • Наследуемся, думаем над аргументами в большинстве случаев он будет один: conn_id;
  • Переопределяем стандартные методы: я ограничился get_conn(), в котором я получаю параметры соединения по имени и всего-навсего достаю секцию extra (это поле для JSON), в которую я (по своей же инструкции!) положил токен Telegram-бота: {"bot_token": "YOuRAwEsomeBOtToKen"}.
  • Создаю экземпляр нашего TelegramBot, отдавая ему уже конкретный токен.

Вот и всё. Получить клиент из хука можно c помощью TelegramBotHook().clent или TelegramBotHook().get_conn().


И вторая часть файлика, в котором я сделать микрообёрточку для Telegram REST API, чтобы не тащить тот же python-telegram-bot ради одного метода sendMessage.


class TelegramBot:    """Telegram Bot API wrapper    Examples:        >>> TelegramBot('YOuRAwEsomeBOtToKen', '@myprettydebugchat').send_message('Hi, darling')        >>> TelegramBot('YOuRAwEsomeBOtToKen').send_message('Hi, darling', chat_id=-1762374628374)    """    API_ENDPOINT = 'https://api.telegram.org/bot{}/'    def __init__(self, tg_bot_token: str, chat_id: Union[int, str] = None):        self._base_url = TelegramBot.API_ENDPOINT.format(tg_bot_token)        self.session = BaseUrlSession(self._base_url)        self.chat_id = chat_id    def send_message(self, message: str, chat_id: Union[int, str] = None):        method = 'sendMessage'        payload = {'chat_id': chat_id or self.chat_id,                   'text': message,                   'parse_mode': 'MarkdownV2'}        response = self.session.post(method, data=payload).json()        if not response.get('ok'):            raise TelegramBotException(response)class TelegramBotException(Exception):    def __init__(self, *args, **kwargs):        super().__init__((args, kwargs))

Правильный путь сложить всё это: TelegramBotSendMessage, TelegramBotHook, TelegramBot в плагин, положить в общедоступный репозиторий, и отдать в Open Source.

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



В нашем даге что-то сломалось! А ни этого ли мы ждали? Именно!


Наливать-то будешь?


Чувствуете, что-то я пропустил? Вроде бы обещал данные из SQL Server в Vertica переливать, и тут взял и съехал с темы, негодяй!


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


План у нас был такой:


  1. Сделать даг
  2. Нагенерить таски
  3. Посмотреть, как всё красиво
  4. Присваивать заливкам номера сессий
  5. Забрать данные из SQL Server
  6. Положить данные в Vertica
  7. Собрать статистику

Итак, чтобы всё это запустить, я сделал маленькое дополнение к нашему docker-compose.yml:


docker-compose.db.yml
version: '3.4'x-mssql-base: &mssql-base  image: mcr.microsoft.com/mssql/server:2017-CU21-ubuntu-16.04  restart: always  environment:    ACCEPT_EULA: Y    MSSQL_PID: Express    SA_PASSWORD: SayThanksToSatiaAt2020    MSSQL_MEMORY_LIMIT_MB: 1024services:  dwh:    image: jbfavre/vertica:9.2.0-7_ubuntu-16.04  mssql_0:    <<: *mssql-base  mssql_1:    <<: *mssql-base  mssql_2:    <<: *mssql-base  mssql_init:    image: mio101/py3-sql-db-client-base    command: python3 ./mssql_init.py    depends_on:      - mssql_0      - mssql_1      - mssql_2    environment:      SA_PASSWORD: SayThanksToSatiaAt2020    volumes:      - ./mssql_init.py:/mssql_init.py      - ./dags/commons/datasources.py:/commons/datasources.py

Там мы поднимаем:


  • Vertica как хост dwh с самыми дефолтными настройками,
  • три экземпляра SQL Server,
  • наполняем базы в последних кое-какими данными (ни в коем случае не заглядывайте в mssql_init.py!)

Запускаем всё добро с помощью чуть более сложной, чем в прошлый раз, команды:


$ docker-compose -f docker-compose.yml -f docker-compose.db.yml up --scale worker=3

Что нагенерировал наш чудорандомайзер, можно, воспользовавшись пунктом Data Profiling/Ad Hoc Query:



Главное, не показывать это аналитикам


Подробно останавливаться на ETL-сессиях я не буду, там всё тривиально: делаем базу, в ней табличку, оборачиваем всё менеджером контекста, и теперь делаем так:


with Session(task_name) as session:    print('Load', session.id, 'started')    # Load worflow    ...    session.successful = True    session.loaded_rows = 15

session.py
from sys import stderrclass Session:    """ETL workflow session    Example:        with Session(task_name) as session:            print(session.id)            session.successful = True            session.loaded_rows = 15            session.comment = 'Well done'    """    def __init__(self, connection, task_name):        self.connection = connection        self.connection.autocommit = True        self._task_name = task_name        self._id = None        self.loaded_rows = None        self.successful = None        self.comment = None    def __enter__(self):        return self.open()    def __exit__(self, exc_type, exc_val, exc_tb):        if any(exc_type, exc_val, exc_tb):            self.successful = False            self.comment = f'{exc_type}: {exc_val}\n{exc_tb}'            print(exc_type, exc_val, exc_tb, file=stderr)        self.close()    def __repr__(self):        return (f'<{self.__class__.__name__} '                 f'id={self.id} '                 f'task_name="{self.task_name}">')    @property    def task_name(self):        return self._task_name    @property    def id(self):        return self._id    def _execute(self, query, *args):        with self.connection.cursor() as cursor:            cursor.execute(query, args)            return cursor.fetchone()[0]    def _create(self):        query = """            CREATE TABLE IF NOT EXISTS sessions (                id          SERIAL       NOT NULL PRIMARY KEY,                task_name   VARCHAR(200) NOT NULL,                started     TIMESTAMPTZ  NOT NULL DEFAULT current_timestamp,                finished    TIMESTAMPTZ           DEFAULT current_timestamp,                successful  BOOL,                loaded_rows INT,                comment     VARCHAR(500)            );            """        self._execute(query)    def open(self):        query = """            INSERT INTO sessions (task_name, finished)            VALUES (%s, NULL)            RETURNING id;            """        self._id = self._execute(query, self.task_name)        print(self, 'opened')        return self    def close(self):        if not self._id:            raise SessionClosedError('Session is not open')        query = """            UPDATE sessions            SET                finished    = DEFAULT,                successful  = %s,                loaded_rows = %s,                comment     = %s            WHERE                id = %s            RETURNING id;            """        self._execute(query, self.successful, self.loaded_rows,                      self.comment, self.id)        print(self, 'closed',              ', successful: ', self.successful,              ', Loaded: ', self.loaded_rows,              ', comment:', self.comment)class SessionError(Exception):    passclass SessionClosedError(SessionError):    pass

Настала пора забрать наши данные из наших полутора сотен таблиц. Сделаем это с помощью очень незатейливых строчек:


source_conn = MsSqlHook(mssql_conn_id=src_conn_id, schema=src_schema).get_conn()query = f"""    SELECT         id, start_time, end_time, type, data    FROM dbo.Orders    WHERE        CONVERT(DATE, start_time) = '{dt}'    """df = pd.read_sql_query(query, source_conn)

  1. С помощью хука получим из Airflow pymssql-коннект
  2. В запрос подставим ограничение в виде даты в функцию её подбросит шаблонизатор.
  3. Скармливаем наш запрос pandas, который достанет для нас DataFrame он нам пригодится в дальнейшем.

Я использую подстановку {dt} вместо параметра запроса %s не потому, что я злобный Буратино, а потому что pandas не может совладать с pymssql и подсовывает последнему params: List, хотя тот очень хочет tuple.
Также обратите внимание, что разработчик pymssql решил больше его не поддерживать, и самое время съехать на pyodbc.

Посмотрим, чем Airflow нашпиговал аргументы наших функций:



Если данных не оказалось, то продолжать смысла нет. Но считать заливку успешной тоже странно. Но это и не ошибка. А-а-а, что делать?! А вот что:


if df.empty:    raise AirflowSkipException('No rows to load')

AirflowSkipException скажет Airflow, что ошибки, собственно нет, а таск мы пропускаем. В интерфейсе будет не зеленый и не красный квадратик, а цвета pink.


Подбросим нашим данным несколько колонок:


df['etl_source'] = src_schemadf['etl_id'] = session.iddf['hash_id'] = hash_pandas_object(df[['etl_source', 'id']])

А именно:


  • БД, из которой мы забрали заказы,
  • Идентификатор нашей заливающей сессии (она будет разной на каждый таск),
  • Хэш от источника и идентификатора заказа чтобы в конечной базе (где всё ссыпется в одну таблицу) у нас был уникальный идентификатор заказа.

Остался предпоследний шаг: залить всё в Vertica. А, как ни странно, один из самых эффектных эффективных способов сделать это через CSV!


# Export data to CSV bufferbuffer = StringIO()df.to_csv(buffer,          index=False, sep='|', na_rep='NUL', quoting=csv.QUOTE_MINIMAL,          header=False, float_format='%.8f', doublequote=False, escapechar='\\')buffer.seek(0)# Push CSVtarget_conn = VerticaHook(vertica_conn_id=target_conn_id).get_conn()copy_stmt = f"""    COPY {target_table}({df.columns.to_list()})     FROM STDIN     DELIMITER '|'     ENCLOSED '"'     ABORT ON ERROR     NULL 'NUL'    """cursor = target_conn.cursor()cursor.copy(copy_stmt, buffer)

  1. Мы делаем спецприёмник StringIO.
  2. pandas любезно сложит в него наш DataFrame в виде CSV-строк.
  3. Откроем соединение к нашей любимой Vertica хуком.
  4. А теперь с помощью copy() отправим наши данные прямо в Вертику!

Из драйвера заберем, сколько строчек засыпалось, и скажем менеджеру сессии, что всё ОК:


session.loaded_rows = cursor.rowcountsession.successful = True

Вот и всё.


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

create_schema_query = f'CREATE SCHEMA IF NOT EXISTS {target_schema};'create_table_query = f"""    CREATE TABLE IF NOT EXISTS {target_schema}.{target_table} (         id         INT,         start_time TIMESTAMP,         end_time   TIMESTAMP,         type       INT,         data       VARCHAR(32),         etl_source VARCHAR(200),         etl_id     INT,         hash_id    INT PRIMARY KEY     );"""create_table = VerticaOperator(    task_id='create_target',    sql=[create_schema_query,         create_table_query],    vertica_conn_id=target_conn_id,    task_concurrency=1,    dag=dag)

Я с помощью VerticaOperator() создаю схему БД и таблицу (если их еще нет, естественно). Главное, правильно расставить зависимости:

for conn_id, schema in sql_server_ds:    load = PythonOperator(        task_id=schema,        python_callable=workflow,        op_kwargs={            'src_conn_id': conn_id,            'src_schema': schema,            'dt': '{{ ds }}',            'target_conn_id': target_conn_id,            'target_table': f'{target_schema}.{target_table}'},        dag=dag)    create_table >> load

Подводим итоги


Ну вот, сказал мышонок, не правда ли, теперь
Ты убедился, что в лесу я самый страшный зверь?

Джулия Дональдсон, Груффало


Думаю, если бы мы с моими коллегами устроили соревнование: кто быстрее составит и запустит с нуля ETL-процесс: они со своими SSIS и мышкой и я с Airflow А потом бы мы еще сравнили удобство сопровождения Ух, думаю, вы согласитесь, что я обойду их по всем фронтам!


Если же чуть-чуть посерьезнее, то Apache Airflow за счет описания процессов в виде программного кода сделал мою работу гораздо удобнее и приятнее.


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


Часть заключительная, справочно-информационная


Грабли, которые мы собрали за вас


  • start_date. Да, это уже локальный мемасик. Через главный аргумент дага start_date проходят все. Кратко, если указать в start_date текущую дату, а в schedule_interval один день, то DAG запустится завтра не раньше.


    start_date = datetime(2020, 7, 7, 0, 1, 2)
    

    И больше никаких проблем.


    С ним же связана и еще одна ошибка выполнения: Task is missing the start_date parameter, которая чаще всего говорит о том, что вы забыли привязать к оператору даг.


  • Всё на одной машине. Да, и базы (самого Airflow и нашей обмазки), и веб-сервер, и планировщик, и воркеры. И оно даже работало. Но со временем количество задач у сервисов росло, и когда PostgreSQL стал отдавать ответ по индексу за 20 с вместо 5 мс, мы его взяли и унесли.


  • LocalExecutor. Да, мы сидим на нём до сих пор, и мы уже подошли к краю пропасти. LocalExecutorа нам до сих пор хватало, но сейчас пришла пора расшириться минимум одним воркером, и придется поднапрячься, чтобы переехать на CeleryExecutor. А ввиду того, что с ним можно работать и на одной машиной, то ничего не останавливает от использования Celery даже не сервере, который естественно, никогда не пойдет в прод, чесслово!


  • Неиспользование встроенных средств:


    • Connections для хранения учетных данных сервисов,
    • SLA Misses для реагирования на таски, которые не отработали вовремя,
    • XCom для обмена метаданными (я сказал метаданными!) между тасками дага.

  • Злоупотребление почтой. Ну что тут сказать? Были настроены оповещения на все повторы упавших тасков. Теперь в моём рабочем Gmail >90k писем от Airflow, и веб-морда почты отказывается брать и удалять больше чем по 100 штук за раз.



Больше подводных камней: Apache Airflow Pitfails

Средства ещё большей автоматизации


Для того чтобы нам еще больше работать головой, а не руками, Airflow заготовила для нас вот что:


  • REST API он до сих пор имеет статус Experimental, что не мешает ему работать. С его помощью можно не только получать информацию о дагах и тасках, но остановить/запустить даг, создать DAG Run или пул.


  • CLI через командную строку доступны многие средства, которые не просто неудобны в обращении через WebUI, а вообще отсутствуют. Например:


    • backfill нужен для повторного запуска инстансов тасков.
      Например, пришли аналитики, говорят: А у вас, товарищ, ерунда в данных с 1 по 13 января! Чини-чини-чини-чини!. А ты такой хоба:
      airflow backfill -s '2020-01-01' -e '2020-01-13' orders
      
    • Обслуживание базы: initdb, resetdb, upgradedb, checkdb.
    • run, который позволяет запустить один инстанс таска, да еще и забить на всё зависимости. Более того, можно запустить его через LocalExecutor, даже если у вас Celery-кластер.
    • Примерно то же самое делает test, только еще и в баз ничего не пишет.
    • connections позволяет массово создавать подключения из шелла.

  • Python API довольно хардкорный способ взаимодействия, который предназначен для плагинов, а не копошения в нём ручёнками. Но кто ж нам помешает пойти в /home/airflow/dags, запустить ipython и начать беспредельничать? Можно, например, экспортировать все подключения таком кодом:


    from airflow import settingsfrom airflow.models import Connectionfields = 'conn_id conn_type host port schema login password extra'.split()session = settings.Session()for conn in session.query(Connection).order_by(Connection.conn_id):  d = {field: getattr(conn, field) for field in fields}  print(conn.conn_id, '=', d)
    

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


    Скажем, далеко не все наши таски идемпотентны, а могут иногда падать и это нормально. Но несколько завалов это уже подозрительно, и надо бы проверить.


    Осторожно, SQL!
    WITH last_executions AS (SELECT    task_id,    dag_id,    execution_date,    state,        row_number()        OVER (            PARTITION BY task_id, dag_id            ORDER BY execution_date DESC) AS rnFROM public.task_instanceWHERE    execution_date > now() - INTERVAL '2' DAY),failed AS (    SELECT        task_id,        dag_id,        execution_date,        state,        CASE WHEN rn = row_number() OVER (            PARTITION BY task_id, dag_id            ORDER BY execution_date DESC)                 THEN TRUE END AS last_fail_seq    FROM last_executions    WHERE        state IN ('failed', 'up_for_retry'))SELECT    task_id,    dag_id,    count(last_fail_seq)                       AS unsuccessful,    count(CASE WHEN last_fail_seq        AND state = 'failed' THEN 1 END)       AS failed,    count(CASE WHEN last_fail_seq        AND state = 'up_for_retry' THEN 1 END) AS up_for_retryFROM failedGROUP BY    task_id,    dag_idHAVING    count(last_fail_seq) > 0
    



Ссылки


Ну и естественно первые десять ссылок из выдачи гугла содержимое папки Airflow из моих закладок.



И ссылки, задействованные в статье:


Подробнее..

Видео Databases Meetup Percona, Postgres Pro, Tarantool и MCS

10.07.2020 14:07:02 | Автор: admin


Всем привет! 25 июня прошел второй митап серии @Databases, организованный Mail.ru Cloud Solutions совместно с Tarantool. Переход в онлайн никого не обходит стороной, но даже на удаленке нам удалось собрать вместе более 400 участников, чтобы обсудить актуальные проблемы современных производительных баз данных.

Под катом видео выступлений: Percona о том, как собрать гибридное облако с помощью K8s, которое заменит DBaaS; Postgres Pro сразу с двумя докладами рассказали все о JSON[b] в Postgres, а также поделились стратегическими планами по развитию базы данных; а Mail.ru Cloud Solutions как S3-хранилище эволюционировало за свои три года в проде и вместе с ним менялся подход к Tarantool в его архитектуре.

Как собрать гибридное облако с помощью Kubernetes, которое может заменить DBaaS. Петр Зайцев, генеральный директор Percona



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

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

Архитектура S3: 3 года эволюции Mail.ru Cloud Storage. Владимир Перепелица, архитектор платформы Mail.ru Cloud Solutions



За три года жизни S3-хранилище MCS выросло до кластера в десятки терабайт в RAM, где лежат метаданные о миллиардах пользовательских объектов. Архитектура такой облачной базы данных требует нетривиального подхода. Например, для нее критически важно уметь линейно масштабироваться.

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

JSON[b] в Postgres: Пора великого объединения. Олег Бартунов, генеральный директор, сооснователь Postgres Professional



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

Эволюция Postgres Pro за годы существования и стратегические планы по развитию. Иван Панченко, сооснователь и заместитель генерального директора Postgres Professional



Postgres Pro коммерческий форк Postgres, выпускающийся компанией Postgres Professional. Форки, в том числе коммерческие, являются важной частью мировой экосистемы Postgres, поставляя в общий котёл передовые разработки. Сооснователь компании Postgres Professional расскажет о том, почему компания пришла к необходимости выпустить свой форк Postgres, каковы основные отличия Postgres Pro от PostgreSQL, а также поделится планами по развитию продукта.

Stay tuned


Следите за анонсами мероприятий Mail.ru Cloud Solutions в нашем канале Telegram: t.me/k8s_mail

А если хотите быть спикером событий серии @Meetup, оставьте заявку на выступление по ссылке: https://mcs.mail.ru/speak
Подробнее..

Практические кейсы по созданию IT-инфраструктуры на базе дисковых полок Western Digital Ultrastar

22.07.2020 22:18:15 | Автор: admin


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

Ключевые преимущества аппаратной платформы Ultrastar Data


Western Digital предлагает две модели JBOD-массивов, выпускаемых под брендом Ultrastar Data60 и Data102. Указанные модификации полностью идентичны с точки зрения реализованных в них технологий и отличаются друг от друга лишь емкостью, о чем красноречиво говорит числовой индекс в названии: младшая модель способна вместить 60 3.5-дюймовых SAS (12 Гб/с) или SATA (6 Гб/с) накопителей, тогда как флагман до 102 накопителей. Таким образом, одна дисковая полка Ultrastar Data60 позволяет хранить вплоть до 840 RAW-данных, а максимальная емкость Ultrastar Data102 может достигать уже 1.4 петабайта (при использовании жестких дисков Western Digital Ultrastar DC HC 530 емкостью 14 ТБ каждый). При этом 24 из доступных отсеков можно использовать для установки твердотельных накопителей с интерфейсом SAS или SATA, что позволяет достичь оптимального баланса между емкостью и производительностью, задействуя JBOD в сценариях, где на первый план выходит высокая доступность данных.

Проектируя дисковые полки серии Ultrastar Data, мы уделили особое внимание борьбе с негативным воздействием вибрации и высоких температур на функционирование системы. Результатом работы инженеров Western Digital стало появление сразу двух вспомогательных технологий, позволивших значительно улучшить эксплуатационные характеристики JBOD: IsoVibe и ArcticFlow. Рассмотрим каждую из них подробнее.

Технология подавления ротационной вибрации IsoVibe


IsoVibe призвана нивелировать пагубное влияние ротационной вибрации, возникающей при раскрутке шпинделя HDD, на производительность массива. Напомним, что при смещении магнитной головки с трека под действием внешних факторов, микроконтроллер диска вынужден инициировать процедуру позиционирования заново, из-за чего время чтения/записи данных значительно возрастает. Так, например, при воздействии на работающий винчестер ротационной вибрации с угловым ускорением в 50 радиан/сек2 потери производительности могут превысить порог в 70%. В случае с JBOD данная проблема встает еще более остро, так как в силу высокой плотности размещения накопителей в сравнительно компактном корпусе их взаимное влияние друг на друга многократно возрастает.

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


Амортизированные салазки помогают снизить уровень вибрации

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


Прорези в PCB бэкплейна снижают распространение вибрации внутри JBOD

Дополняет картину интеллектуальная прошивка микроконтроллеров жестких дисков Western Digital Ultrastar, которые мы рекомендуем использовать вместе с JBOD-массивами, поддерживающая технологию RVS (Rotational Vibration Safeguard). Специализированный алгоритм отслеживает сигналы, поступающие со встроенных мультиаксиальных акселерометров и в режиме реального времени рассчитывает компенсационные усилия, необходимые для коррекции траектории движения блока магнитных головок.


Принцип работы технологии компенсации ротационной вибрации RVS

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

Система охлаждения ArcticFlow


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

В Ultrastar Data данная проблема решена следующим образом. Дисковая полка разделена на две зоны охлаждения (по 4 ряда в каждой), изолированные друг от друга. Воздушные потоки, обеспечивающие вентиляцию передней зоны, отводятся из корпуса по обводным воздуховодам, огибающим задний отсек по бокам. Что же касается задних рядов, то для их охлаждения предусмотрен отдельный воздуховод, расположенный по центру, воздух из которого поступает непосредственно к задним рядам накопителей, с 5-го по 8-ой. Кроме того отдельный поток холодного воздуха подводится непосредственно к блокам питания и модулям I/O, расположенным позади.


Схема циркуляции воздуха внутри дисковых полок Ultrastar Data

Такая конструкция помогла достичь действительно впечатляющих результатов. ArcticFlow позволила существенно сократить разницу температур между передней и задней зонами: разброс между ними не превышает 10C. При использовании накопителей Ultrastar, созданных на базе платформы HelioSeal четвертого поколения (более подробно о технологиях, применяемых при производстве жестких дисков для ЦОД, вы можете прочитать в материале Ярче звезд), на самом горячем участке, которым является 8-ой ряд, вплотную прилегающий к отсекам блоков питания, максимальная температура HDD не поднимается выше 49C. При этом на охлаждение каждого из них тратится в среднем 1.6 Вт электроэнергии, что в два раза меньше, чем у конкурирующих моделей.



Таким образом, ArcticFlow решает одновременно 3 задачи:

  1. эффективное охлаждение помогает продлить сроки эксплуатации накопителей, установленных в JBOD, а также полностью исключает вероятность их выхода из строя вследствие перегрева;
  2. отпадает потребность в установке мощных, высокоскоростных кулеров, что также помогает снизить общий уровень вибрации, негативно отражающейся как на состоянии аппаратуры, так и на ее производительности;
  3. меньшее энергопотребление позволяет значительно сократить операционные расходы на обслуживание дата-центра, оборудованного JBOD Ultrastar.

Построение облачной инфраструктуры с применением дисковых полок Ultrastar на примере компании Acronis


Кому же подойдут дисковые полки Western Digital Ultrastar? Первое, что приходит в голову облачные сервисы, оперирующие огромными массивами данных. По мере расширения бизнеса такие компании неизбежно сталкиваются с экспоненциальным ростом затрат на масштабирование и поддержку IT-инфраструктуры, которые оказываются тем больше, чем сложнее организована последняя.

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

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


Стремясь увеличить емкость хранилищ данных и при этом оптимизировать затраты на их обслуживание, Acronis столкнулись с рядом существенных трудностей, вызванных отсутствием унифицированной аппаратной платформы. Компания обратилась за помощью к своему давнему технологическому партнеру DIAWAY. Для прогнозирования капитальных и операционных расходов системный интегратор создал доскональную финансовую модель на ближайшие 5 лет. Сравнив предложения, представленные на современном рынке, специалисты DIAWAY пришли к выводу, что наиболее оптимальным вариантом для реализации подобного проекта станут гибридные хранилища Western Digital Ultrastar Data60 и Data102.

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

  • Снижение TCO

Благодаря переходу на гибридные хранилища Ultrastar, Acronis удалось добиться существенного сокращения капитальных и эксплуатационных расходов: стоимость хранения данных в пересчете на терабайт информации снизилась более, чем на 25%.

  • Повышение надежности систем хранения

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

  • Простота обслуживания

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

Примеры развертывания системы резервного копирования на базе Western Digital Ultrastar Data60 и программного обеспечения от Veeam Software


Впрочем, не стоит думать, что дисковые полки Ultrastar ориентированы сугубо на крупные компании и облачных провайдеров: JBOD-массивы способны стать незаменимым инструментом и в арсенале представителей малого и среднего бизнеса. Речь идет, прежде всего, о создании высокоемких и производительных систем резервного копирования, для организации которых мы предлагаем готовую связку в виде Ultrastar Data60/102 и программного обеспечения, разработанного одним из наших стратегических партнеров Veeam Software, специализирующихся на создании комплексных решений в сфере резервного копирования данных.


Девиз компании It just works! говорит сам за себя: Veeam стремится создавать простые, эффективные, а главное, надежные продукты из разряда настроил и забыл, и у них это действительно хорошо получается. Не случайно в 2019 году общее количество клиентов компании превысило 375 тысяч, а ее годовой оборот перевалил за отметку в 1 миллиард долларов США.

В ходе проектирования системы резервного копирования на базе дисковых полок Ultrastar и программного обеспечения Veeam наибольшую эффективность демонстрируют два подхода:

  • on-premises резервные копии создаются и хранятся на базе собственного ЦОД предприятия;
  • гибридная модель on-premises + cloud tier на стороне клиента хранятся только актуальные резервные копии, которые могут понадобиться здесь и сейчас для восстановления работоспособности производственной среды, тогда как более старые бэкапы автоматически переносятся в облако.


Каждый из них обладает своими преимуществами. Комбинация self-hosted и облачных решений позволяет без труда масштабировать IT-инфраструктуру по мере необходимости благодаря подключению объектных хранилищ Amazon S3, Azure Blob Storage, IBM Cloud Object Storage, или любых других S3-совместимых сервисов, и дополнительно экономить на долговременном хранении данных, также оставляя возможность для disaster recovery в случае возникновения аварийных ситуаций. On-premises же гарантирует быстрое восстановление любых когда-либо созданных резервных копий, независимость от внешних факторов, высокий уровень приватности и соответствие местному законодательству в том случае, если деятельность компании так или иначе связана с обработкой персональных данных клиентов.

Проще всего продемонстрировать эффективность связки программного обеспечения Veeam и гибридных хранилищ Western Digital на конкретных примерах. Мы выбрали два наиболее показательных кейса из нашей обширной практики.

Кейс 1


Клиент

В роли заказчика выступил крупный европейский производитель бытовых товаров с годовым оборотом более 500 миллионов евро, офисы и производственные мощности которого расположены в разных странах ЕС и в Китае. Штат компании насчитывает около 1800 постоянных сотрудников, а IT-инфраструктура представлена 8 центрами обработки данных по всему миру.

Проблема

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

Поиск решения

Специалисты IT-отдела заказчика пришли к выводу, что обновление существующей инфраструктуры резервного копирования является нерентабельным, в связи с чем было принято решение о переходе на новую архитектуру, что позволило бы не только сэкономить, но и решить проблему масштабирования в будущем. Для организации системы резервного копирования было выбрано гибридное хранилище Ultrastar Data60 от Western Digital, управляемое программным обеспечением Veeam Backup & Replication 9.5, Veeam Backup для Microsoft Office 365 и Microsoft Windows Storage Spaces (входит в состав Windows Server 2016).

Конфигурация

Итоговая аппаратная конфигурация состояла из сервера HPE Proliant DL360 G9, оснащенного парой контроллеров Broadcom 9480-8i8e MegaRAID, обслуживающих модули ввода-вывода Ultrastar Data60. Каждый RAID-контроллер был подключен к назначенному порту I/O-модуля с помощью 4-канального HD MiniSAS-кабеля (P/N 1EX0329), обеспечивая полосу пропускания до 9,6 ГБ/с на контроллер.


Серверная платформа HPE Proliant DL360 G9

Дисковое хранилище было развернуто с 60-ю 12-терабайтными SAS HDD Ultrastar таким образом, его общая емкость составила 720 ТБ. С помощью зонирования T10, Ultrastar Data60 был логически разделен на две зоны по 30 дисков в каждой, так, чтобы каждый контроллер видел диски, назначенные только для определенных портов. В группах из 30 накопителей команда ИТ-специалистов создала несколько наборов томов с чередованием, которые были сгруппированы в единый общий том с помощью Windows Storage Spaces. Один из таких томов использовался для инкрементного резервного копирования, в то время как другой содержал полный образ резервной копии, который был дополнительно сжат с использованием функции дедупликации Windows Server.

Результаты

Связка 1 сервер + 2 RAID-контроллера + 1 Ultrastar Data60 обошлась заказчику существенно дешевле по сравнению с выделенным устройством резервного копирования, поддерживающим внутреннюю дедупликацию. В будущем данную платформу можно будет без труда масштабировать путем последовательного подключения новых дисковых полок (до четырех штук) без необходимости модернизации серверной платформы.

Кейс 2


Клиент


GreenPower крупное предприятие, специализирующееся на производстве натуральных витаминных комплексов и пищевых добавок. Компании принадлежит торговая марка Dr. Hittich, а ее штаб-квартира находится в Керкраде (Нидерланды).

Проблема

GreenPower нуждались в надежном и эффективном решении для резервного копирования. Изначально для этих целей использовались сервера на 24/36 отсеков, а общее дисковое пространство, отведенное под бэкапы, составляло 108 терабайт. Когда данного объема перестало хватать, перед компанией встала проблема масштабирования IT-инфраструктуры. Серверы хранения данных большей емкости оказались слишком дороги, поэтому от их приобретения пришлось отказаться. В свою очередь, идея с регулярной заменой заполненных дисков на пустые показала свою полную несостоятельность: такой подход не мог обеспечить нужный уровень доступности резервных копий, а ошибки при маркировке изъятых дисков регулярно приводили к сложностям при восстановлении данных и даже к их утрате.

Конфигурация

Было решено реализовать систему резервного копирования на базе двух серверов с программным обеспечением Veeam Backup & Replication 9.5 и двух дисковых полок Ultrastar Data60 от Western Digital. В каждое гибридное хранилище были установлены 60 SAS HDD Ultrastar емкостью 6, 8 и 10 терабайт.


Жесткие диски для ЦОД Ultrastar DC HC330 емкостью 10 терабайт

Жесткие диски были сконфигурированы в несколько наборов RAID-массивов, управляемых Windows Storage Spaces. Для дедупликации данных встроенными средствами программного обеспечения Microsoft было создано несколько виртуальных дисков типа Thin (такой подход позволил обойти ограничение в 64 ТБ). Как и в первом примере, доступное дисковое пространство было разделено на два логических тома, один из которых использовался для создания полных бэкапов, тогда как второй был предназначен для инкрементного резервного копирования.

Результаты

Переход на платформу хранения данных Ultrastar Data60 помог значительно снизить затраты на логистику, а в пересчете на терабайт информации, приобретение дисковых полок оказалось значительно более выгодным решением по сравнению с закупкой полноценных серверов: поскольку за счет использования функции дедупликации данных Microsoft Windows Server 2016 удается экономить около 1250 терабайт на каждые 378 ТБ физического дискового пространства, емкости одной такой полки с учетом текущих потребностей компании, хватит на 6 лет ежедневного создания резервных копий.

Не менее важным преимуществом оказалось и значительное повышение производительности системы резервного копирования: создание и восстановление бэкапов происходит на скорости не менее 1 ГБ/с. Это исключает возникновение ситуаций, когда Windows Server не успевает завершить дедупликацию данных в существующих резервных копиях до создания новых. Ранее подобные коллизии приводили к значительному снижению производительности всей системы, однако новая платформа позволила забыть о них раз и навсегда.
Подробнее..

Без изъянов тестируем самый производительный SSD Kingston KC2500

09.07.2020 10:15:09 | Автор: admin
Бурное развитие технологий Контроллеров SSD и NAND памяти обязывает производителей идти в ногу с прогрессом. Поэтому компания Kingston объявила о выходе нового SSD KC2500 со скоростями чтения до 3,5 Гбайт/сек, и записи до 2,9 Гбайт/сек.



Новинки представлены в четырех размерах от 250 ГБ до 2 ТБ и все они выполнены в форм-факторе М.2 2280, оснащены интерфейсом подключения PCI Express 3.0 x4 с протоколом NVMe 1.3 и поддерживают сквозную защиту данных с использованием 256-битного аппаратного шифрования AES. Шифрование применимо в корпоративной среде, учитывая поддержку TCG Opal 2.0 и Microsoft eDrive. Скоростные характеристики зависят от размера SSD:

o 250 Гб чтение до 3500 МБ/с, запись до 1200 МБ/с;
o 500 Гб чтение до 3500 МБ/с, запись до 2900 МБ/с;
o 1 ТБ чтение до 3500 МБ/с, запись до 2900 МБ/с;
o 2 ТБ чтение до 3500 МБ/с, запись до 2900 МБ/с;
Заявленный срок гарантийного обслуживая 5 лет.



Ядром любого NVMe накопителя является контроллер и Kingston продолжает использовать хорошо известный процессор Silicon Motion SM2262ENG. Естественно задействовано все 8 доступных контроллеру канала. А основное отличие от KC2000 это улучшенная прошивка, которая позволяет задействовать все резервы NAND памяти. И, собственного говоря, разогнанные микросхемы NAND памяти.



В комплект поставки входит сам SSD KC 2500 и ключ для активации утилиты Acronis True Image HD. С его помощью будет проще мигрировать на новый накопитель, сделав образ своего старого диска. Накопитель сконструирован в распространенном форм-факторе M.2 2280 и подойдет для установки в ПК и ноутбуки. Стандартное форматирование в среде Windows оставляет для пользователя 931 гигабайт свободного пространства. Схема расположение NAND памяти двухстороннее, а сам SSD позволяет на него установить дополнительное охлаждение, но как выяснится дальше, оно не является обязательным условием.

Методика тестирования


Топология строения SSD накопителей предусматривает использование буфера записи и чтения, а также многопоточность. Размер DRAM-кеша обычно бывает либо статичным, либо динамическим. В современных типичных SSD на контроллерах Silicon Motion зачастую устанавливают хитрый динамический DRAM-кеш, а управляет им прошивка. В контроллере и прошивке кроется основная хитрость. Чем лучше и прогрессивней используется контроллер и адаптивней прошивка под различные сценарии использования, тем быстрее SSD работает при условии наличия скоростной NAND-памяти.



Тестовый стенд включал в себя платформу Intel с материнской платой ASUS ROG Maximus XI Hero (Wi-Fi), процессором Intel Core i7 9900K, видеокартой ASUS Radeon RX 5700, 16 Гб памяти DDR4-4000 и операционной системой Windows 10 X64 (сборка 19041).

Результаты тестирования


AS SSD Benchmark
o Тестирование проводилось данными объемом 10 ГБ;
o Тест последовательного чтения / записи;
o Тест случайного чтения / записи к 4 Кб блоков;
o Тест случайного чтения / записи 4 Кб блоков (Глубина очереди 64);
o Тест измерения времени доступа чтения / записи;
o Итоговый результат в условных единицах;
o Copy Benchmark оценивает скорость работы и затраченного на это времени при копировании разных групп файлов (ISO образ, папка с программами, папка с играми).



CrystalDiskMark
o Тестирование проводилось с 5 повторениями, каждый объемом 16 ГБ и 1 ГБ.
o Последовательное чтение/запись с глубиной 8.
o Последовательное чтение/запись с глубиной 1.
o Случайное чтение/запись блоками по 4 кб с глубиной 32 и 16 потоков.
o Случайное чтение/запись блоками по 4 кб с глубиной 1.





HD Tune Pro 5.75
o Линейная скорость чтения и записи блоками 64 Кбайт.
o Врем доступа.
o Расширенные тесты чтения и записи
o Тесты работы с различным размером блока, а также реальная скорость на 16 Гб файле.



PCMark 10 Storage
o Quick System Drive Benchmark: короткий тест, эмулирующий легкую нагрузку на систему хранения. Используются наборы тестов, повторяющие реальные действия системы и программ с накопителем;
o Data Drive Benchmark: повторяет нагрузку на систему хранения в виде наборов тестов для NAS, (хранение и использование файлов различного типа);



Нагрев при последовательной записи




Стандартная процедура записи на SSD KC2500 позволяет оценить степень нагрева устройства без активного охлаждения. Вы вряд ли удивитесь, если мы вам скажем, что, нагрев высокопроизводительных SSD является краеугольным камнем. Относительно этой проблемы бьются инженеры и стараются не заводить SSD в критические режимы. Простейший подход подразумевает установку радиатора (докупается отдельно, либо используется система охлаждения материнской платы), либо вводится режим пропуска очередей записи для разгрузки контроллера. При этом производительность снижается, но SSD не перегревается. Такая же схема работает на процессорах, когда при чрезмерном нагреве он пропускает такты. Но в случае с процессором, пропуски не будут столь заметны пользователю, как с SSD. Ведь нагревшись выше заложенного конструкторами температуры, SSD будет пропускать слишком много тактов. А это в свою очередь вызовет фризы в операционной системе. К счастью, в Kingston KC2500 прошивка адаптирована таким образом, чтобы во время записи контроллер отдыхал в момент истощения DRAM-кеша. При любой задаче записи сначала заканчивается буфер, происходит разгрузка контроллера, потом данные снова попадают в буфер и запись продолжается с прежней скоростью без продолжительной остановки. Температура в 72С близка к критической, но сам тест проходил в неблагоприятных условиях: SSD был расположен в близости от видеокарты и лишен радиатора материнской платы. Установка же радиатора, которым комплектуется материнская плата, позволила снизить температуру до 53-55С. Стикер SSD не снимался, а в качестве теплопроводящего материала использовалась термопрокладка материнской платы. К тому же размер радиатора ASUS ROG Maximus XI Hero не столь велик, а соответственно обладает лишь средней эффективностью по отводу тепла. Стоит учесть, что, вынеся Kingston KC2500 на отдельную плату-переходник PCIe и доукомплектовав его радиатором, об температурных режимах можно будет и вовсе забыть.

Динамический кеш


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



Для примера попробуем заполнить весь диск файлом со случайными данными. Этот файл содержит сжимаемые и не сжимаемые данные различными блоками. Теоретически, быстрого буфера должно хватить на 100-200 ГБ, однако как видите результат, вышел иной. Значимое падение линейной записи нарисовалось только у 400+ ГБ отметке, что нам говорит о сложном алгоритме управления записи прошивкой. На этом этапе становится понятно, куда были потрачены человеко-часы при создании KC2500. Таким образом, SLC-кеш на накопителе KC2500 действительно обладает динамическим распределением и зависит от множества факторов, но точно не ограничивается 150-160 ГБ.

Типы обращений к SSD ОС Windows 10


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



За почти 10 минут работы более 90% обращений были связаны с чтением файлов блоками 4К, и почти половина записей такими же блоками. Замечу, что файл подкачки в среде Windows был на усмотрение системы. В целом картина показывает, что важны для работы не столько скорость, сколько время отклика на мелкоблочных операциях. Причем объем этих операций не столь велик. Естественно, стоит задуматься о приобретении быстрого SSD под игры (загрузка самих игр и скорость записи обновлений также важны). А в качестве еще одной ремарки, приятно получать и высокую скорость линейного чтения/записи, когда речь идет о частом копировании или записи данных.

Выводы




Kingston KC2500 это продолжение популярной серии KC2000, на ускоренной памяти с прошивкой, адаптированной для настольных компьютеров. Улучшения коснулись и линейно скорости чтения, и записи. Был пересмотрен подход к SLC-кешу, он имеет больше степеней свободы и подстройки под различные сценарии. В качестве бонуса Kingston продолжает одаривать покупателей 5-летней гарантией, а также поддержкой 256-битным XTS-AES шифрованием.

Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.
Подробнее..

Не только размер имеет значениеили что нам принес новый протокол NVMe

17.07.2020 10:14:14 | Автор: admin
Известная история. Как только появляются более мощные компьютеры, как только возрастает производительность процессоров и емкость носителей данных, и пользователь с облегчением вздыхает теперь мне всего и на всё хватит, не придется ужиматься и экономить, так почти сразу появляются новые потребности, отбирающие всё больше ресурсов, новое ПО, которое тоже ни в чем себе не отказывает. Вечная проблема. Нескончаемый круговорот. И бесконечный поиск новых решений. Облачные хранилища, нейронные сети, искусственный интеллект даже трудно себе представить, каких гигантских мощностей требую эти технологии. Но не будем расстраиваться, ведь для любой задачи рано или поздно находится решение.



Одним из таких решений стал протокол NVM-express, который, как говорят специалисты, совершил революцию в использовании твердотельной энергонезависимой памяти. Что же такое NVMe и какие преимущества он принес с собой?


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

И вот на смену HDD пришли SSD твердотельные накопители, энергонезависимые немеханические запоминающие устройства. Первые накопители SSD появились на рынке во второй половине 2000-х. Довольно скоро они уже стали соперничать с жесткими дисками по объему. Но вот полностью раскрыть свой потенциал и преимущества в скорости, параллельности обращений к ячейкам долгое время не могли, потому что существующие интерфейсы и протоколы были построены по старым стандартам, призванным поддерживать накопители HDD через интерфейсы SATA и еще более древними SCSI (SAS).

Следующим шагом в раскрытии потенциала энергонезависимой памяти стал переход на шины PCI-express. Но для них к тому времени еще не были разработаны новые промышленные стандарты. И вот в 2012 году выпускаются первые компьютеры, в которых реализован протокол NVM-express.

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

Поэтому словосочетание накопитель NVMe не совсем корректное, а сравнение типа HDD SSD NVMe абсолютно ошибочное и вводит в заблуждение пользователя, который только знакомится с темой. Правильно сравнивать HDD с SSD с одной стороны, SSD, подключенный через интерфейс SATA (по протоколу AHCI) и SSD, подключенный через шину PCI-express с использованием протокола NVM-express, с другой. Сравнивать HDD с SSD, вероятно, уже мало кому интересно. Все понимают разницу, и всем хорошо известны преимущества последнего. Разве что отметить некоторые (весьма разительные) преимущества. По сравнению с жёсткими дисками твердотельные накопители имеют меньший размер и вес, являются беззвучными, а полное отсутствие механических приводов делает их многократно более устойчивыми к повреждениям (например, при падении) да и просто увеличивает срок службы.

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

Интерфейс SATA, как уже говорилось, создавался для жестких дисков, головка которых одновременно физически может получить доступ только к одной ячейке. Ничего удивительного, что в SATA-устройствах всего один канал. Для SSD этого плачевно мало, ведь одно из их преимуществ поддержка параллельных потоков. Контроллер SSD также управляет начальным позиционированием, что является еще одним существенным преимуществом. Шина PCI-express обеспечивает многоканальную работу, а протокол NVMe реализовывает это преимущество. В результате данные, хранящиеся на твердотельных накопителях, передаются через 65 536 параллельных очередей управления, каждая из которых может содержать одновременно более 65 536 команд. Сравните: SATA и SCSI могут использовать только одну очередь, поддерживающую до 32 и до 254 команд соответственно.

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

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

Многочисленные тесты, проведенные различными организациями и экспертами доказывают, что скорость работы SSD NVMe в среднем в 5 раз выше, чем при подключении SSD по старым интерфейсам.

Теперь о том, всем ли доступны SSD, реализованные на PCIe с протоколом NVMe. И речь идет не только о стоимости. По цене такая реализация пока еще заметно выше, хотя цены на компьютерные компоненты, как известно, высоки лишь в самом начале продаж и имеют тенденцию к довольно быстрому снижению.

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



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



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



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

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



На правах рекламы


VDS с NVMe SSD это именно про виртуальные серверы от нашей компании.
Уже давно используем исключительно быстрые серверные накопители от Intel, мы не экономим на железе, только брендовое оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить ;)

Подробнее..

Распределённые СУБД для энтерпрайза

24.07.2020 10:04:54 | Автор: admin
CAP-теорема является краеугольным камнем теории распределённых систем. Конечно, споры вокруг неё не утихают: и определения в ней не канонические, и строгого доказательства нет Тем не менее, твёрдо стоя на позициях бытового здравого смысла, мы интуитивно понимаем, что теорема верна.



Единственное, что не очевидно, так это значение буквы P. Когда кластер разделился, он решает то ли не отвечать, пока не будет набран кворум, то ли отдавать те данные, которые есть. В зависимости от результатов этого выбора система классифицируется либо как CP, либо как AP. Cassandra, например, может вести себя и так и так, в зависимости даже не от настроек кластера, а от параметров каждого конкретного запроса. Но если система не P, и она разделилась, тогда что?

Ответ на этот вопрос несколько неожиданный: CA-кластер не может разделиться.
Что же это за кластер, который не может разделиться?

Непременный атрибут такого кластера общая система хранения данных. В подавляющем большинстве случаев это означает подключение через SAN, что ограничивает применение CA-решений крупными предприятиями, способными содержать SAN-инфраструктуру. Для того, чтобы несколько серверов могли работать с одними и теми же данными, необходима кластерная файловая система. Такие файловые системы есть в портфелях HPE (CFS), Veritas (VxCFS) и IBM (GPFS).

Oracle RAC


Опция Real Application Cluster впервые появилась в 2001 году в релизе Oracle 9i. В таком кластере что несколько экземпляров сервера работают с одной и той же базой данных.
Oracle может работать как с кластерной файловой системой, так и с собственным решением ASM, Automatic Storage Management.

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

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



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

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

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

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

Правильное использование Oracle RAC физическое деление данных (например, при помощи механизма секционированных таблиц) и обращение к каждому набору секций через выделенный узел. Главным назначением RAC стало не горизонтальное масштабирование, а обеспечение отказоустойчивости.

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

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

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

IBM Pure Data Systems for Transactions


Кластерное решение для СУБД появилось в портфеле Голубого Гиганта в 2009 году. Идеологически оно является наследником кластера Parallel Sysplex, построенным на обычном оборудовании. В 2009 году вышел продукт DB2 pureScale, представляющий собой комплект программного обеспечения, а в 2012 года IBM предлагает программно-аппаратный комплект (appliance) под названием Pure Data Systems for Transactions. Не следует путать его с Pure Data Systems for Analytics, которая есть не что иное, как переименованная Netezza.

Архитектура pureScale на первый взгляд похожа на Oracle RAC: точно так же несколько узлов подключены к общей системе хранения данных, и на каждом узле работает свой экземпляр СУБД со своими областями памяти и журналами транзакций. Но, в отличие от Oracle, в DB2 есть выделенный сервис блокировок, представленный набором процессов db2LLM*. В кластерной конфигурации этот сервис выносится на отдельный узел, который в Parallel Sysplex называется coupling facility (CF), а в Pure Data PowerHA.

PowerHA предоставляет следующие сервисы:

  • менеджер блокировок;
  • глобальный буферный кэш;
  • область межпроцессных коммуникаций.

Для передачи данных от PowerHA к узлам БД и обратно используется удалённый доступ к памяти, поэтому кластерный интерконнект должен поддерживать протокол RDMA. PureScale может использовать как Infiniband, так и RDMA over Ethernet.



Если узлу нужна страница, и этой страницы нет в кэше, то узел запрашивает страницу в глобальном кэше, и только в том случае, если и там её нет, читает её с диска. В отличие от Oracle, запрос идёт только в PowerHA, а не в соседние узлы.

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

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

Грязные, то есть изменённые, страницы могут быть записаны на диск как с обычного узла, так и с PowerHA (castout).

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

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

Внутренние тесты IBM на нагрузке, состоящей из 90% чтения и 10% записи, что очень похоже на реальную промышленную нагрузку, показывают почти линейное масштабирование до 128 узлов. Условия тестирования, увы, не раскрываются.

HPE NonStop SQL


Своя высокодоступная платформа есть и в портфеле Hewlett-Packard Enterprise. Это платформа NonStop, выпущенная на рынок в 1976 году компанией Tandem Computers. В 1997 году компания была поглощена компанией Compaq, которая, в свою очередь, в 2002 году влилась в Hewlett-Packard.

NonStop используется для построения критичных приложений например, HLR или процессинга банковских карт. Платформа поставляется в виде программно-аппаратного комплекса (appliance), включающего в себя вычислительные узлы, систему хранения данных и коммуникационное оборудование. Сеть ServerNet (в современных системах Infiniband) служит как для обмена между узлами, так и для доступа к системе хранения данных.

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

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

Начиная с 1987 года на платформе NonStop работает реляционная СУБД сначала SQL/MP, а позже SQL/MX.

Вся база данных делится на части, и за каждую часть отвечает свой процесс Data Access Manager (DAM). Он обеспечивает запись данных, кэшировние и механизм блокировок. Обработкой данных занимаются процессы-исполнители (Executor Server Process), работающие на тех же узлах, что и соответствующие менеджеры данных. Планировщик SQL/MX делит задачи между исполнителями и объединяет результаты. При необходимости внести согласованные изменения используется протокол двухфазной фиксации, обеспечиваемый библиотекой TMF (Transaction Management Facility).



NonStop SQL умеет приоритезировать процессы так, чтобы длинные аналитические запросы не мешали исполнению транзакций. Однако её назначение именно обработка коротких транзакций, а не аналитика. Разработчик гарантирует доступность кластера NonStop на уровне пять девяток, то есть простой составляет всего 5 минут в год.

SAP HANA


Первый стабильный релиз СУБД HANA (1.0) состоялся в ноябре 2010 года, а пакет SAP ERP перешёл на HANA с мая 2013 года. Платформа базируется на купленных технологиях: TREX Search Engine (поиска в колоночном хранилище), СУБД P*TIME и MAXDB.

Само слово HANA акроним, High performance ANalytical Appliance. Поставляется эта СУБД в виде кода, который может работать на любых серверах x86, однако промышленные инсталляции допускаются только на оборудовании, прошедшем сертификацию. Имеются решения HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Некоторые конфигурации Lenovo допускают даже эксплуатацию без SAN роль общей СХД играет кластер GPFS на локальных дисках.

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



Каждый узел кластера HANA отвечает за свою часть данных, а карта данных хранится в специальном компоненте Name Server, расположенном на узле-координаторе. Данные между узлами не дублируются. Информация о блокировках также хранится на каждом узле, но в системе есть глобальный детектор взаимных блокировок.

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

Узел-координатор дублирован, поэтому в случае выхода координатора из строя в работу немедленно вступает резервный узел. А вот если выходит из строя узел с данными, то единственный способ получить доступ к его данным перезапустить узел. Как правило, в кластерах HANA держат резервный (spare) сервер, чтобы как можно быстрее перезапустить на нём потерянный узел.
Подробнее..

Карты памяти Kingston Canvas Plus с космическими скоростями

08.07.2020 14:22:16 | Автор: admin
Популяризация FullHD и 4К контента ставит новые требования к флеш-картам. Современные видеоролики требуют от накопителей скорости жестких дисков. Еще недавно линейные показатели HDD находились на уровне 100-150 Мбайт/сек, сегодня SD-карты с легкостью их превосходят. Встречаем новые поколения скоростных SD-карт от Kingston.



Зачем картам такие скорости?


Вопрос из разряда риторических. Возьмём обычный пример: зеркальная камера не первой свежести и последовательная непрерывная съемка В таком случае камеры заполнит свой внутренний буфер и постарается записать его на карту. Для этого ей нужна либо быстрая флешка, либо вы ждете, пока сольется буфер на карту. В теории и на практики камеры достаточно быстро записывают, но им нужна скоростная карта памяти. Старичок Nikon D800 делает фотографии в несжатом виде на 50-60 Мб. D850 уже оперирует размерами под 100 МБ. Так что перекинуть буфер, состоящий из десятка фотографий, потребует от карты памяти максимальные скорости. В среднем карты умеют записывать со скоростью 40-50 МБ/сек. Значит, для переброса 500-1000 МБ вы зависните в режиме ожидания до 25 секунд. В это время воспользоваться камерой вы не сможете, т.к. буфер будет полный. Или еще пример из разряда любителей снимать видео: те же камеры пишут в HD или 4К разрешении, выдавая постоянный поток до 144 Мбит/сек. В пересчете на привычные мегабайты это до 18-20 МБ/сек. Вроде бы не много, или меньше, чем размер записи буфера на карту. Но, серийная непрерывная съемка производится длительностью в несколько секунд, а потом вы ищите новую цель, видео же снимается не меньше десятка секунд, а чаще минутами. Ваша карта должна быть способна постоянно писать со скоростью не менее 20 МБ/сек на протяжении минут! Отдельной статьей идут камеры с потоками до 400 Мбит/сек. Для них выбор носителя крайне важный момент. Замешкаетесь или поверите производителям 3-5 эшелона на слово и разочаруетесь пропусками кадров при съемке видео.

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

Скоростные SD-карты Kingston


Canvas React Plus Kit емкостью 128 Гбайт (MLPMR2/128GB), форм-фактора microSD с кардридером USB->MicroSD и переходником MicroSD->SD.


o В комплекте поставляется устройство для чтения карт памяти MobileLite Plus microSD Reader;
o Класс 10, UHS-II, U3, V90, A1;
o Поддержка приложений A1 для Android;
o 285/165МБ/с для операций чтения/записи;

Canvas React Plus Kit емкостью 64 Гбайт (MLPR2/64GB), форм-фактора SD с кардридером UHS-II USB->SD.

o Устройство для чтения карт памяти MobileLite Plus SD Reader входит в комплект поставки;
o Класс 10, UHS-II, U3, V90;
o 300/260МБ/с для операций чтения/записи;

Canvas Go! Plus SD емкостью 64 Гбайт (SDG3/64GB), форм-фактора SD.


o Класс 10, UHS-I, U3, V30;
o 170/70МБ/с для операций чтения/записи;

Форматы карт и стандарты


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

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

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

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


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

Форм-фактор SD


Здесь все просто! Существует три размера карт, а наиболее распространенными остались два: microSD и SD. Первые устанавливаются в телефоны, планшеты, видеорегистраторы, экшн-камеры и через переходники в остальные устройства. Вторые, SD, чаще попадаются в фотоаппаратах и видеокамерах.

Слева карта SD формата, справа microSD.

Различия в объеме


Даже в таком простом вопросе как объем, ассоциация придумала 4 вида форматов. Это связано и с доступным для пользователя местом и поддержкой файловой системой.

До 2 Гбайт SD-карты SDSC (Стандартной емкости, FAT16)
От 2 Гбайт до 32 Гбайт SD-карты SDHC (Высокой емкости, FAT32)
До 2 Тбайт SD-карты SDXC (Расширенной емкости, exFAT)
От 2 до 128 Тбайт SD-карты SDUC (Ультраемкости, exFAT)

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

Классы скорости


SD Association за свою историю ввела с десяток обозначений скорости карт, разграничив их по сферам применения. Обычный класс скорости делится на 4 подкласса: C2, C4, C6, C10. Он обозначает минимальную скорость линейной записи в Мбайт/сек. Современные SD-карты почти все соответствуют C10.

UHS класс скорости


Подразделяется на 2 категории: UHS Speed Class 1 и UHS Speed Class 3.
UHS Speed Class 1 обозначает минимальную скорость линейной записи не менее 10 Мбайт/сек;
UHS Speed Class 3 обозначает минимальную скорость линейной записи не менее 30 Мбайт/сек;

Шина обмена данными


Еще один параметр максимальной пропускной способности, но теперь он говорит нам о поддерживаемом соединении между клиентом и картой. Для UHS-II характерно 2 ряда контактов, для UHS-I один.

UHS-I скорость полудуплексного режима передачи данных до 104 Мбайт/сек;
UHS-II скорость полудуплексного режима передачи данных до 312 Мбайт/сек;
UHS-III скорость полудуплексного режима передачи данных до 624 Мбайт/сек;

Класс скорости записи видео


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

V6 скоростью последовательной записи выше 6 Мбайт/сек;
V10 скоростью последовательной записи выше 10 Мбайт/сек;
V30 скоростью последовательной записи выше 30 Мбайт/сек;
V60 скоростью последовательной записи выше 60 Мбайт/сек;
V90 скоростью последовательной записи выше 90 Мбайт/сек;

Класс использования для приложений


Относительно новый класс, говорящий об адаптации карты для работы с приложениями. Теоретически зерно мудрости в этом стандарте есть, но ему часто преувеличивают значимость. Дело в том, что принято считать работу приложений требовательной к частым, случайным запросам чтения и записи. Сложно судить, но давайте посмотрим на заявление объективно. Операционная система iOS сразу отпадает, т.к. Apple ликвидировал даже намеки на поддержку карт памяти в своих устройствах. Android смартфоны и планшеты другое дело. Но и здесь некоторые производители навязывают свой интерфейс, например, топовые телефоны Huawei. Остальные пока держатся группой и встраивают в смартфоны лоток с картой, но опять же, установка второй сим-карты официально лишает вас возможности использовать дополнительную память. В целом пользователи чаще переносят на SD-карту нетребовательные и емкие приложения: запись фото/видео, карты, навигацию и т.п. А они работают по принципу линейной записи или чтения. В общем, не так и часто встречаются повышенные требования к картам на случайные операции с малыми объемами.

A1 минимальная скорость случайного чтения, не менее 1500 IOPS, минимальная скорость случайной записи, не менее 500 IOPS, минимальная скорость линейной записи, не менее 10 Мбайт/сек;
A2 минимальная скорость случайного чтения, не менее 4000 IOPS, минимальная скорость случайной записи, не менее 2000 IOPS, минимальная скорость линейной записи, не менее 10 Мбайт/сек;



Фактический размер карт


Canvas React Plus Kit емкостью 128 Гбайт (MLPMR2/128GB), форм-фактора microSD с кардридером USB->MicroSD и переходником MicroSD->SD.


После форматирования в exFAT емкость составила 119,37 Гбайт.

Canvas React Plus Kit емкостью 64 Гбайт (MLPR2/64GB), форм-фактора SD с кард ридером UHS-II USB->SD.


После форматирования в exFAT емкость составила 59,73 Гбайт.

Canvas Go! Plus SD емкостью 64 Гбайт (SDG3/64GB), форм-фактора SD.


После форматирования в exFAT емкость составила 57,97 Гбайт.

Методика тестирования


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

Тестовый стенд включал в себя современную платформу AMD с материнской платой ASUS ROG Strix TRX40-E Gaming, процессором AMD Ryzen Threadripper 3970X, портами USB 3.2 Gen2, видеокартой ASUS Radeon RX 5700, 16 Гб памяти Kingston DDR4-4000. Карты устанавливались в комплектные кард-ридеры. Тест Canvas Go! Plus SD происходил совместно с устройством для чтения карт памяти MobileLite Plus SD Reader.

Карты памяти форматировались утилитой SD Memory Card Formatter 5.00, разработанной SD Association.

Результаты тестирования


AS SSD Benchmark

Слева направо: Canvas React Plus Kit емкостью 128 Гбайт (MLPMR2/128GB), Canvas React Plus Kit емкостью 64 Гбайт (MLPR2/64GB), Canvas Go! Plus SD емкостью 64 Гбайт (SDG3/64GB).
o Тест последовательного чтения / записи;
o Тест случайного чтения / записи к 4 Кб блоков;
o Тест случайного чтения / записи 4 Кб блоков (Глубина очереди 64);
o Тест измерения времени доступа чтения / записи;
o Итоговый результат в условных единицах;
o Copy Benchmark оценивает скорость работы и затраченного на это времени при копировании разных групп файлов (ISO образ, папка с программами, папка с играми).



CrystalDiskMark

o Последовательное чтение/запись с глубиной 8.
o Последовательное чтение/запись с глубиной 1.
o Случайное чтение/запись блоками по 4 кб с глубиной 32 и 16 потоков.
o Случайное чтение/запись блоками по 4 кб с глубиной 1.

Слева направо: Canvas React Plus Kit емкостью 128 Гбайт (MLPMR2/128GB), Canvas React Plus Kit емкостью 64 Гбайт (MLPR2/64GB), Canvas Go! Plus SD емкостью 64 Гбайт (SDG3/64GB)



HD Tune Pro 5.75
o Линейная скорость чтения и записи блоками 64 Кбайт.
o Врем доступа.
o Расширенные тесты чтения и записи
o Тесты работы с различным размером блока, а также реальная скорость на 16 Гб файле.
Слева направо: Canvas React Plus Kit емкостью 128 Гбайт (MLPMR2/128GB), Canvas React Plus Kit емкостью 64 Гбайт (MLPR2/64GB), Canvas Go! Plus SD емкостью 64 Гбайт (SDG3/64GB).







H2Test
o Позволяет оценить среднюю скорость чтения и записи на диск, выдавая информацию в Мбайт/сек.

Слева направо: Canvas React Plus Kit емкостью 128 Гбайт (MLPMR2/128GB), Canvas React Plus Kit емкостью 64 Гбайт (MLPR2/64GB), Canvas Go! Plus SD емкостью 64 Гбайт (SDG3/64GB).



Выводы


Canvas React Plus Kit емкостью 128 Гбайт (MLPMR2/128GB)


Дорогая microSD карта для требовательных потребителей. В комплекте идет скоростной переходник для быстрого чтения с карты по USB. Будьте внимательны, SD->microSD поддерживает стандарт UHS-I, при использовании его скорость будет ограничена. Карта обеспечивает феноменальные скорости для своего класса: скорость линейного чтения 267-290 Мбайт/сек, записи 218-228 Мбайт/сек. На случайных операциях развивает от 2,8 до 12,6 Мбайт/сек. Минимальная цена на Яндекс.Маркете от 7150 рублей на июнь 2020 года в г. Москве. Согласно тестам Canvas React Plus Kit весьма универсальная SD-карты. Ее показатели говорят о хорошей приспособленности для работы и в качестве системы хранения данных на мобильных телефонах (карты, навигация, фото, видео), и для высокого битрейта для записи видео. Именно универсальность для различных задач совместно с высокими скоростями чтения и записи выделяет Canvas React Plus Kit.

Canvas React Plus Kit емкостью 64 Гбайт (MLPR2/64GB)

Исходя из результатов тестов для этой карты работа сосредоточена на фото и видеозаписи. Она не слишком подходит для записи мелкими блоками, а раскрытие потенциала происходит на блоках 512 килобайт и выше. При этом чтение у нее быстрое начиная с 128 килобайт блоков, но сильной стороной Canvas React Plus Kit в форм-факторе SD является потоковая запись (более 250 МБ/сек). Скорость стабильна на протяжении всего объема 64 ГБ. Сколько бы вы не заполняли и стирали данных, Canvas React Plus Kit всегда выдает 250 Мбайт/сек на запись.
Минимальная цена на Яндекс.Маркете от 4300 рублей на июнь 2020 года в г. Москве.

Canvas Go! Plus SD емкостью 64 Гбайт (SDG3/64GB)

Хорошая цена и высокие показатели. Canvas Go! Plus SD емкостью 64 Гбайт показала, что и доступные карты способны на многое. Скорость линейного чтения 175-184 Мбайт/сек, записи 70-77 Мбайт/сек. На случайных операциях развивает от 3,9 до 8,3 Мбайт/сек. В целом Canvas Go! Plus SD универсальная карта как для быстрого чтения различными блоками, так и записи. Удачно впишется в любой фотоаппарат или экшн-камеру со средними характеристиками битрейта. Минимальная цена на Яндекс.Маркете от 1460 рублей на июнь 2020 года в г. Москве. Подойдет даже для записи видео V60, т.е. прекрасно справится с битрейтом до 500-550 Мбит.

Новые карты памяти Kingston Canvas Plus уже в продаже и доступны в магазинах-партнеров.

Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.
Подробнее..

Организация разработки в изолированной сети как управлять зависимостями?

30.07.2020 10:07:11 | Автор: admin

Всем привет,


Наша компания занимается разработкой CUBA Open Source Java фреймворка для разработки корпоративных приложений. Платформа CUBA это целая экосистема, которая включает в себя сам фреймворк и разнообразные аддоны, предоставляющие прикладной функционал, готовый к использованию в несколько кликов. За последние несколько лет фреймворк сильно набрал популярность и сейчас используется более 20 000 разработчиками по всему земному шару. С ростом популярности мы сталкивались с множеством интересных кейсов и в этой статье хотим затронуть один из них. Возможно, этот материал поможет в вашей практике, особенно если вы работаете в организации, в которой вопросы безопасности больно бьют по рукам разработчиков.


image


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


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


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


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


Но что делать в случае, если публичные репозитории недоступны из внутренней сети?


Возможные варианты решения проблемы


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


Что же нам остается?


  • Вариант 0. Упрашивание безопасников.
  • Вариант 1. Шлюз.
  • Вариант 2. Ручное управление зависимостями.

Вариант 0 рассматривать не будем, рассмотрим вариант 1 и 2.


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


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


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


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


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

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


Как мы предлагаем решать эти проблемы?


CUBA SDK


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


В чем отличие CUBA SDK от оффлайн плагинов для Gradle или Maven?
Главное отличие CUBA SDK не кэширует зависимости конкретного проекта, а позволяет синхронизировать артефакты между внешними и внутренними репозиториями, чтобы разработчикам было комфортно создавать и разрабатывать приложения в закрытой сети.
CUBA SDK не требует проекта и позволяет создать необходимый оффлайн стек фреймворков, аддонов и библиотек со всеми зависимостями.


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


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


image


CUBA SDK позволяет с помощью нескольких консольных команд определять все зависимости для артефактов и заливать их в нужные репозитории. Для полностью закрытых сетей можно использовать команды импорта и экспорта или установить CUBA SDK на шлюз.


Преимущества использования CUBA SDK:


  • автоматически собирает все зависимости с исходным кодом для загружаемых библиотек
  • определяет зависимости для платформы и аддонов CUBA Platform
  • проверяет и устанавливает новые версии библиотек
  • может работать одновременно с несколькими репозиториями для поиска артефактов, включая локальные maven репозитории
  • имеет встроенный Nexus OSS репозиторий артефактов
  • даёт возможность загрузки артефактов одновременно в несколько репозиториев, включая локальные maven
  • производит импорт и экспорт артефактов со всеми зависимостями
  • предоставляет интерактивный режим с подсказками для установки платформы и аддонов CUBA Platform
  • использует механизмы Gradle для определения зависимостей
  • не зависит от IDE
  • может быть установлен на CI сервере

Команды SDK


Полный список доступных команд можно посмотреть на странице GitHub.


CUBA SDK изначально поддерживает три типа компонентов: CUBA Framework, CUBA addon и библиотека, которая может быть загружена через maven координаты. Этот список может быть расширен для других типов компонентов через плагины для CUBA SDK.


Установка компонента в удаленный репозиторий может быть выполнена через команду install. При создании SDK мы предусмотрели вариант, когда SDK может быть установлен на шлюзовом компьютере или на переносном носителе, в этом случае установку компонентов можно сделать через команды resolve и push.


resolve просто определяет и скачивает все зависимости в локальный кэш SDK
push заливает уже скачанные артефакты с зависимостями в настроенные target репозитории


Для работы с репозиториями в SDK есть встроенный менеджер репозиториев.
Менеджер репозиториев поддерживает локальные и удаленные репозитории, которые в SDK разделены на две группы:


  • source это репозитории, которые будут использоваться для поиска артефактов
  • target репозитории, в которые нужно будет залить эти артефакты

SDK сам может использоваться как репозиторий, для этого с помощью команды setup-nexus SDK скачивает, устанавливает и настраивает репозиторий Nexus OSS. Для запуска и остановки репозитория используются команды start и stop.


Для проверки и установки обновлений достаточно выполнить команду check-updates.


Определение зависимостей


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


Maven как менеджер зависимостей


Поэтому мы решили использовать Apache Maven для определения транзитивных зависимостей компонентов.


Для этого в CUBA SDK скачивается дистрибутив maven в домашнюю папку SDK и через Java Runtime запускаются команды.


Например, с помощью команды


dependency:resolve -Dtransitive=true -DincludeParents=true -DoverWriteSnapshots=true -Dclassifier=<classifier> -f pom.xml

мы определяли все зависимости для компонентов, которые описаны в pom.xml, и эти компоненты автоматически скачивались в локальный кэш maven, после чего с помощью команды


org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy-file -Durl=<repository URL>

артефакты заливались в нужный репозиторий.


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


org.apache.maven.plugins:maven-dependency-plugin:3.1.1:get -Dartifact=<maven coordinates>

Для выполнения команд Maven в приложении CUBA SDK сгенерировался settings.xml файл. Он содержал список всех репозиториев, которые должны были использоваться для загрузки и выгрузки артефактов.


Gradle как менеджер зависимостей


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


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


Для вызова задач Gradle используется Gradle Tooling API.


Для определения пути к зависимостями через Gradle мы используем artifact resolution query API. Следующий код позволяет получить путь к исходникам библиотеки:


 def component = project.dependencies.createArtifactResolutionQuery()            .forComponents(artifact.id.componentIdentifier)            .withArtifacts(JvmLibrary, SourcesArtifact)            .execute()            .resolvedComponents[0] def sourceFile = component?.getArtifacts(SourcesArtifact)[0]?.file

Таким образом, мы получили пути ко всем файлам в локальном кэше Gradle и сохраняли их в хранилище SDK.


Для загрузки в локальный кэш и определения зависимостей для компонентов мы добавляем компоненты в конфигурацию и через lenientConfiguration получаем все зависимости.


project.ext.properties["toResolve"].tokenize(';').each {            dependencies.add 'extraLibs', it        }        def resolved = [:]        configurations.all.collect {            if (it.canBeResolved) {                it.resolvedConfiguration.lenientConfiguration.artifacts.each { art ->                    try {                        ...                    } catch (e) {                        logger.error("Error: " + e.getMessage(), e)                        logger.error("could not find pom for {}", art.file)                    }                }            }        }

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


Для загрузки артефактов в репозитории SDK использует PublishToMavenRepository задачу Gradle.


task publishArtifact(type: PublishToMavenRepository) {    doLast {        if (project.ext.hasProperty("toUpload")) {            def toUpload = new JsonSlurper().parseText(project.ext.properties["toUpload"])            def descriptors = new JsonSlurper().parseText(project.ext.properties["descriptors"])            artifactId toUpload.artifactId            groupId toUpload.groupId            version toUpload.version            descriptors.each { descriptor ->                artifact(descriptor.filePath) {                    classifier descriptor.classifier.type                    extension descriptor.classifier.extenstion                }            }        }    }}

В результате использования Gradle мы избавились от конфликтов при определении транзитивных зависимостей и заметно ускорили работу приложения.


Сборка проекта


Для сборки CUBA SDK мы использовали тот же подход, что и для CUBA CLI. Мы с помощью инструмента jlink собирали все необходимые модули в кастомную JRE, которая поставляется вместе с приложением. Это позволило сделать SDK независимым от установленной на компьютерах пользователей Java. Пример такой сборки можно посмотреть в CLI Core Sample проекте.


Поддержка сторонних плагинов


Так как CUBA SDK построен на основе библиотеки CLI Core, CUBA SDK поддерживает сторонние плагины. С помощью системы плагинов сейчас в SDK реализованы maven и gradle менеджеры зависимостей компонентов и провайдеры для CUBA компонентов.


Рассмотрим пример, как мы можем расширить функционал SDK с помощью плагина. В данном примере мы напишем провайдер для стартеров Spring Boot из хорошо известного Spring Initializr.


Для начала создадим новый проект, для примера возьмем плагин для CUBA CLI, как описано здесь, и добавим зависимости:


implementation "com.haulmont.cli.core:cli-core:1.0.0"implementation "com.haulmont.cli.sdk:cuba-sdk:1.0.1"

Создадим новый провайдер для стартеров spring boot SpringBootProvider, который наследуем от BintraySearchComponentProvider. BintraySearchComponentProvider позволяет автоматически находить доступные версии компонентов, используя Bintray API.


class SpringBootProvider : BintraySearchComponentProvider() {   var springComponentsInfo: SpringComponentsInfo? = null   override fun getType() = "boot-starter"   override fun getName() = "Spring boot starter" ...   override fun load() {       springComponentsInfo = Gson().fromJson(readSpringFile(), SpringComponentsInfo::class.java)   }   private fun readSpringFile(): String {       return SpringComponentsPlugin::class.java.getResourceAsStream("spring-components.json")           .bufferedReader()           .use { it.readText() }   }

Этот провайдер будет искать доступные компоненты из файла spring-components.json, который является json версией yml файла приложения Spring Initializr.


Для маппинга из json в объекты создадим простые data классы:


data class SpringComponent(   val name: String,   val id: String,   val groupId: String?,   val artifactId: String?,   val description: String?,   val starter: Boolean? = true)data class SpringComponentCategory(   val name: String,   val content: List<SpringComponent>)data class SpringInitializr(   val dependencies: List<SpringComponentCategory>)data class SpringComponentsInfo(   val initializr: SpringInitializr)

Для того, чтобы добавить наш провайдер к остальным провайдерам SDK, нужно в init событии плагина зарегистрировать провайдер:


class SpringBootComponentsPlugin : CliPlugin {   private val componentRegistry: ComponentRegistry by sdkKodein.instance<ComponentRegistry>()   @Subscribe   fun onInit(event: InitPluginEvent) {       val bootProvider = SpringBootProvider()       componentRegistry.addProviders(bootProvider)       bootProvider.load()   }}

Все готово. Теперь, чтобы установить наш плагин в терминале или через IDE, нужно выполнить команду gradle installPlugin.


Запустим SDK
image


Видим, что наш плагин успешно загрузился. Теперь проверим, что вся наша логика работает с помощью команды resolve boot-starter:


image


image


Как видим, подсказки для компонентов и их версий успешно заработали.


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


Исходный код тестового плагина можно найти на странице GitHub.


Заключение


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


Если вы самоизолировались в глухой деревне или летите 8 часов в самолете и не готовы платить по 300 евро за 10 мегабайт трафика, то CUBA SDK отличное решение, которое позволит собрать актуальный стек используемых библиотек и фреймворков локально у вас на компьютере.

Подробнее..

Western Digital начинает поставки корпоративных HDD объемом до 20 ТБ

10.07.2020 14:07:02 | Автор: admin


Компания Western Digital анонсировала выход сразу нескольких моделей емких HDD для корпоративного использования. Обновление получили линейки Gold и Ultrastar. В первом случае диски уже можно купить, во втором речь идет об анонсе новых моделей, которые станут доступны не ранее следующего квартала.

WD Gold это носители для корпоративных систем хранения данных. Рядовой пользователь тоже может их приобрести, но позиционируются они как серверные. Линейка жестких дисков Gold поддерживает только интерфейс SATA. Производитель дает на них пятилетнюю гарантию.

Линейка пополнилась моделями на 16 ТБ и 18 ТБ. Скорость передачи данных для моделей объемом в 16 ТБ составляет 262 Мбайт/с, для устройств на 18 ТБ этот показатель чуть выше 269 Мбайт/с. Кэш-буфер у обеих моделей 512 Мбайт. Производитель заявляет, что срок безотказной работы обеих моделей 2,5 млн часов.


Вторая новость о расширении линейки жестких дисков Ultrastar DC моделями с емкостью 16 и 18 ТБ (HC550). Как и предыдущие HDD, они предназначены для использования в корпоративной среде. Их отличие от родственников поддержка не одного, а двух интерфейсов, не только SATA, но и SAS 12G. Скорость передачи данных у моделей емкостью 16 и 18 ТБ 250 МБайт/с и 257 МБайт/с соответственно.


В этих HDD используется технология CMR (Conventional Magnetic Recording), то есть данные хранятся в параллельных дорожках без перекрытия. Последнее актуально для технологии SMR (Shingled Magnetic Recording). Ее достоинство возможность повышения плотности записи, недостаток снижение производительности. У дисков по девять пластин, скорость работы которых 7200 RPM. Объем буфера DRAM - 512 МБ.

Среди прочих преимуществ дисков защита от вибраций, увеличенная производительность, повышенная надежность. На обе модели также распространяется пятилетняя гарантия. Заявленная стоимость 630 евро. Правда, купить HDD объемом в 20 ТБ можно будет не ранее следующего квартала.

Компания Western Digital на дисках не остановилась. Новыми моделями пополнились и линейки гибридных полок JBOD Ultrastar Data60 и Data102, плюс Serv60+8.


Системы будут поставляться вместе с новыми HDD со следующего квартала. Характеристики платформ 1.836PB, 4U. Гарантия на них, как и на жесткие диски, пять лет.


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

Подробнее..

Зачем нужна новая POSIX-подобная файловая система

16.07.2020 10:19:49 | Автор: admin
Поговорим о том, как устроена ФС Hyperdrive, и тех, кто уже начать её использовать.


Фото moren hsu Unsplash

Пара слов о Hyperdrive


Это POSIX-подобная файловая система для приложений с распределённой архитектурой. Её иерархия представлена единым деревом, а все объекты обладают двумя именами: абсолютное (от корня) и относительное (от текущего рабочего каталога). Hyperdrive разрабатывают авторы открытого P2P-браузера Beaker он позволяет размещать сайты прямо в браузере достаточно создать локальную папку и поделиться соответствующей ссылкой.

Как устроена система


Она реализована на Node.js её исходный код лежит на GitHub. По словам авторов, работа с Hyperdrive напоминает взаимодействие со стандартным модулем Node fs. Вот пример:

var hyperdrive = require('hyperdrive')var archive = hyperdrive('./my-first-hyperdrive') // content will be stored in this folderarchive.writeFile('/hello.txt', 'world', function (err) {  if (err) throw err  archive.readdir('/', function (err, list) {    if (err) throw err    console.log(list) // prints ['hello.txt']    archive.readFile('/hello.txt', 'utf-8', function (err, data) {      if (err) throw err      console.log(data) // prints 'world'    })  })})

В основе Hyperdrive лежат две особые структуры под названием Hypercores. Это журналы, в которые можно только добавлять данные (append-only logs). Первый хранит индексные метаданные, а второй бинарники файлов. Имена файлов и папок проиндексированы с помощью префиксного дерева хешей, чтобы упростить поиск. В каком-то смысле оно служит быстрой системой типа ключ-значение. Целостность данных проверяется с помощью дерева Меркла с криптографической хеш-функцией BLAKE2b-256.

За обработку обращений пользователей к файловой системе отвечает специальный демон. Его CLI позволяют создавать, расшаривать и просматривать директории Hyperdrive. Демон поддерживает FUSE, поэтому диски Hyperdrive могут отображаться как обычные папки на системах Linux и Mac.

Где её используют


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

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


Фото Clint Adair Unsplash

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

Сегодня вокруг Dat уже сформировалось достаточно обширное сообщество, а его продвижением занимается специальный фонд Dat Foundation его поддерживает Mozilla и Code for Science & Society. В перспективе эти организации поспособствуют росту популярности как протокола Dat, так и файловой системы Hyperdrive.



О чем мы пишем в корпоративном блоге 1cloud.ru:

Резервное копирование файлов: как подстраховаться от потери данных
Минимизация рисков: как не потерять ваши данные
Где полезны объектные хранилища
RAID-массив в виртуальной машине


Подробнее..

Видеонаблюдение HikVision бесплатно

16.07.2020 20:13:21 | Автор: admin


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

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

Во-вторых, мы, конечно, ставили ссылку на каталог с современными видеорегистраторами, которые мы продаем в данный момент, но особо на продажи не рассчитывали. И тоже ошиблись, продав 12 новых видеорегистраторов.

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

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

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

Что разыгрываем?


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

  1. Четырехканальный видеорегистратор DS-H204QP 1 штука
  2. HD-TVI камера DS-T200P 4 штуки
  3. Жесткий диск WD на 1 Тбайт, Purple Surveillance 1 штука
  4. Коаксиальный кабель RG-6 (20 метров) 4 штуки
  5. ЖК Монитор не менее 17 дюймов 1 штука
  6. Бесплатное программное обеспечение для ПК Windows и MacOS
  7. Бесплатное приложение для мобильных платформ Android и iOS

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

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

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

Для этого мы выбрали оборудование аналогового формата HD-TVI, так как HD-TVI камеры в принципе не нуждаются в настройке, а настройка HD-TVI видеорегистратора достаточно простая.

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

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

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

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

Что такое бесконечный розыгрыш, и как мы будем определять победителя?


Бесконечный розыгрыш означает, что мы разыграем один комплект видеонаблюдения каждый месяц, с учетом того, что эта статья и это видео были опубликованы в июле 2020 года. Это значит что до конца 2020 года мы разыграем 7 комплектов, а за 2021 год 12 комплектов. И далее до бесконечности по 12 комплектов каждый год.

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

Как принять участие?
Условий три: подписаться на наш YouTube канал, поставить лайк этому видео и написать любой осмысленный комментарий к этому видео.

Как принять участие в розыгрыше в июле 2020 года?
Для определения победителя в июле 2020 года мы возьмем все комментарии, которые были написаны к этому видео с 1 июля 2020 года по 31 июля 2020 и случайным образом выберем один комментарий, автор которого и станет победителем.

Как принять участие в розыгрыше в августе 2020 года?
Для определения победителя в августе 2020 года мы возьмем все комментарии, которые были написаны к этому видео с 1 августа 2020 года по 31 августа 2020 и случайным образом выберем один комментарий, автор которого и будет победителем. И далее до бесконечности.

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

Для доставки выигрыша по России мы сделаем бесплатную доставку до транспортной компании Деловые Линии, если Деловые линии не доставляет в тот населенный пункт, где вы проживаете, доставим бесплатно до любой транспортной компании по вашему выбору в пределах Москвы.

Как понять что розыгрыш действует?


Если вы можете посмотреть это видео, то акция действует, и вы можете участвовать.



В последний день того месяца, в котором вы смотрите это видео, мы подведем итог, и объявим победителя.


Видеорегистратор DS-H204QP


4-канальный гибридный видеорегистратор HiWatch DS-H204QP с поддержкой технологии питания по коаксиальному кабелю (PoC) производства компании HikVision. Гарантия 2 года.


Передняя панель видеорегистратора


Задняя панель видеорегистратора

Видеорегистратор рассчитан на подключение до четырех аналоговых камер стандартов TVI, AHD и одной IP-камеры (до 5 с замещением аналоговых камер) с разрешением до 4 Мп. Инновационный кодек разработанный HikVision H.265+, позволяет экономить до 70 % жесткого диска.

Основные характеристики:


  • 4 канала с поддержкой PoC-камер
  • Запись с разрешением до 6 Мп
  • Вывод видео с разрешением до 1080р
  • 1 Жесткий диск SATA до 10ТБ
  • 4 аудио вход / 1 аудио выход
  • 4 тревожных входа /1 тревожный выход
  • Сетевой интерфейс 1 RJ-45 10M / 100M Ethernet
  • Питание: 48В DC
  • Потребляемая мощность: до 40Вт.
  • Рабочие условия: -10C+55C, 10%-90% влажность
  • Размер: 315 242 45 мм
  • Вес: 1,16 кг (Без HDD)


Сеть


Подробно со всеми характеристиками вы можете ознакомится в паспорте.

Функционал видеорегистратора


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

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

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

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

Например камера направлена вдоль забора, также рисуете линию вдоль забора. Если ее кто-то пересечёт, то сработает этот детектор и вы сможете получить уведомление на электронную почту например.

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

Но самое интересное это конечно уведомления на электронную почту и пушап с уведомлением в приложение для смартфона.

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

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

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

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

HD-TVI камера DS-T200P


2 Мп камера DS-T200P с максимальным разрешением Full HD 1920х1080 и углом обзора объектива 82.6 градуса. Производит компания HikVision под одним из своих брендов HiWatch.

Позволяет транслировать видео сигнал по коаксиальному кабелю с разрешением до FullHD на расстояние до 500 метров.

Камера DS-T200P оснащена технологией передачи напряжения питания (PoC) по коаксиальному кабелю RG-6 или RG-59 на расстояние до 200 метров.

Для борьбы с шумами на борту присутствует цифровое шумоподавление DNR, встроенная ИК-подсветка с функцией Smart помогает избежать пересветки объекта наблюдения посредством автоматической коррекции яркости ИК-диодов.

Рабочие температуры располагаются в интервале от -40 до +60C, что вкупе с индексом защиты корпуса от влаги и пыли IP66 открывает возможность инсталляции устройства на улице.



В основу DS-T200P положена CMOS-матрица 1/2.7" с максимальным разрешением 1920х1080, высокой чувствительностью 0.01 Люкс при F1.2 и частотой 25 кадров в секунду. Камера поддерживает режим работы день / ночь и снабжена механическим ИК-фильтром для коррекции цветовой передачи в светлое время суток и увеличения чувствительности в темное.

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

Корпус устройства защищен от попадания внутрь влаги и пыли по стандарту IP66. Сверху закреплен козырек, выступ которого можно регулировать. С тыльной стороны в корпус интегрирован поворотный кронштейн для упрощения процесса монтажа. Модель с мегапиксельным объективом 2.8 мм. Интерфейсы представлены BNC-разъемом аналогового видеовыхода (HD-TVI выход) и гнездом подключения источника питания 12 В. Максимальное потребление энергии HiWatch DS-T200P составляет 4 Вт. Камера может быть установлена не только внутри помещений, но и на улице диапазон рабочих температур от -40 до +60C. Допустимый уровень влажности 90%


Жесткий диск WD Purple на 1Tb


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





Технология IntelliSeek эффективно уменьшает шум и вибрацию, которые ведут к повреждениям. Благодаря этому накопитель будет долго служить владельцу, не нуждаясь в ремонте либо замене. Эта модель поддерживает стандартный интерфейс SATA III, поэтому с её установкой не будет никаких сложностей.

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

Коаксиальный кабель




Четыре куска коаксиального кабеля RG-6 по 20 метров, обратите внимание они уже обжаты BNC разъемами с двух сторон.

ЖК Монитор не менее 17 дюймов


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

Бесплатное программное обеспечение для компьютера


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

Бесплатное программное обеспечение iVMS-4200 для установки на компьютер с Windows либо MacOS, с помощью которого вы сможете подключится этому видеорегистратору и просматривать как в режиме онлайн так и работать с архивом. Актуальные ссылки на скачивание здесь.

Настройка доступа к видеорегистратору через браузеры


Для Windows
Для просмотра через web требуется установить плагин Web Components
  1. Инструкция по настройке просмотра в Firefox
  2. В Internet Explorer в разделе Свойства обозревателя->Дополнительно разрешите запуск сторонних плагинов.
  3. В Chrome и браузерах на его основе, например Yandex browser разработчиками была отключена поддержка сторонних NAPI плагинов. По данной причине потребуется установить расширение IE Tabs. Инструкция по настройке просмотра в Chrome

Для Mac OS
Это веб-плагин V3.0.6.23. Позволяет просматривать в реальном времени большую часть видеорегистраторов HikVision в Safari для Mac.

Приложения для для мобильных платформ


Приложения устанавливаются на смартфоны под управлением Android и iOS для удаленного просмотра видео, работы с видеоархивом и некоторых других простых возможностей.

Для просмотра видеозаписей и видеоархива через интернет вам потребуется подключить видеорегистратор к облачному p2p сервису с длинным и замысловатым названием Hik-connect / Guarding-vision, зарегистрироваться можно через сайт или в мобильных приложениях Hik-connect для android и iOS, скачать последние версии можно здесь.

Утилиты для работы с устройствами по сети


Сетевой сканер SADP
Утилита осуществляет поиск устройств HikVision в вашей подсети и отображает информацию о них. Можно осуществить активацию устройств и произвести их базовые сетевые настройки. Скачать версию для Windows 7/8/10. Скачать версию для MacOSX

Remote Backup
Утилита для резервного копирования архива. Скачать версию для Windows 7/8/10.

BatchConfigTool
Утилита для пакетной настройки. Скачать версию для Windows 7/8/10, Скачать версию для MacOSX.


Важное


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

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

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

P.S. Понятно, что в мире нет ничего абсолютного, кроме числа 42 :) Поэтому наш разыгрываемый комплект со временем может претерпеть изменения, например какое-то оборудование может быть снято с производства. В таком случае мы будем подбирать аналог с максимально сходными или более высокими характеристиками. Естественно об изменениях в составе разыгрываемого комплекта мы будем уведомлять.

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

Подробнее..

Kingston DataTraveler новое поколение защищенных флешек

23.07.2020 10:06:27 | Автор: admin
Привет, Хабр! У нас отличная новость для тех, кто предпочитает обезопасить свои данные, которые хранятся не только на внутренних накопителях ПК и ноутбуков, но и на съемных носителях. Дело в том, что 20 июля наши американские коллеги из Kingston объявили о выпуске трех USB-накопителей с поддержкой стандарта USB 3.0, емкостью 128 Гбайт и функцией шифрования. Если быть точнее, речь идет о моделях Kingston DataTraveler Locker+ G3, Kingston DataTraveler Vault Privacy 3.0 и Kingston DataTraveler 4000 G2. Далее по тексту мы детально поговорим о каждом из накопителей и расскажем, что они умеют, помимо обеспечения безопасности.



Kingston DataTraveler Locker+ G3: беспрецедентная защита


Флешка Kingston DataTraveler Locker+ G3 (доступная с емкостями 8, 16, 32, 64 а теперь и 128 Гбайт) обеспечивает защиту персональных данных с помощью аппаратного шифрования, а также позволяет установить пароль для доступа к информации, что обеспечивает двойной уровень защиты. Накопитель выполнен в прочном металлическом корпусе и оснащен удобной петличкой, чтобы цеплять флешку на связку ключей (aka брелок). Таким образом, накопитель всегда будет с вами (если вы не из тех, кто постоянно теряет ключи от дома и офиса, конечно).

DataTraveler Locker+ G3 прошлого поколения зарекомендовали себя на рынке как одни из самых надежных устройств хранения данных. К тому же эти накопители не требуют сложных настроек: одна из опций позволяет настроить резервное копирование данных с флешки в облачное хранилище Google, OneDrive, Amazon Cloud или Dropbox. А это уже фактически тройная защита.

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



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

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

Потерять накопитель тоже не страшно. Система безопасности не позволит злоумышленникам или обычным мамкиным хакерам взломать вашу флешку методом подбора паролей. После 10 неудачных попыток ввода DataTraveler Locker+ G3 автоматически отформатируется и уничтожит все данные (однако в облачном хранилище они останутся).

Kingston DataTraveler Vault Privacy 3.0: для бизнеса


Флешка DataTraveler Vault Privacy 3.0 (DTVP 3.0) обеспечивает защиту классом повыше и ориентирована на бизнес-сегмент: в частности, накопитель поддерживает аппаратное 256-битное AES-XTS-шифрование и оснащен прочным алюминиевым корпусом, который защищает флешку от физических воздействий, и герметичным колпачком для предотвращения попадания влаги и пыль на USB-коннектор. Интересная особенность заключается еще и в поддержке ОС Linux, а не только распространенный систем на базе Windows и Mac.

Как и в случае с предыдущей флешкой (Kingston DTLPG3) при использовании DataTraveler Vault Privacy 3.0 вам нужно просто установить пароль и накопитель будет содержать все записанные данные в полной безопасности от постороннего вторжения. Функция защиты от взлома здесь аналогичная: 10 попыток на ввод пароля, после чего информация на флешке уничтожается. Хакнуть флешку методом брутфорса у злоумышленников не получится от слова совсем.



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

Ранее в продаже были доступны накопители DataTraveler Vault Privacy 3.0 с емкостями 4, 8, 16, 32 и 64 Гбайт, а с обновлением линейки добавилась модель с емкостью 128 Гбайт. Что ж, вкупе с AES-шифрованием Kingston DataTraveler Vault позволит не переживать за возможные утечки ценной информации, зная, что ваши данные защищены серьезным шифрованием

Kingston DataTraveler 4000 G2: защита на уровне правительства


В накопителе Kingston DataTraveler 4000 G2 акцент также сделан на защиту данных, но здесь он еще более серьезный, чем у Kingston DTVP 3.0. Вместе с емкостью в 128 Гбайт конечный пользователь получает несколько уровней расширенной защиты, так что предложение выгодное. И если безопасность является приоритетом рассматривать DataTraveler 4000 G2 в качестве покупки имеет смысл. Устройство выполнено в прочном корпусе из нержавеющей стали, обладает герметичной заглушкой и как и вышеназванные продукты предлагает 256-битное аппаратное AES-XTS-шифрование для надежной защиты информации на флеш-памяти.



Кроме того, флешка сертифицирована по стандарту FIPS 140-2 Level 3 Validation (стандарт безопасности для накопителей, использующихся в правительстве США). Также накопитель обладает защитой от несанкционированного доступа (при неверном вводе пароля свыше 10 раз данные удаляются), режимом доступа только для чтения (во избежании заражения компьютеров) и возможностью централизованного управления накопителем на корпоративном уровне (удаленная настройка паролей и изменение политики устройства и т.п.). Стоит отметить, что утилита для удаленного управления и настройки накопителей не входит в пакет ПО и приобретается отдельно. Впрочем, для любой компании это вполне допустимые затраты.

Результаты тестов уже скоро


И самое главное новые флешки уже едут к нашим специалистам, которые проведут тотальное тестирование образцов и подробнее расскажут о том, на какие скорости передачи данных могут рассчитывать пользователи, и как реализованы алгоритмы шифрования. К этому времени Kingston DataTraveler Locker+ G3, Kingston DataTraveler Vault Privacy 3.0 и Kingston DataTraveler 4000 G2 как раз станут доступными для продаж по всему миру.

Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru