Сравнение методов распознавания сигналов. Нейронные сети против согласованного фильтра

Горизонтальное масштабирование. Что, зачем, когда и как?

Александр Макаров ( SamDark )

Здравствуйте! Я Александр Макаров, и вы можете меня знать по фреймворку «Yii» — я один из его разработчиков. У меня также есть full-time работа — и это уже не стартап — Stay.com, который занимается путешествиями.

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

Что такое масштабирование, вообще? Это возможность увеличить производительность проекта за минимальное время путем добавления ресурсов.

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

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

Самый классный вопрос, который задают, — а зачем оно надо, если у меня все и на одном сервере прекрасно работает? На самом-то деле, надо проверить, что будет. Т.е., сейчас оно работает, но что будет потом? Есть две замечательные утилиты — ab и siege, которые как бы нагоняют тучу пользователей конкурента, которые начинают долбить сервер, пытаются запросить странички, послать какие-то запросы. Вы должны указать, что им делать, а утилиты формируют такие вот отчеты:

и

Главные два параметра: n — количество запросов, которые надо сделать, с — количество одновременных запросов. Таким образом они проверяют конкурентность.

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

Есть еще один параметр — Responce time — время ответа, за которое в среднем сервер отдал страничку. Оно бывает разное, но известно, что около 300 мс — это норма, а что выше — уже не очень хорошо, потому что эти 300 мс отрабатывает сервер, к этому прибавляются еще 300-600 мс, которые отрабатывает клиент, т.е. пока все загрузится — стили, картинки и остальное — тоже проходит время.

Бывает, что на самом деле пока и не надо заботиться о масштабировании — идем на сервер, обновляем PHP, получаем 40% прироста производительности и все круто. Далее настраиваем Opcache, тюним его. Opcache, кстати, тюнится так же, как и APC, скриптом, который можно найти в репозитории у Расмуса Лердорфа и который показывает хиты и мисы, где хиты — это сколько раз PHP пошел в кэш, а мисы — сколько раз он пошел в файловую систему доставать файлики. Если прогнать весь сайт, либо запустить туда какой-то краулер по ссылкам, либо вручную потыкать, то у нас будет статистика по этим хитам и мисам. Если хитов 100%, а мисов — 0%, значит, все нормально, а если есть мисы, то надо выделить больше памяти, чтобы весь наш код влез в Opcache. Это частая ошибка, которую допускают — вроде Opcache есть, но что-то не работает…

Еще часто начинают масштабировать, но не смотрят, вообще, из-за чего все работает медленно. Чаще всего лезем в базу, смотрим — индексов нет, ставим индексы — все сразу залетало, еще на 2 года хватит, красота!

Ну, еще надо включить кэш, заменить apache на nginx и php-fpm, чтобы сэкономить память. Будет все классно.

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

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

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

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

На что нужно обращать внимание прямо сейчас при мониторинге? Это:

1. доступность, т.е. жив сервер, вообще, или нет;
   
2. нехватка ресурсов диска, процессора и т.д.;
   
3. ошибки.
   

Как это все мониторить?

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

• Monit — mmonit.com/monit
• Zabbix — www.zabbix.com
• Munin — munin-monitoring.org
• Nagios — www.nagios.org
• ServerDensity — http://ift.tt/npKeng

Первые 4 инструмента можно поставить на сервер, они мощные, классные. А ServerDensity хостится у кого-то, т.е. мы за нее платим деньги, и она может собирать с серверов все данные и отображать их для анализа.

Для мониторинга ошибок есть два хороших сервиса:

• Rollbar — rollbar.com
• Sentry — getsentry.com

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

Sentry можно поставить к себе на сервер, есть исходник, а Rollbar — нет, но Rollbar лучше, потому что он берет деньги за количество ошибок, т.е. стимулирует их исправлять.

Про нотификации повторю, что спамить не стоит, теряется внимание.

Что, вообще, надо анализировать?

RPS и Responce time — если у нас начинает время ответа падать, то надо что-то делать.

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

Также стоит смотреть на бизнес-анализ. Google Analytics для сайтовых типов отлично подходит, а mixpanel — для логирования ивентов, он работает на десктопных приложениях, на мобильных, на веб. Можно и на основе каких-то своих данных писать, но я бы советовал готовые сервисы. Смысл в том, что наш мониторинг может показывать, что сервис жив, что все работает, что общий Responce time нормальный, но когда мы, допустим, регистрацию в mixpanel'е начинаем трекать, он показывает, что их как-то маловато. В этом случае надо смотреть, насколько быстро отрабатывают определенные ивенты, страницы, и в чем состоят проблемы. Проект всегда должен быть «обвешан» анализом, чтобы всегда знать, что происходит, а не работать вслепую.

Нагрузка, вообще, возникает или запланировано, или нет, может возникать постепенно, может не постепенно:

Как бороться с нагрузкой? Решает все бизнес, и важна только цена вопроса. Важно:

1. чтобы сервис работал,
   
2. чтобы это было не сильно дорого, не разорило компанию.
   

Остальное не очень важно.

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

На рисунке синяя штука — это Интернет, из которого идут запросы. Ставится балансировщик, единственная задача которого — распределить запросы на отдельные фронтенды-сервера, принять от них ответы и отдать клиенту. Смысл тут в том, что 3 сервера могут обработать (в идеале) в 3 раза больше запросов, исключая какие-то накладные расходы на сеть и на саму работу балансировщика.

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

Вообще, PHP — штука отличная для масштабирования, потому что он следует принципу Share nothing по умолчанию. Это означает, что если мы возьмем, допустим, Java для веба, то там приложение запускается, читает весь код, записывает по максимуму данных в память программы, все там крутится, работает, на request уходит очень мало времени, очень мало дополнительных ресурсов. Однако есть засада — т.к. приложение написано так, что оно должно на одном инстансе работать, кэшироваться, читать из своей же памяти, то ничего хорошего у нас при масштабировании не получится. А в PHP по умолчанию ничего общего нет, и это хорошо. Все, что мы хотим сделать общим, мы это помещаем в memcaсhed, а memcaсhed можно читать с нескольких серверов, поэтому все замечательно. Т.е. достигается слабая связанность для слоя серверов приложений. Это прекрасно.

Чем, вообще, балансировать нагрузку?

Чаще всего это делали Squid'ом или HAProxy, но это раньше. Сейчас же автор nginx взял и партировал из nginx+ балансировщик в nginx, так что теперь он может делать все то, что раньше делали Squid'ом или HAProxy. Если оно начинает не выдерживать, можно поставить какой-нибудь крутой дорогой аппаратный балансировщик.

Проблемы, которые решает балансировщик — это как выбрать сервер и как хранить сессии? Вторая проблема — чисто PHP'шная, а сервер может выбираться либо по очереди из списка, либо по географии каких-то IP'шников, либо по какой-то статистике (nginx поддерживает least-connected, т.е. к какому серверу меньше коннектов, на него он и будет перекидывать). Можем написать для балансировщика какой-то код, который будет выбирать, как ему работать.

Вот, по этой ссылке описан балансировщик, свежепартированный в nginx:

Всем рекомендую, там очень простые конфиги, все максимально просто.

Что, если мы упремся в балансировщик?

Есть такая штука как DNS Round robin — это замечательный трюк, который позволяет нам не тратиться на аппаратный балансировщик. Что мы делаем? Берем DNS-сервер (обычно DNS-сервера у себя никто не хостит, это дорого, несильно надежно, если он выйдет из строя, то ничего хорошего не получится, все пользуются какими-то компаниями), в А-записи прописываем не один сервер, а несколько. Это будут А-записи разных балансировщиков. Когда браузер туда идет (гарантий, на самом деле, нет, но все современные браузеры так действуют), он выбирает по очереди какой-нибудь IP-адрес из А-записей и попадает либо на один балансировщик, либо на второй. Нагрузка, конечно, может размазываться не равномерно, но, по крайней мере, она размазывается, и балансировщик может выдержать немного больше.

Что делать с сессиями?

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

Возникает очевидное желание сделать общую файловую систему, подключить NFS. Но делать так не надо — она до жути медленная.

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

Можно писать в memcached, но очень-очень осторожно, потому что memcached — это, все-таки, кэш и он имеет свойство вытираться, как только у него мало ресурсов, или некуда писать новые ключи — тогда он начинает терять старые без предупреждения, сессии начинают теряться. За этим надо либо следить, либо выбрать тот же Redis.

Redis — нормальное решение. Смысл в том, что Redis у нас на отдельном сервере, и все наши фронтенды ломятся туда и начинают с Redis'а свои сессии считывать. Но Redis однопоточный и рано или поздно можем хорошенько упереться. Тогда делают sticky-сессии. Ставится тот же nginx и сообщается ему, что нужно сделать сессии так, чтобы юзер, когда он пришел на сервер и ему выдалась сессионная coockies, чтобы он впоследствии попадал только на этот сервер. Чаще всего это делают по IP-хэшу. Получается, что если Redis на каждом инстансе, соответственно, сессии там свои, и пропускная способность чтения-записи будет гораздо лучше.

Как насчет coockies? Можно писать в coockies, никаких хранилищ не будет, все хорошо, но, во-первых, у нас все еще куда-то надо девать данные о сессии, а если мы начнем писать в coockies, она может разрастись и не влезть в хранилище, а, во-вторых, можно хранить в coockies только ID, и нам все равно придется обращаться к БД за какими-то сессионными данными. В принципе, это нормально, решает проблему.

Есть классная штука — прокси для memcached и Redis:

Они, вроде как, поддерживают распараллеливание из коробки, но делается это, я не сказал бы, что очень оптимально. А вот эта штука — twemproxy — она работает примерно как nginx с PHP, т.е. как только ответ получен, он сразу отправляет данные и в фоне закрывает соединение, получается быстрее, меньше ресурсов потребляет. Очень хорошая штука.

Очень часто возникает такая ошибка «велосипедирования», когда начинают писать, типа «мне сессии не нужны! я сейчас сделаю замечательный токен, который будет туда-сюда передаваться»… Но, если подумать, то это опять же сессия.

В PHP есть такой механизм как session handler, т.е. мы можем поставить свой handler и писать в coockies, в БД, в Redis — куда угодно, и все это будет работать со стандартными session start и т.д.

Сессии надо закрывать вот этим замечательным методом.

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

Что делать с файлами?

С ними можно справляться двумя способами:

1. какое-то специализированное решение, которое дает абстракцию, и мы работаем с файлами как с файловой системой. Это что-то вроде NFS, но NFS не надо.
   
2. «шардирование» средствами PHP.
   

Специализированные решения из того, что действительно работает, — это GlusterFS. Это то, что можно поставить себе. Оно работает, оно быстрое, дает тот же интерфейс, что NFS, только работает с нормальной терпимой скоростью.

И Amazon S3 — это, если вы в облаке Amazon'а, — тоже хорошая файловая система.

Если вы реализуете со стороны PHP, есть замечательная библиотека Flysystem, покрытая отличными тестами, ее можно использовать для работы со всякими файловыми системами, что очень удобно. Если вы сразу напишете всю работу с файлами с этой библиотекой, то потом перенести с локальной файловой системы на Amazon S3 или др. будет просто — в конфиге строчку переписать.

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

Лучше всего раздавать файлы nginx'ом или Varnish'ем, но лучше все делать nginx'ом, т.к. мы все его любим и используем — он справится, он хороший.

Что у нас происходит с базой данных?

Если у вас все уперлось в код PHP, мы делаем кучу фронтендов и все еще обращаемся к одной БД — она справится достаточно долгое время. Если нагрузка не страшная, то БД живет хорошо. Например, мы делали JOIN'ы по 160 млн. строк в таблице, и все было замечательно, все бегало хорошо, но там, правда, оперативки надо больше выделить на буферы, на кэш…

Что делать с БД, если мы уперлись в нее? Есть такие техники как репликация. Обычно делается репликация мастер-слэйв, есть репликация мастер-мастер. Можно делать репликацию вручную, можно делать шардирование и можно делать партицирование.

Что такое мастер-слэйв?

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

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

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

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

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

Есть такая штука как read/write split.Делается 2 пула серверов — мастер, слэйв, соединение по требованию, и логика выбора соединения варьируется. Смысл в том, что если мы будем всегда читать со слэйвов, а писать всегда в мастер, то будет небольшая засада:

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

Есть два типа выборок:

1. для чтения или для вывода;
   
2. для записи, т.е., когда мы что-то выбрали и потом это что-то надо изменить и записать обратно.
   

Если выборка для записи, то мы можем либо всегда читать с мастера и писать на мастер, либо мы можем выполнить «SHOW SLAVE STATUS» и посмотреть там Seconds_Behind_Master (для PostgreSQL тоже супер-запрос есть на картинке) — он покажет нам число. Если это 0 (нуль), значит, все у нас уже реплицировалось, можно смело читать со слэйва. Если число больше нуля, то надо смотреть значение — либо нам стоит подождать немного и тогда прочитать со слэйва, либо сразу читать с мастера. Если у нас NULL, значит еще не реплицировали, что-то застряло, и надо смотреть логи.

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

Что такое мастер-мастер?

Это ситуация, когда стоит несколько серверов, и везде и пишется, и читается. Плюс в том, что оно может быть быстрее, оно отказоустойчивое. В принципе, все то же, что и у слэйвов, но логика, вообще, простая — мы просто выбираем рандомное соединение и с ним работаем. Минусы: лаг репликации выше, есть шанс получить какие-то неконсистентные данные, и, если произошла какая-нибудь поломка, то она начинает раскидываться по всем мастерам, и никому уже неизвестно, какой мастер нормальный, какой поломался… Это все дело начинает реплицироваться по кругу, т.е. очень неслабо забивает сеть. Вообще, если пришлось делать мастер-мастер, надо 100 раз подумать. Скорее всего, можно обойтись мастер-слэйвом.

Можно делать репликацию всегда руками, т.е. организовать пару соединений и писать сразу в 2, в 3, либо что-то делать в фоне.

Что такое шардирование?

Фактически это размазывание данных по нескольким серверам. Шардировать можно отдельные таблицы. Берем, допустим, таблицу фото, таблицу юзеров и др., растаскиваем их на отдельные сервера. Если таблицы были большие, то все становится меньше, памяти ест меньше, все хорошо, только нельзя JOIN'ить и приходится делать запросы типа WHERE IN, т.е. сначала выбираем кучу ID'шников, потом все эти ID'шники подставляем запросу, но уже к другому коннекту, к другому серверу.

Можно шардировать часть одних и тех же данных, т.е., например, мы берем и делаем несколько БД с юзерами.

Можно достаточно просто выбрать сервер — остаток от деления на количество серверов. Альтернатива — завести карту, т.е. для каждой записи держать в каком-нибудь Redis'е или т.п. ключ значения, т.е. где какая запись лежит.

Есть вариант проще:

Сложнее — это когда не удается сгруппировать данные. Надо знать ID данных, чтобы их достать. Никаких JOIN, ORDER и т.д. Фактически мы сводим наш MySQL или PostgreSQL к key-valuе хранилищу, потому что мы с ними ничего делать не можем.

Обычные задачи становятся необычными:

• Выбрать TOP 10.
• Постраничная разбивка.
• Выбрать с наименьшей стоимостью.
• Выбрать посты юзера X.

Если мы зашардировали так, что все разлетелось по всем серверам, это уже начинает решаться очень нетривиально. В этой ситуации возникает вопрос — а зачем нам, вообще SQL? Не писать ли нам в Redis сразу? А правильно ли мы выбрали хранилище?

Из коробки шардинг поддерживается такими штуками как:

• memcache;
• Redis;
• Cassandra (но она, говорят, с какого-то момента не справляется и начинает падать).

Как быть со статистикой?

Часто статистику любят считать с основного сервера — с единственного сервера БД. Это прекрасно, но запросы в статистике обычно жуткие, многостраничные и т.д., поэтому считать статистику по основным данным — это большая ошибка. Для статистики в большинстве случаев realtime не нужен, так что мы можем настроить мастер-слэйв репликацию и на слэйве эту статистику уже посчитать. Или мы можем взять что-нибудь готовое — Mixpanel, Google Analytics или подобное.

Это основная идея, которая помогает раскидывать все по разным серверам и масштабировать. Во-первых, от этого сразу виден профит — даже если у вас один сервер и вы начинаете в фоне что-то выполнять, юзер получает ответ гораздо быстрее, но и впоследствии размазывать нагрузку, т.е. мы можем перетащить всю эту обработку на другой сервер, можно обрабатывать даже не на PHP. Например, в Stay.com картинки ресайзятся на Go.

Как?

Можно сразу взять Gearman. Это готовая штука для обработки в фоне. Есть под PHP библиотеки, драйвера… А можно использовать очереди, т.е. ActiveMQ, RabbitMQ, но очереди пересылают только сообщения, сами обработчики они не вызывают, не выполняют, и тогда придется что-то придумывать.

Общий смысл всегда один — есть основное ПО, которое помещает в очереди какие-то данные (обычно это «что сделать?» и данные для этого), и какой-то сервис – он либо достает, либо ему прилетают (если очередь умеет активно себя вести) эти данные, он все обрабатывает в фоне.

Перейдем к архитектуре.

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

Связанность бывает в коде. SOLID, GRASP — это принципы, которые позволяют избежать связанности именно в коде. Но связанность в коде на разнос по серверам, конечно, влияет, но не настолько, насколько связанность доменного слоя с нашим окружением. Если мы в контроллере пишем много-много кода, получается, что в другом месте мы это использовать, скорее всего, не сможем. Нам непросто будет все это переносить из веб-контроллера в консоль и, соответственно, сложнее переносить на другие сервера и там обрабатывать по-другому.

Service-oriented architecture.

Есть 2 подхода разбиения систем на части:

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

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

2. правильное решение — бить на отдельные логические части, т.е. если в областях Sales и Customer используется модель user, то мы создаем 2 модели user. Они могут читать одни и те же данные, но представляют они их немного по-разному. Если разбить систему таким образом, то все гораздо лучше воспринимается и намного проще все это раскидать.

   Еще важно то, что части всегда должны взаимодействовать через интерфейсы. Так, в нашем примере, если Sales с чем-то взаимодействует, то он не пишет в БД, не использует общую модель, а с другими областями «разговаривает» через определенный контракт.
   

Что с доменным слоем?

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

Есть 2 книги про доменный слой, которые всем советую:

• «Domain-Driven Design: Tackling Complexity in the Heart of Software» от Eric Evans,
  
• «Implementing Domain-Driven Design, Implementing Domain-Driven Design».
  

Также советую сходить по ссылкам:

• про BoundedContext — http://ift.tt/LcVP0W (то, о чем было выше — если у вас две области вроде как пересекаются, но они
  разные, то стоит некоторые сущности продублировать, такие как модель user);
  
• про DDD в общем — http://ift.tt/1BuVuN3 — ссылка еще на одну книгу.
  

В архитектуре, опять же, стоит придерживаться принципа share nothing, т.е. если вы хотите что-то сделать общим, делайте это всегда сознательно. Логику предпочтительно закидывать на сторону приложения, но и в этом стоит знать меру. Никогда не стоит, допустим, делать хранимые процедуры в СУБД, потому что масштабировать это очень тяжело. Если это перенести на сторону приложения, то становится проще — сделаем несколько серверов и все будет выполняться там.

Не стоит недооценивать браузерную оптимизацию. Как я уже говорил, из тех 300-600 мс, которые запросы выполняются на сервере, к ним прибавляется 300-600 мс, которые тратятся на клиенте. Клиенту все равно, сервер ли у нас быстрый, или это сайт так быстро отработал, поэтому советую использовать Google PageSpeed и т.д.

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

Никогда не действуйте вслепую, всегда мониторьте, анализируйте. Вслепую практически все решения по умолчанию неправильные. Думайте! Не верьте, что существует «серебряная пуля», всегда проверяйте.

Еще немного ссылок полезных:

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

В англоязычном Интернете не знают слова «highload», поэтому там ищите по слову «sclability».

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

P.S. Полные слайды этого выступления см. на http://ift.tt/2iTDxmr и в блоге rmcreative.ru.

Контакты

» SamDark

Этот доклад — расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем HighLoad++ Junior за 2015 год.

— Старьё! — скажите вы.
— Вечные ценности! — ответим мы.

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

Ну и главная новость — мы начали подготовку весеннего фестиваля "Российские интернет-технологии", в который входит восемь конференций, включая HighLoad++ Junior.

Let's block ads! (Why?)

Персона. Командир Нортон

Питер Нортон известен большинству пользователей персональных компьютеров. Правда, не все об этом задумываются, не все представляют, насколько велики его заслуги. За плечами Питера годы работы над такими продуктами, как Norton Commander, Norton Utilities, Norton Disk Doctor. Он также является автором таких популярных книг, как «Внутри IBM PC», «Внутри OS/2» и «Справочник программиста».

Нортон создал новое направление разработки ПО. Он был новатором и с точки зрения рынка, и в техническом плане. Однако Питер Нортон работал не ради денег и славы. По крайней мере, сам он в это верит.

Питер Нортон появился на свет в 1943 году. Он познакомился с компьютерами еще в ранней юности, когда подрабатывал в страховой компании сезонным сотрудником. Его первым компьютером был IBM PC. Он приобрел эту машину, как только она появилась в продаже. Общение с компьютерами стало серьезным увлечением Питера: он освоил азы работы с ним в качестве пользователя, а затем приступил к самостоятельному изучению программирования.

Нортон учился в Ридоновском колледже (Портленд, штат Орегон). Затем он поступил в Калифорнийский университет в Беркли, который окончил со степенью бакалавра по математике.

После университета Питер Нортон устроился на работу в аэрокосмическую компанию, которая базировалась в Южной Калифорнии. Однако в конце 70-х отрасль начала сдавать позиции на рынке, и многие специалисты потеряли работу. Boeing, McDonnell Douglas и Lockheed провели масштабные сокращения.

Образовавшееся свободное время Нортон решил потратить на саморазвитие: он провел пять лет в буддийском монастыре на побережье Сан-Франциско.

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

Давай попробуем вернуть

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

В 1982 году Питеру удалось написать свою программу, которая анализировала скрытые участки памяти и позволяла найти утерянные данные. Он назвал ее «Unerase». Эта программа стала прообразом современных программ-утилит.

«Когда в 1982 году я написал свою новую программу Unerase, позволяющую восстановить случайно стертый файл, никому, казалось, такие программы были не нужны. Но я-то знал, какую ценность для меня и для моих друзей представляет написанная мной программа. Спустя некоторое время все поняли, как важно иметь возможность восстановить утерянные данные. Unerase фактически сформировала новый сектор рынка программных средств для PC, который называется рынком сервисных программ», — вспоминал Нортон.

Нортон и его команда

Питер Нортон создал свою первую компанию в 1982 году, имея на руках $30 тысяч и компьютер IBM. Компания получила название Peter Norton Computing. Правда, на начальном этапе единственным ее сотрудником был сам основатель.

В 1986 году компания выпустила на рынок оболочку Norton Commander (NC). Три первых версии разработал программист Джон Соча.

Версия 1.0

Джон Соча получил степень магистра и доктора Прикладной Физики Университета Корнелла. После окончания университета Джон стал первым директором отдела исследований и развития в Peter Norton Computing. Он был вторым программистом в компании:

Я начал работу над тем, что впоследствии стало известно как Norton Commander. Осенью 1984 года, когда я был еще аспирантом в области прикладной физики в университете Корнелла. Первые версии были написаны полностью на языке Ассемблера. Но на это требовалось слишком много времени, поэтому я вскоре перешел на смесь Си и Ассемблера, в то время как большинство «настоящих программистов» не воспринимало Си.

Я назвал его [Norton Commander] «Визуальный DOS» с аббревиатурой VDOS вместо обычных двухбуквенных сокращений, которые использовались в то время.

Тогда у меня был контракт с Microsoft Press, по которому я должен был написать несколько книг. Я взял два месяца аспирантуры и написал первую книгу.

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

Именно Соча привлек к работе еще одного программиста — Брэда Кингсберри.

Он стал разработчиком утилиты NCD, которая была позже интегрирована в Norton Commander как режим NCD:

Мой предыдущий работодатель только что закрыл свои двери, поэтому я разослал свое резюме в несколько компаний. Я присоединился к Peter Norton Computing в 1985. Питер ответил мне и оплатил билеты до Сиэттла, где он отдыхал в летнем отпуске, после чего нанял на месте. Но так как Питер был все еще в отпуске, я начал работу прямо из отеля в Сиэттле и проработал оттуда в течении первых двух недель. Далее, в течение следующих 6 месяцев я работал с кухонного стола PNCI. Когда Эйлин, жена Питера, начинала готовить ужин, я понимал, что рабочий день закончен и отправлялся домой.

Со временем сотрудников компании PNCI стало уже пять человек. Питер занимался разработкой, управлением, маркетингом и написанием мануалов из «берлоги» своего дома. А трое его сотрудников работали наверху.

Вся его [Нортона] философия сводилась к фразе, которую я от него постоянно слышал: «мы будем заниматься этим бизнесом пока это весело». Поэтому основным стимулом заниматься чем-либо было «круто» или «весело», а уже потом – деньги.

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

Версию NC 1.0 Джон Соча разрабатывал в 1984-1989 годах.

Norton Commander for DOS – это файловый менеджер для DOS, который существовал в 5 основных версиях – 1.0, 2.0, 3.0, 4.0, 5.0, причем только последняя версия имеет подверсию 5.5. Многие версии до сих пор используются различными энтузиастами и лежат на различных сайтах в сети Интернет.

Начиная с версии 2, на Norton Commander обрушился успех, сравнимый с успехом 123, WordPerfect и MS Word.

На территории бывшего СССР и восточной Европы синий экран Norton Commander стал синонимом DOS. Многие пользователи никогда и не подозревали что это не родной интерфейс DOS, а в русском языке слова «Нортон» и «коммандер» стали частью жаргона ИТшников, и стали, по сути, синонимами файлового менеджера.

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

Первые годы развития Norton Commander (1984-1988) совпали с рассветом MS-DOS: в то время она стала наиболее широко распространенной операционной системы на планете. Она быстро сменила CP/M, и начиная с конца 1983 многие программные продукты, созданные для MS-DOS стали доминирующими в своем классе и даже служили стандартом де-факто для портирования на другие ОС.

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

Версия 5

В 1989 году объем продаж компании Нортона составил $25 миллионов. В 1990 году Peter Norton Computing Incorporated объединилась с крупной калифорнийской компанией по производству программного обеспечения Symantec Corp. По мнению экспертов, капитал нортоновской компании составлял на момент слияния не менее $70 миллионов.

В 2002 году Нортон вошел в совет директоров компании Acorn Technologies, после того, как инвестировал в нее.

Личная жизнь и благотворительность

В 1983 году Питер Нортон женился на Эйлин Хэррис. У них двое детей.

Нортон — большой любитель искусства и науки. В 1989 году он основал Семейный фонд Нортонов Norton Family Foundation, который вкладывает около $1,5 миллиона в год в различные гуманитарные проекты.

Нортон часто помогает материально и другим фондам — борьбы со СПИДом, поддержки нищих, защиты одиноких людей. Чета Нортон также поддерживала финансами несколько музеев США.

В 2000 году Питер развелся с женой и переехал в Нью-Йорк. Через некоторое время он начал встречаться с Гвен Адамс, финансистом из Нью-Йорка. В мае 2007 года они поженились.

Другой Нортон

Если вы думаете, что Питер Нортон – это всего лишь «человек-диск», или в крайнем случае – бюро по розыску потерянных файлов, вы ошибаетесь. Нортон играл роль просветителя и в других аспектах аппаратного и программного обеспечения. Те, кто использует компьютер, каждый день чувствовали необходимость в «Руководстве по программированию» или в «Книге по языку Ассемблера». И если такая необходимость возникала, они в первую очередь обращались к Нортону, писала газета Washington Post в 1987 году.

Питер Нортон также был автором идеи «персонализации» продвижения программного обеспечения через использование фотографий одной и той же модели для всей линейки продуктов. Этот принцип до сих пор используется в компании Symantec. Нортон сам выступал в качестве фотомодели на коробках Norton Utilities и других продуктов Symanteс из линейки Norton.

У Питера Нортона был свой взгляд на разработку программного обеспечения. О своей концепции разработки компьютерных программ Питер Нортон рассказал во время своего визита в Москву на открытии выставки «Комтек-91» 8 апреля 1991 года: «Она состоит в ориентации на заказчика и пользователя, предугадывании рыночных тенденций, доработке программных продуктов с целью упрощения и оптимизации. Не стоит охотиться за новыми совершенными программами — гораздо проще, удобнее и действеннее разработать новую усовершенствованную версию на базе уже существующего программного продукта. Это привлекает хорошо знакомых с предыдущей версией программы пользователей».

Наиболее известные его программные продукты — это Norton Commander, NortonUtilities, Norton Disk Doctor, Norton Integrator. Norton Programmer's Guides — это серия из четырех автоматизированных справочников по языкам программирования: ASSEMBLER, С, PASCAL и BASIC. Эти справочники примечательны тем, что работают в режиме «онлайн» и позволяют получать всю необходимую в данный момент информацию, что гораздо удобнее, чем обращаться к справочному руководству.

*****

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

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

Let's block ads! (Why?)

[Перевод] Чистый javascript.Переменные

[Перевод] Чистый javascript.Введение

[Перевод] Неконтролируемые компоненты в React

Продолжение серии переводов раздела "Продвинутые руководства" (Advanced Guides) официальной документации библиотеки React.js.

Неконтролируемые компоненты в React

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

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

Например, следующий код принимает значение Имени из формы в неконтролируемом компоненте:

class NameForm extends React.Component {
  constructor(props) {
    super(props);
    this.handleSubmit = this.handleSubmit.bind(this);
  }

  handleSubmit(event) {
    alert('A name was submitted: ' + this.input.value);
    event.preventDefault();
  }

  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        <label>
          Name:
          <input type="text" ref={(input) => this.input = input} />
        </label>
        <input type="submit" value="Submit" />
      </form>
    );
  }
}

Поскольку в неконтролируемом компоненте хранение актуальных данных происходит в DOM — использование таких компонентов иногда позволяет проще интегрировать (соединять) React и не-React код. Если вас интересует меньший объем кода (и следственно скорость его написания) в ущерб чистоты кода — это вариант. В противном случае, лучше использовать контролируемые компоненты.

Значения по умолчанию

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

render() {
  return (
    <form onSubmit={this.handleSubmit}>
      <label>
        Name:
        <input
          defaultValue="Bob"
          type="text"
          ref={(input) => this.input = input} />
      </label>
      <input type="submit" value="Submit" />
    </form>
  );
}

Кроме того, <input type="checkbox"> и <input type="radio"> поддерживают атрибут defaultChecked, а <select> поддерживает defaultValue.

Предыдущие части:

• Ref-атрибуты и DOM в React.
• PropTypes — проверка типов в React.
• JSX — подробности.

Первоисточник: React — Advanced Guides — Uncontrolled Components

Let's block ads! (Why?)

Переведена документация Nuxt.JS

Всем привет от Translation Gang!

Vue.js нам показалось мало. Планов громадьё, причём даже за пределами русского языка, фронтенда и веба вообще, но на практике пока что далеко от Vue не убегали — благодаря стараниям theOnlyBoy мы оперативно перевели документацию фреймворка сверхвысокого уровня Nuxt.js.

• Официальный сайт с переводом
• Репозиторий на GitHub

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

Translation Gang продолжает трудиться на благо перевода документации open-source проектов.
В деле поддержания актуальности документации Vue.js мы недавно обогнали оригинал, за что спасибо Алекандру Соколову. В целом, негативных отзывов на качество перевода пока не поступало, а позитивных — в количестве, что нас очень радует. Так или иначе, PRs are more than welcome.

Очень хочется, чтобы из Translation Gang выросло большое и дружное международное сообщество добровольцев open-source переводов. Поэтому мы очень рады любой помощи: участию в переводе или вычитке, предложенному для перевода проекту, и даже просто рассказу о сообществе. Особенно полезно сейчас было бы попиариться в локальных зарубежных сообществах — так что если у кого-то есть выходы, мы были бы очень признательны. Спасибо!

Мы есть в VK

Let's block ads! (Why?)

Security Week 01-02: уязвимость в box.com, фишинг паролей в PDF, атаки на MongoDB

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

Начнем с интересного приема фишинга при помощи PDF, о котором сообщил SANS Institute. При открытии документа в этом формате пользователю сообщается, что он «заблокирован» и предлагается ввести логин и пароль. Пароль затем отправляется на сервер злоумышленника. Интересных моментов тут два. Во-первых, это фишинг вслепую: пользователь может ввести пароль от учетной записи или от почты, или вообще непонятно от чего. Злоумышленников это не волнует: расчет на то, что пароль везде одинаковый.

Во-вторых, при попытке отправить данные на сервер Adobe Reader выводит предупреждение. А вот, например, встроенный в браузер Microsoft Edge просмотрщик пересылает введенную информацию молча, без объявления войны. Похожий метод (сообщение о якобы заблокированном контенте) применяется в аттачах в формате MS Word, но там это сделано, чтобы заставить пользователя выполнить вредоносный код.

Box.com закрыл уязвимость, благодаря которой конфиденциальные документы можно было нагуглить
Новость.

Любопытная уязвимость была обнаружена исследователем Маркусом Нейсом из компании Swisscom. Он с помощью довольно тривиальных настроек поисковой системы нашел способ «гуглить» конфиденциальные документы, принадлежащие пользователям корпоративных аккаунтов сервиса Box.com. «Утечка» происходила, когда пользователь хотел поделиться информацией с кем-то, для чего создавал специальную ссылку. В таком случае предполагается, что доступ к контенту должен быть только при наличии ссылки, но выяснилось, что общие папки индексируются поисковиком.

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

У владельцев неправильно настроенных БД на MongoDB вымогают деньги
Новость.

И еще одна новость про неправильную конфигурацию. Виктор Геверс из GDI Foundation в конце прошлого года обнаружил несколько случаев атак на неправильно сконфигурированные базы данных MongoDB. Неправильно — в смысле доступных из сети с широкими правами. Атака происходила следующим образом: на сервере удалялось все содержимое базы данных и оставлялась записка с требованием выкупа в размере 0,2 биткоина (чуть больше 200 долларов). За прошедшие две недели количество атак выросло многократно. По состоянию на 9 января исследователи насчитали более 28 тысяч атакованных серверов.

WHOA... Latest #mongodb download from @shodanhq massive jump in ransomed databases 93TB gone (snapshots taken at 1530 and 2130 CET) http://pic.twitter.com/MakOlrbptt

— Niall Merrigan (@nmerrigan) January 8, 2017

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

А что еще остается делать?

Древности

«Amoeba-2367»

Очень опасный резидентный вирус-«призрак». Стандартно поражает .COM- и .EXE-файлы при их запуске или открытии. 21-го марта и 1-го ноября уничтожает информацию на винчестере. Перехватывает int21h. Содержит тексты:

«Tosee aworld in a grain of sand,
And a heaven in a wildflower
Hold Infinity in the palm of your hand
And Eternity in an hour.»;

«THE VIRUS 16/3/91 AMOEBA virus by the Hacker Twins ©1991 This is nothing, wait for the release of AMOEBA II-The universal infector, hidden to any eye but ours!»

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 59.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Let's block ads! (Why?)

Мой домашний дата-центр

Это не очередная статья о том, как какой-то «эконом» решил поставить сервер у себя в квартире и разместить веб-сайт дома, потому, что он ошибочно подумал, что это будет дешевле, чем в дата-центре. Без резервирования питания и каналов, без создания нужной климатической среды для эксплуатации серверного оборудования. С огромными счетами за электричество и недовольным провайдером Интернет, который не подписывался поставлять канал за «100 рублей» для сервера или стойки серверов :)

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

И первый из них и, пожалуй, самый достойный — домашний дата-центр проекта ve2cuy, организованный канадским IT-специалистом Alain Boundreault дома, не столько с целью экономии, сколько с целью воплощения различных custom-built решений, улучшения собственных навыков, ну и просто потому, что ему это было интересно и он это мог. Мое мнение — очень круто, неплохой workshop, не всегда подобные инфраструктуры могут быть настолько продуманы в реальных ЦОДах. И в добавок, это действительно экономические эффективное решение, полноценно удовлетворяющее потребности его создателя. Давайте с ним познакомимся? Alain Boundreault уже стал известным на YouTube и недавно выложил видео-экскурсию по своему домашнему дата-центру, оцените его работу сами:

Понятное дело, что Alain не единственный, кто строит подобные решения у себя дома. Но уникальность проекта ve2cuy в том, что Alain применил, хоть и устаревшее, но исключительно высококлассное оборудование от Dell, HP, Sun, Juniper и IBM, модернизировал электросеть, обеспечил климат и разместил все это в подвале собственного дома, в том числе оборудование высокой вычислительной плотности, такое, как IBM BladeCenter.

На его веб-сайте можно найти подробный обзор построенного решения, включая диаграмму всех компонентов, среди которых Open Stack MAAS (Metal as a Service) облако и множество систем хранения (iSCSI и Fiber Channel).

«Моим первым шагом стало усовершенствование электросети, установка электрощита, позволяющего обеспечить 40 ампер при 240 вольтах или 9.6 кВт⋅ч мощности. Серверы редко когда загружены одновременно, потому фактическое энергопотребление зачастую составляет всего лишь 1-2 кВт⋅ч, при стоимости электричества в Квебеке порядка 7 центов за кВт⋅ч, что обеспечивает высокую экономическую эффективность», говорит Boudreault, который обучает разработке ПО и использует построенное решение в том числе и для этих целей. Тем не менее он отмечает, что его тип домашнего ЦОД «не для слабонервных».

И автор понимает это. Ибо на вопрос, почему он не разместил веб-страницу собственного проекта на построенном дома решении, Alain ответил: «Я использовал для размещения ve2cuy один из домашних серверов ранее, но, проживая в сельской местности, мы подвергаемся слишком большому количеству сбоев питания. Мощности ИБП, установленного в моем ЦОДе, хватит не более, чем на 20 минут. Кроме того, мой провайдер блокирует порт 80, что сделало задачу довольно сложной. Спасибо за Ваш вопрос. P.S. У меня есть рабочая копия сайта на одном из серверов дома, быть может, в один прекрасный день, я вновь переведу её в рабочий режим».

К слову, с провайдером Интернет, имел проблему не только Alain, но и наш следующий участник, который известен под ником houkouonchi, установивший дома только 1 серверный шкаф и получивший с 2012-го года свыше 350 000 просмотров на YouTube:

На самом деле это «не настоящий дата-центр, но не во многих домах размещен полноразмерный серверный шкаф с более, чем 150-терабайтным хранилищем в нем», пишет houkouonchi. «Этот шкаф прикручен сквозь деревянный пол прямо к цементному фундаменту. Полностью заполненная оборудованием стойка потребляет около одного кВт⋅ч мощности».

В 2013-м году с ним связался его Интернет-провайдер Verizon, который был весьма удивлен увидеть свыше 50 терабайт трафика в месяц от клиента с тарифным планом домашнего пользования. Оказалось, что размещение медиа-серверов, нарушает условия предоставления услуг домашним пользователям и houkouonchi пришлось перейти на тарифный план для бизнес-абонентов.

Стоит также отметить интересное объяснение houkouonchi, по поводу того, почему в его серверах дома нет дисков Seagate:

«Серверы поставляются с дисками Seagate, мы их заменяем на Hitachi, так как практически все диски, что Вы видите на видео — вышедшие из строя диски в партии из 100 серверов».

Серверный шкаф из IKEA?

Зачем использовать стандартный серверный шкаф из дата-центра дома, если можно использовать стильный столик из IKEA? До такого додумались энтузиасты из Нидерландов, когда обнаружили, что шведские столики LACK, имеют пространство между ножками ровно в 19 дюймов, такой же ширины, как у слота серверной стойки в центре обработки данных, а значит, можно крепить свитчи и серверы!

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

С момента своего первого появления в 2010 году, LACKRack преобразился в дизайне и даже приобрел модификации. Технологический евангелист Frank Dennemen из PernixData в своей статье о новой, модифицированой им, передвижной версии LACKRack, отметил, что порой он хочет что-то сломать или убить сервер целиком, чтоб посмотреть, что будет, и для этих целей ему очень нужна домашняя лаборатория, а так, как, 19-дюймовые стандартные шкафы не вписываются в дизайн современных интерьеров, полезно иметь что-то типа LACKRack, только с колесами, чтоб иметь возможность удобно передвигать по дому. Результат можем видеть ниже:

Организация домашних лабораторий и дата-центров с целью тестирования приложений и разработки, становится все более популярной, сейчас в сети Интернет можно найти достойные влоги на эту тему, один из запомнившихся — GNET Data Center Project, тем не менее еще больше проектов остаются скрытыми от общественности. Возможно Вы организовали свой домашний мини-ЦОД, или знаете еще какой-то достойный проект? Поделитесь им в комментарии.

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

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

Комментатор, оставивший наиболее полезный комментарий по теме статьи и получивший наибольшее количество плюсиков в течении последующих 7 дней, имеет право запросить полноценный выделенный сервер в Нидерландах 2 х Intel Dodeca-Core Xeon E5-2650 v4 / 128GB DDR4 / 6x480GB SSD / 1Gbps 100 ТВ до конца зимы бесплатно, при условии оплаты услуги на март месяц.

Let's block ads! (Why?)

[Перевод] Ref-атрибуты и DOM в React

tiny-dnn — анонс библиотеки

Форма подписки: как эффективно собрать базу адресов

100 выпуск Digest MBLTdev — свежак для iOS-разработчиков

Сегодня для вас выходит сотый выпуск дайджеста. У нас нет слонов и плюшек. Мы не дарим футболки и нечасто раздаём промо-коды. Всё, что у нас есть — наша собственная каждодневная работа, находками из которой мы делимся с вами. Спасибо, что читаете нас. Выпуск под катом.
Пользуясь случаем, хотелось бы перечислить поименно тех, благодаря кому рассылке уже сто недель: Fanruten (Яндекс), vancher (Aviasales), Александр Зимин (Uberchord), NicoleK (Devim), iSasha (e-Legion), alexchernyy (Ivideon) и, конечно, лично вы, читающий этот текст. А теперь к делу.

10 ways the iPhone changed the world
iPhone стал совсем взрослым. 10 лет. Посмотрим, чем Apple нас порадует в следующую декаду.
telegraph.co.uk

Apple, Facebook and Google top Greenpeace’s clean energy report
Зеленее просто некуда. Для потребителя (особенно из России) это не играет роли от слова совсем. Но так-то Apple большие молодцы, их можно только похвалить. Когда-нибудь эта история доберется и до России. Наверное.
techcrunch.com

Update on the Swift Project Lead
Chris Lattner, который является автором LLVM и Swift, покинул Apple и теперь работает в Tesla.
lists.swift.org

Swift 3.1 Release Process
Уже весной нам обещают новый Swift 3.1, который совместим с 3.0 и содержит различные улучшения.
swift.org

IGListKit 2.1.0
Появилась поддержка macOS. Посоны даже запилили туторил у Рэя.
engineering.instagram.com

MVVM and RxSwift
Очень понятный доклад на уже давно хайповую тему.
realm.io

Bringing Wide Color to Instagram
С 7-м iPhone появился фича под названием “Wide Color”. Теперь камера и экран могут работать с большим количеством цветов. И если ваше приложение построено вокруг просмотра фотографий, то неплохо проверить, что пользователь видит все как надо, а не обрезанные цвета, как на древних iPhone.
engineering.instagram.com

Creating a Compelling Today Widget
Как ребята из PSPDFKit делали виджет с динамическим размером (сворачивается и разворачивается) для iOS 9/10. Не так чтоб сложно, но приятно изложено.
pspdfkit.com

Hero
Pod для организации красивых переходов. Заметили, что красивая анимация всем нравится, и как только появляется новое решение, все о нем пишут? Вот и нам тоже нравится красивая анимация.
github.com

Crazy Fast Builds Using distcc
Как с помощью distcc сделали компиляцию проекта параллельно на нескольких машинах в рамках одной сети. Занятно, что раньше distcc был частью Xcode, а потом перестал.
pspdfkit.com

Gifu 2.0
Обновился pod для использования GIF. iOS 9.0+ и Swift 3.0. Поддержка Swift 2.3 есть в отдельной ветке.
cocoapods.org

Design Patterns implemented in Swift 3.0
Пример использования разных паттернов проектирования на Swift.
github.com

Git back to the future
Для тех, кто не знает, что такое “git reflog” и как восстановить потерянные коммиты.
philna.shg

Swish
Интересный скриптик, который позволяет собирать Swift код на удаленном Linux хосте, не покидая Xcode.
github.com

XShared
Расширение для Xcode. Очень простое: обрамляет копируемый текст с помощью ```, чтобы затем можно было сразу вставить в Slack или Telegram. И смех вроде. А ``` набирать напрягает. Особенно в Telegram.
github.com

iOS Awesome Starter Kit
Одно из видений “джентльменского” набор для опытного разработчика, который работает сам на себя.
github.com

How to create effective push notifications
Чрезвычайно актуальная статья о том, как сделать действительно классные push-уведомления. Справляются с этой задачей, прямо скажем, немногие.
uxplanet.org

Stepik Contest
Наверное, самая большая российская платформа онлайн-курсов проводит конкурс на создание курсов. И знаете, я что-то не вижу ни одного курса по Swift там. Может, вы?
adaptive.stepik.org

Предыдущие выпуски Digest MBLTdev и подписка доступны на официальном сайте.
Всё бесплатно и никакого спама, честно!

Let's block ads! (Why?)