Введение

Пришла пора покупать СХД. Какую взять, кого слушать? Вендор А рассказывает про вендора B, а еще есть интегратор C, который рассказывает обратное и советует вендора D. В такой ситуации и у опытного архитектора по системам хранения голова пойдет кругом, особенно со всеми новыми вендорами и модными сегодня SDS и гиперконвергенцией.

Итак, как же во всем этом разобраться и не оказаться в дураках? Мы (AntonVirtual Антон Жбанков и korp Евгений Елизаров) попробуем об этом рассказать русским языком по белому.
Статья во многом перекликается, и фактически является расширением “Дизайна виртуализованного ЦОД” в плане выбора систем хранения данных и обзора технологий систем хранения. Мы кратко рассмотрим общую теорию, но рекомендуем ознакомиться и с указанной статьей.

Зачем

Часто можно наблюдать ситуацию как приходит новый человек на форум или в специализированный чатик, как например Storage Discussions и задает вопрос: “вот мне предлагают два варианта СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, что посоветуете”?

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

У нас было 2 анализатора кода, 4 инструмента для динамического тестирования, свои поделки и 250 скриптов. Не то, чтобы это всё было нужно в текущем процессе, но раз начал внедрять DevSecOps, то надо иди до конца.



Источник. Авторы персонажей: Джастин Ройланд и Дэн Хармон.

Что такое SecDevOps? А DevSecOps? В чем отличия? Application Security — о чём это? Почему классический подход больше не работает? На все эти вопросы знает ответ Юрий Шабалин из Swordfish Security. Юрий подробно на всё ответит и разберет проблемы перехода от классической модели Application Security к процессу DevSecOps: как правильно подойти к встраиванию процесса безопасной разработки в процесс DevOps и ничего не сломать при этом, как пройти основные этапы тестирования на безопасность, какие инструменты можно применять, чем они отличаются и как их правильно настроить, чтобы избежать подводных камней.

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



Я не могу похвастаться тем, что за 7 лет я затронул все темы сетевой сферы или тем, что хотя бы одну из них раскрыл полностью. Но это и не было целью. А целью этой серии статей было ввести юного студента за руку в этот мир и проводить его шаг за шагом по основной галерее, давая общее представление, и уберечь от болезненных скитаний по тёмным уголкам сознания Олифера и Олифера в мучительных попытках найти ответ на вопрос, как всё это применить в жизни.
СДСМ планировался коротким практическим курсом «как научиться в сети за месяц», а вылился в 16 (на самом деле 19) длинных выпусков, которые мы уже даже переименовали в «Сети Для Самых Суровых». Общее количество символов перевалило за 1 000 000.

_{Источник изображения:www.nikonsmallworld.com}

Антиплагиат – это специализированный поисковик, о чем уже писали ранее. А любому поисковику, как ни крути, чтобы работать быстро, нужен свой индекс, который учитывает все особенности области поиска. В своей первой статье на Хабре я расскажу о текущей реализации нашего поискового индекса, истории его развития и причинах выбора того или иного решения. Эффективные алгоритмы на .NET — это не миф, а жесткая и продуктивная реальность. Мы погрузимся в мир хеширования, побитового сжатия и многоуровневых кешей с приоритетами. Что делать, если нужен поиск быстрее, чем за O(1)?

Если кто-то еще не знает, где на этой картинке шинглы, добро пожаловать…

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

Немного предыстории:

Некоторое время назад я решил завести пчел, и они таки появились… на целый сезон, но не вышли из зимовки.
И это несмотря на то, что вроде все делал правильно — осенний прикорм, утепление перед холодами.
Улей был классический деревянный системы "Дадан" на 10 рамок из 40-мм доски.
Но в ту зиму из-за температурных "качелей" даже опытные пчеловоды потеряли куда больше, чем обычно.

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

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

Логика работы следующая: при первом запуске/сбросе запоминаются в EEPROM показания датчиков, установленных под ульи.
Дальше, каждый день, после заката система "просыпается", считывает показания и отправляет СМС с изменением веса за сутки и от момента включения.
Кроме того передается значение напряжения батареи, а при снижении до 3.5В выдается предупреждение о необходимости зарядки, ибо ниже 3.4В модуль связи не включается, да и показания веса уже "уплывают".

По мере роста использования HTTPS растёт желание посторонних лиц внедриться в защищённый трафик. Исследование 2017 года The Security Impact of HTTPS Interception показало, что это становится всё более распространённой практикой. Анализ трафика на серверах обновления Firefox показал, что в отдельных странах процент внедрения посторонних агентов в HTTPS достигает 15%.

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

Вчера Mozilla довела до финальной версии один из своих экспериментальных проектов Firefox Send: простой и безопасный сервис обмена зашифрованными файлами. Поддерживаются файлы до 1 ГБ (до 2,5 ГБ после авторизации в Firefox Account).

Сервис выглядит просто, но под ним работает движок, который обеспечивает настоящее end-to-end шифрование, то есть вы никуда не передаёте файлы в открытом виде — они шифруются конкретно на вашем ПК, а расшифровываются на компьютере получателя (JS в браузере). Как это работает, можно посмотреть на примере Firefox Sync, здесь реализована похожая архитектура.

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

Google Safe Browsing внезапно нашел вирус на моем сайте. [WNC-611600] Malicious or unwanted software detected on site… (Которого не было — как выяснилось позже).

Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал.

Предлагаю и вам познакомиться с данной статьей в моем переводе. Комментарии и дополнения только приветствуются!


(Источник картинки)

Эта рассказ о нестандартном подходе к разработке Android-приложений. Одно дело — установка Android Studio и написание «Hello, World» на Java или Kotlin. Но я покажу, как эту же задачу можно выполнить иначе.

В магазинах можно встретить множество мощных светодиодных ламп, например «свечки» и «шарики» 9 и 11 Вт.

Вот только свечек и шариков такой мощности сегодня существовать не может.

Мексиканский наркобарон Хоакин Гусман Лоэра (Эль Чапо)

Не так давно в СМИ промелькнула статья о том, что мексиканского наркобарона Эль Чапо арестовали из-за того, что его IT-шник слил криптоключи в ФБР, а те в свою очередь смогли расшифровать и прослушать его телефонные переговоры.

Давайте пофантазируем и представим, что наркобарон, IT-шник и все, все, все жили бы в России…

Представили? А теперь разберем, какими законами и как регулировалось бы применение криптозащиты в данном фантасмагорическом случае.

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

Люди расположились на креслах и диванах, стоявших вдоль стен, кто-то клевал носом, кто-то ковырялся в телефоне, некоторые вели ленивую беседу, даже курильщики были здесь – лень тащиться на улицу. До конца обеда еще оставалось минут пятнадцать.

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

— Коллеги, беда! – запыхавшись, выпалил собственник. – Срочно все в зал!

Программируя вместе за одним компьютером, Джефф Дин и Санджай Гемават изменили курс компании — и весь Интернет. На иллюстрации: лучшие программисты Google иногда кажутся двумя полушариями одного мозга. Рисунок Дэвида Планкерта

Однажды в марте 2000 года шесть лучших инженеров Google собрались в импровизированном конференц-зале. Произошло ЧП: с октября 1999 года остановились краулеры. Хотя пользователям ещё выдавали поисковые результаты, но они устарели на пять месяцев. На карту было поставлено больше, чем предполагали инженеры. В данный момент Ларри Пейдж и Сергей Брин вели переговоры о поставке поиска Google на крупнейший в интернете портал Yahoo и обещали увеличить поисковый индекс в десять раз, чтобы идти в ногу со Всемирной паутиной, которая за предыдущий год удвоилась в размере. Если краулеры не починят, google.com застрянет в прошлом, сделка с Yahoo может провалиться, а компания рискует сжечь полученные инвестиции и кануть в небытие.

5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Организатор круглого стола, Максим Смирнов, ведет блог про архитектуру и канал на Facebook.

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

На круглом столе было представлено 4 доклада по 15-20 минут, после чего были вопросы из аудитории и обсуждение.

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

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


Папа, а почему ты смотришь в телефон?

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

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

Знаете что? Пусть катятся к черту.

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

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

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

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

В данной статье рассмотрим архитектуры простых и эффективных KV-хранилищ с использованием цепной репликации (chain replication), которая активно исследуется и успешно применяется в различных системах.