Трудная дорога в облака

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

Первый вопрос, который встал передо мной - что выбрать, OpenStack или OpenNebula. И он решился буквально за полчаса гугления. OpenStack точно изучать не буду в ближайшем будущем. Слишком много отрицательных отзывов. Достаточно проглядеть названия текстов: Боль и страдания OpenStack (на Хакере), OpenStack или как не стоит делать проекты (видео лекции Бориса Павловича), Итак, вы решили развернуть OpenStack (статья на Хабре; в названии никакого негатива нет, но сам автор характеризует свой текст как "пост ненависти к OpenStack"). 

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

В общем, решил я остановиться на OpenNebula. Тоже open, тоже бесплатная платформа, но вроде бы попроще и попонятнее. Начну, пожалуй со статьи на Вике МГТУ им. Баумана.

Кстати, где-то там в недрах OpenNebula используется алгоритм консенсуса Raft. Об этом можно прочитать в посте Романа Богачева.

Ссылки: электроника

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

• Видео Новые платформы и модули на канале voltNik. 
• Сообщество ремонтеров на Picabu.
• Супер-мега подробный рассказ о NodeMCU и WiFi розетке с этой железкой.
• О ремонте кабеля USB-microUSB
• Статья на ту же тему на кунг-фу-сайте мастер пайки 
• Видео Ремонт usb кабеля для зарядки телефона
• Доходчиво о чтении электрических схем
• Теор основы электротехники в блоге DI HALT
• Пайка разъема гарнитуры/наушников на Picabu

Курс по анализу данных на github

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

Лучшие способы применения Redis

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

Модели согласованности

Хорошая картинка с иерархией моделей согласованности. Краткое описание сути нескольких моделей со ссылками на статьи. Пересказ раздела "Согласованность и репликация" из Таненбаума.

Целостное хэширование - наконец-то!

Наконец-то я понял идею целостного хэширования (consistent hashing)! Много чего читал - и никак.

Вот, например, замечательный пост, где объясняется идея этого вида хэширования, в контексте статьи о Amazon Dynamo (ссылка на саму статью). Хорошо все рассказано - и всё равно не понял.

Но Интернет большоооой. Вот, наконец, пост, который смог мне объяснить эту простую идею.

Итак. Есть функция хэширования f(). У нее есть некоторая область значений (fmin, fmax). Сворачиваем ее в кольцо. Берем имеющиеся сервера (по которым нужно равномерно распределить ключи), у каждого своё имя (IP-адрес, например). Хэшируем имена серверов, получаем точки на кольце (эти точки разбивают кольцо на отрезки). 

Теперь берем ключи, хэшируем их названия, получаем новые точки, которые распределяются по кольцу. На каком сервере будет размещен данный ключ? Берем ключ, его хэш - точка на кольце. Двигаемся по кольцу по часовой стрелке, находим первую точку, которая представляет сервер. На этом сервере и будет размещен данный ключ. При добавлении/удалении сервера будут перераспределено лишь небольшое количество ключей. В отличие от простейшей методике, где номер сервера определяется по формуле хэш(ключ) % количество_ключей. 

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

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

DHCP-сервер роутера отказал в аренде IP

Вот такую ошибку нашел в журнале событий планшета:
dhcp-сервер отказал в аренде IP-адреса (имеется ввиду dhcp роутера).

Советы из интернета:
Попробуйте увеличить время аренды адресов в DHCP-сервере роутера до хотя бы 7 дней вместо суток.  Вообще-то для сети, где используются постоянные устройства , лучше ставить аренду (Lease Time) хотя бы на месяц. Или вообще на год. А то мало ли по какой причине данное устройство долгое время будет не в сети...