Многие пытаются собрать «Умный дом» своими руками. При выборе системы стоит учитывать не только ассортимент и стоимость конечных устройств, но и возможности контроллера. Большинство контроллеров сразу готовы к работе «из коробки», но представляют ограниченные возможности. Однако нередко именно гибкость и возможность лёгкой интеграции является основополагающим критерием при выборе.

И вот, появился долгожданный «кубик Lego» для систем автоматизации на базе технологии Z-Wave, который обладает желаемой гибкостью и в то же время большим функционалом и низкой ценой.

Плата расширения RaZberry для Raspberry Pi, превращает самый популярный и дешёвый мини-компьютер в Z-Wave контроллер домашней автоматизации.

Этой весной, Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

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

Конспект лекций — Питер Тиль (курс: CS183) Стартап — Стэнфорд, весна 2012 г.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

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

В связи со сменой Hostkey основного ЦОД со Стордаты на Мегафон и переноса основной площадки вирутуализации и перехода на Server 2012 для Windows нам пришлось делать новый высокопроизводительный файлер для выдачи iSCSI/NFS/SMB таргетов на кластеры и нашим клиентам для организации частных облаков/кластеров. Мы выбрали и внедрили NexentaStor и вот что из этого вышло и как мы это делали

В этом году исполняется 10 лет с момента продажи первой системы хранения данных 3PAR с технологией Thin Provisioning. И несмотря на то что технология стала очень популярной и востребованной, толкового описания того как же это работает на низком уровне мне встретить до сих пор не удалось. В этой статье я попробую осветить наиболее «темные», на мой взгляд, стороны thin provisioning – технические основы данной технологии. То есть, то как именно хост взаимодействует с системой хранения данных. Эти технологии сейчас уже не являются эксклюзивом 3PAR, так как теперь это индустриальные стандарты, но так как технология thin provisioning впервые появилась в 3PAR, то позволю себе отдать все лавры именно этим массивам.

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

Картинки кликабельны.

Form builder

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

Введение

Привет всем! Несколько месяцев назад на Хабре была опубликована статья «Вещание онлайн-видео с помощью nginx» , в которой Aecktann рассказал о своем опыте внедрения разрабатываемого мной модуля к nginx для вещания видео — nginx-rtmp-module. С тех пор продукт активно развивался и в этой статье я более подробно расскажу о нем.

Вещатель нужен для передачи видео-потока клиенту. Речь идет либо о живом потоке, либо о вещании записанного видео (VOD, Video-on-demand). Существует большое количество технологий вещания видео. Среди них можно выделить традиционные протоколы, такие как RTMP или MPEG-TS, а также появившиеся в последнее время технологии адаптивного вещания поверх HTTP. К последним относятся HLS (Apple), HDS (Adobe), Smooth Streaming (Microsoft), MPEG-DASH. При выборе технологии основным фактором является ее поддержка на клиентской стороне. Именно поэтому вещание в формате RTMP на текущий момент является одним из самых распространенных. Протокол HLS поддерживается устройствами компании Apple, а также некоторыми версиями Android.

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

Здесь я немного усложню задачу — в первой части был описан только один vdev; здесь их у нас будет несколько, поскольку алгоритм должен выбрать и vdev, куда мы будем писать блок данных, и metaslab внутри vdev'a. В продакшн системе может быть несколько десятков vdev, и правильно распределить данные по ним критично — перебалансировать их мы уже не сможем без копирования всех данных. Цель правильного алгоритма — распараллелить данные так, чтобы на каждом девайсе их было примерно одинаковое количество, выровнять неравномерное заполнение, но и не перегрузить один из девайсов (это будет тормозить запись на весь пул).

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          c1t6d0    ONLINE       0     0     0
          c1t5d0    ONLINE       0     0     0

Для начала, важное замечание: ZFS рассчитан на то, что все девайсы в пуле имеют одинаковый размер. Иначе, например если добавить 2Тб диск в пул из 1Тб дисков, на 2Тб диске в результате окажется в два раза больше данных, и он начнёт влиять на суммарный IOPs системы — алгоритм аллокатора учитывает процент заполнения, а не количество данных в байтах.

На данный момент в ZFS есть четыре алгоритма аллокатора. Переменная zfs_metaslab_ops содержит поинтер на структуру space_map_ops_t, в которой есть поинтеры на семь функций, которые использует каждый конкретный алгоритм. Например, в Illumos используется алгоритм metaslab_df, и соответствующий стракт с поинтерами на функции выглядит вот так:

Скачать, бесплатно, без рекламы и SMS.
Здесь уже много чего писано на тему Sublime Text 2. Это действительно замечательный редактор с весьма обширными возможностями. Но сейчас я не хочу петь ему очередные хвалебные оды.

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

Vdev, или Virtual Device — это базовая единица, на которой строится массив данных ZFS (zpool). Для работы ZFS необходим как минимум один vdev — виртуальное устройство, которое позволяет случайный доступ к информации на уровне блоков.

Обычно, в качестве таких блоков используются целые диски или iScsi/FC LUNы (raw-disk vdev), но можно также использовать разделы дисков или файлы. Целые диски предпочтительнее, так как для них ZFS использует onboard write cache, в результате чего производительность записи может значительно улучшиться. Я пока не буду объяснять разницу между logical vdev и leaf vdev — это топик для отдельной статьи про то как работает RaidzN и zfs mirror.

src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/vdev_disk.c#314

if (vd->vdev_wholedisk == 1) 
{
	int wce = 1;
	/*
	 * If we own the whole disk, try to enable disk write caching.
	 * We ignore errors because it's OK if we can't do it.
	 */
	(void) ldi_ioctl(dvd->vd_lh, DKIOCSETWCE, (intptr_t)&wce, FKIOCTL, kcred, NULL);
}

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

Каждый vdev разделен на логические разделы (metaslab),

Недавно я запустил сайт backgrounddating.com и написал об этом здесь, на Хабрахабре. Разумеется, я уже тогда рассказал о некоторых технических деталях реализации этого проекта, но об одной из возможностей сайта я бы хотел написать отдельно, тем более, что документации (как на русском, так и на английском) на эту тему в Интернете пока что довольно мало. Итак, речь пойдёт о чате в реальном времени между двумя пользователями. Задача состоит в том, чтобы любой пользователь мог отправлять другим пользователям сообщения, и, если у получателя сообщения открыт чат с этим пользователям, то он сразу же видел входящие сообщения (а в ином случае он мог прочитать сообщения позже: то есть при открытии чата загружается история последних сообщений).

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

Сразу уточню, что это не единственный способ реализовать подобное. Вы можете использовать другой асинхронный веб-сервер (например node.js), можете использовать другую очередь сообщений (или вообще её не использовать, если вам подходят особенности такого варианта: с пользователями одного канала обязательно общается один и тот же worker веб-сервера). Я даже не утверждаю, что этот вариант самый лучший (но в данном случае он подошёл лучше всех). В конце концов, мы здесь вообще не будем рассматривать костыли (long polling, Flash) для старых браузеров (а это почти все версии IE, например), не поддерживающих веб-сокеты, и даже не будем рассматривать возможность подключаться из тех браузеров, которые уже поддерживают протокол WebSocket, но не стандартизированную версию (RFC 6455), а одну из устаревших. О том, как можно включить поддержку устаревшей версии «draft 76» (она же «hixie-76»), смотрите в документации Tornado.

Дейл Риз — один из разработчиков PHP-фреймворка Laravel — выложил на Гитхаб весьма приятную подборку цветовых схем, совместимую с Sublime Text 2, Vim и TextMate. В неё входят преимущественно тёмные темы (21 из 25), и, что бывает не так уж часто, практически все они выглядят очень прилично — есть из чего выбрать. Инструкции по установке и скриншоты каждой темы — в репозитории.
Под катом — скриншоты всех 25 схем.

Введение

Недавно я описывал созданную мной систему мониторинга транзитного VoIP методом прогнозирования. Самым сильным плюсом данного метода в задаче мониторинга транзитного VoIP является то, что нет необходимости выставлять критерии того, что считать нормальной работой величин, находящихся под мониторингом, а что – потенциальным сбоем.
Ядром системы является rrdtool, в котором реализованы прогнозирование методом Хольта-Винтерса и механизм выявления аберраций.
Мониторинг методом прогнозирования можно использовать не только для VoIP, но и для любого другого типа трафика, а так же, для величин, которые изменяются во времени с некой прогнозируемой цикличностью. В отличие от стандартных методов, при мониторинге с помощью прогнозирования не осуществляет мониторинг состояния величин, находящихся под мониторингом, зато осуществляется мониторинг динамики изменения их состояний во времени.
Если вам интересна математика прогнозирования рекомендую прочесть. Чтобы быть хоть немного в курсе темы, прочтите главу “Метод прогнозирования реализованный в rrdtool” моего предыдущего поста.

Аннотация

Даже если вы не используете VoIP в своей системе, или это не основное ваше направление, вас может заинтересовать сам метод мониторинга с помощью прогнозирования потому, что его можно успешно применять не только для транзитного VoIP. Метод мониторинга рассматривается на примере приложения к транзитному VoIP потому, что данная задача — яркий пример его использования. Стандартными методами задача не решается, а мониторинг методом прогнозирования реализуется сравнительно просто. То, что написано ниже, это не теоретические изыскания, это уже несколько месяцев успешно используется на практике.

Введение

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

Многие учебные пособия по разработке на Django раскрывают как быстро получить работающий отладочный сервер (python manage.py runserver), а вопрос развертывания в боевом режиме часто остается нераскрытым или освещаются далеко не самые простые и эффективные методы.
Ниже я расскажу о об одном из способов развернуть сайт на Django в боевом режиме, начиная от выбора хостинга, заканчивая развертыванием веб-сервера. Таким образом статья может быть полезна тем, кто освоил разработку на базе Django, но не имеет опыта развертывания серверов. Мой способ один из многих, но он достаточно прост, эффективен в работе и легок в поддержке. Используем VPS-хостинг, Ubuntu 10.04, nginx, gunicorn.

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

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

Всем привет!

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

Архитектура

Экспорт виртуальных жёстких дисков осуществляется через отдельную гигабитную сеть по протоколу AoE. Если коротко — это детище компании Coraid, которая предложила реализовать передачу ATA-команд по сети, напрямую. Спецификация протокола занимает всего десяток страниц! Главная особенность — это отсутствие TCP/IP. При передаче данных получается минимальный оверхед, но как плата за простоту — невозможность роутинга.

Почему именно такой выбор? Если опустить перепечатывание официальных источников — в т.ч. и банальный lowcost.

Соответственно, в хранилищах мы использовали обычные SATA-диски с 7200 rpm. Их недостаток известен всем — низкий IOPS.

Феерическая расстановка точек над i в вопросе удаления файлов из переполненной директории.

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

Для тех, кто не в курсе проблемы, краткое описание: если вы случайно создали в одной директории огромное количество файлов без иерархии — т.е. от 5 млн файлов, лежащих в одной единственной плоской директории, то быстро удалить их не получится. Кроме того, не все утилиты в linux могут это сделать в принципе — либо будут сильно нагружать процессор/HDD, либо займут очень много памяти.

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

В 2007 году, консалтинговое агентство Forrester провело опрос 250 IT-специалистов, с целью оценить риски аварий для IT, как внутри датацентра, так и вне его, например риски природных аварий и катастроф.

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

На графике вы видите также такие IT-дизастеры как отказы электропитания (" — что случилось с вашим электричеством? — Оно моргнуло." ), проблемы с ПО ("…и будет закрыто"), человеческие ошибки ("как ты сказал имя тома, который надо было размонтировать и грохнуть?"), ошибки сетевых настроек (" — а какой интерфейс использовать? — попробуй eth0."), а также и разнообразные природные (и не очень) катаклизмы, такие как пожары, наводнения и так далее.

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