Сервер времени яндекс: NTP Server :: База знаний MSK-IX

Новый OpenID-сервер Яндекса

Имею удвольствие сообщить веб-сообществу, что мы недавно вдохнули вторую жизнь в наш яндексовый OpenID-сервер — http://openid.yandex.ru/. Хотя надо сказать, что во время первой его жизни не так уж и много людей знало, что в Яндексе он вообще есть, в связи с чем я хочу про него потрепаться немножко подробней.

OpenID-сервер работает у нас уже довольно продолжительное время, хотя, надо признаться, был он довольно покинутым: поддерживал только первую версию OpenID, не предоставлял никаких дополнительных возможностей и, в общем-то, не имел планов развития. Это меня, как большого любителя всей этой технологии, немножко огрочало. И вот месяц-другой назад у меня в группе появился новый программист — Володя Епифанов — на которого я и решил свалить написание нового сервера. Он с этим успешно справился, и сейчас openid.yandex.ru это:

OpenID 2.0

Новая версия протокола, доработанная и, на самом деле, в последнее время превалирующая.

Поддержка SRE и микроформата hCard

Через SRE и hCard сайты, на которые логинится пользователь, могут узнавать о нем дополнительную информацию. Сейчас это самый минимум — никнейм (он же логин), однако и это уже приятно работает. Например, если оставить комментарий на Blogger.com, подписываясь своим OpenID, то Blogger сразу подставит ваш яндексовый логин в качестве имени.

Делегация через Я.ру

Помимо адреса http://openid.yandex.ru/username, который автоматически есть у всех пользователей Яндекса, те, у кого есть страница на Я.ру, могут подписываться своим красивым коротким адресом: username.ya.ru

Модные технологии

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

Отдельного упоминания заслуживает делегация через Я.ру. Легко заметить, что запрашивая этот адрес в браузере, вы в результате цепочки редиректов оказываетесь на странице с URL’ом типа http://username.ya.ru/?ncrnd=1971, которую OpenID-консумеры и считают финальным «правильным» адресом пользователя. Помимо того, что он уродлив, он просто не может служить идентификатором, потому что его банально невозможно указать еще раз: ncrnd всегда будет разным :-). Аккуратное откручивание этой штуки заняло довольно много времени и потребовало изучения самых тайных закоулков OpenID-спецификации. Большое спасибо ребятам, обслуживающим HTTP-сервер на Я.ру, за сотрудничество и терпение!

На некоторых сайтах, кстати, авторизация через username.ya.ru таки не работает, но мы работаем над этим.

Планы

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

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

2. Напишем некоторое количество текста, объясняющего, что это все такое, зачем это надо пользователю, чем чревато.

3. Есть интересная идея придумать (или найти придуманный) протокол, которым Яндекс сможет сообщать целевому сайту относительный уровень доверия пользователю. Сейчас у сайта, который принимает яндексового юзера, есть уверенность только в том, что это не робот, потому что у нас есть CAPTCHA при регистрации. Но ведь мы на стороне сервера знаем, какими сервисами пользуется юзер, а значит можем прикинуть, что если пользователь активно пишет в свой ярушный блог и регулярно загружает фотки, то это скорее всего не спамер, а нормальный сетянин.

4. Я хочу обратиться ко всем в рунете, кто делает OpenID-логины. В большинстве случаев сейчас OpenID логин выглядит очень по-гиковски, и нормальным людям его показывать нельзя. Но есть и исключения типа формы на блоге Евгения Степанищева.

   В идеале пользователю вообще не желательно показывать слова «OpenID», а давать понять, что он может просто залогиниться своим логином с другого известного сайта. Для западного интернета такими узнаваемыми провайдерами являются AOL, Yahoo. У нас — ЖЖ, Лайв Интернет, Мой Круг и теперь вот Яндекс. Я думаю это важно, потому что у Яндекса пользователей много, и это, в основном, как раз не гиковская аудитория. Поэтому призываю всех делать формочки, в которых пользователь может выбрать букву «Я», вписать свой логин, а формочка уже сама сделает из него

   http://openid.yandex.ru/username.

Как инфраструктура Яндекс.Почты выросла за 13 лет / Хабр

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

Сейчас мало кто помнит, что самая первая версия Яндекс.Почты была написана на PHP, а письма хранились прямо в реляционной БД рядом с мета-информацией. В том не таком уж и далёком 2000 году весь почтовый сервис умещался на десятке серверов. Сами сервера обслуживались полностью в ручном режиме: от конфигурации дисков до установки операционной системы, никакой автоматизации не было.

2002 год

Первым, от чего пришлось отказаться, стал язык PHP. В то время он чаще мешал, чем помогал развиваться.

Вокруг было много первоклассных Perl-специалистов, под сам Perl уже тогда существовало огромное количество библиотек, и мы переписали почту на связке Apache + Perl. Стало быстрее и проще.

2005 год

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

модель обработки запросов, очень удобен для подключения расширений, в том числе интерпретаторов языков — например, JS. Сервер, как и большая часть кода Яндекс.Почты, написан на C++. Во многом это библиотека для сетевого обмена и работы с тредами, которая была нужна для того, чтобы обеспечить работу сервиса при росте нагрузок.

В этот сервер для облегчения эксплуатации встроен real-time мониторинг его состояния. Вдобавок мы полностью отказались от Perl. Вместо него был создан отдельный Baida-модуль — Web Mail Interface, который внутри себя содержал интерпретатор XScript: парсер XML и движок XSLT-преобразований. Другая особенность — пул соединений с реляционным мета-хранилищем и эффективное управление этим пулом.

2006 год

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

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

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

2007 год

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

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

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

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

2008 год

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

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

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

Теперь пришла пора заменить Postfix на приеме почты. Свой собственный SMTP-сервер мы назвали NwSMTP. Он был задуман как event-based сервер, способный обрабатывать неограниченно большое число соединений. Аналогично устроен небезызвестный web-сервер NGINX, но на тот момент в нем не было поддержки SMTP-proxy. Так мы начали принимать письма практически мгновенно. Разработка NwSMTP была устроена довольно интересно: выкатки происходили очень часто — иногда по версии в час. Сразу после сборки новой версии ее выкатывали на одну production-машину и смотрели, что происходит. Такая оперативность позволила очень быстро выпустить продукт. Отсюда пошло название NwSMTP, это сокращение от Next Week SMTP: почти любая задача в нем за семь дней проходит полный цикл разработки и на вопрос «Когда вы это сделаете?» группа разработки сервера отвечает: «На следующей неделе».

В середине 2008 года, когда у нас запустился Jabber-сервер, мы в качестве эксперимента сделали real-time уведомления о новых письмах. Чтобы не тормозить систему покладки, нотификации работали по UDP-протоколу, а внутри содержали XML-данные, удобные для превращения в XMPP-пакет. Сегодня шутки про «XML по UDP» вызывают улыбку, но в то время это работало, хотя и с большими ограничениями и потерями части нотификаций.

2009 год

К этому времени в Яндекс.Почте одновременно работало несколько интерфейсов. Neo не был интерактивным: HTML-страница генерировалась внутри WMI. Modern содержал интерактив, но был построен на той же архитектуре.

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

С переходом на динамику очень сильно поменялась структура запросов. К этому времени сервер nginx достаточно развился и мы решили поставить его перед Baida для отдачи статики в Почте (к этому времени он уже использовался, например, в Народе). Одновременно с Daria мы экспериментировали с запуском интерпретируемых языков на стороне сервера. Остановились на Javascript в основном из-за удобства, так как на клиенте и сервере используется один и тот же язык программирования. Под сервер Baida написали модуль с TraceMonkey, встроить V8, к сожалению было невозможно. Он уже был популярен, но V8 на тот момент не мог работать с тредной моделью программирования (в последних версиях V8 этот недостаток исправлен).

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

В этом году мы сделали треды, что безусловно, сильно отразилось на структуре БД и нагрузке.

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

Отдельная история про просмотрщик документов

Как-то мы захотели проверить, насколько востребованным будет сервис просмотра документов. Удалось очень быстро разработать прототип на python и поднять ферму OpenOffice, который конвертировал документы в HTML. Перед сервисом поставили nginx для защиты от всплесков нагрузки, добавили модуль обращения в хранилище за документами и отдали в эксплуатацию. В таком виде прототип просуществовал несколько лет, оброс мониторингами, оптимизациями и второстепенными возможностями. Сейчас эксплуатируется уже вторая версия просмотрщика, которая впрочем работает примерно на тех же технологиях.

2010 год

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

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

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

2011 год

Мы активно начали предлагать нашим пользователям использовать HTTPS для защиты передаваемых данных, а затем включили защищенную работу с почтой по умолчанию. Это решение, с одной стороны, сделало работу с Яндекс.Почтой более безопасной, а с другой — потребовало от нас работы по настройке параметров соединения. Классически почта работает на длинных HTTPS-подключениях с большим значением keepalive. Однако в смартфонах этот режим подключения часто ограничен или работает странно. При HTTPS-соединении возникают дополнительные накладные расходы на рукопожатие, а если браузер не хочет или не может держать открытым соединение, то каждый запрос будет вызывать дополнительные расходы. На узких каналах и слабых процессорах телефонов это время становится заметным. Сразу после включения HTTPS по умолчанию мы увидели, как выросли графики времени загрузки интерфейса почты, и потребовалось некоторое время на поиск причин и решение проблемы. Другой проблемой стало отображение HTTP-содержимого писем по HTTPS, например, изображений, добавленных через тег. Мы построили отдельный сервис, который кеширует изображения и способен отдавать их по HTTPS, после чего, заменили вставленные в письма изображения на ссылки нашего прокси. При проектировании подобных сервисов важно не допустить появления открытого редиректа — возможности открыть любой URL с доверенного хоста, а добавление уровней защиты не должно приводить к заметному снижению производительности. Мы справились и с этой задачей.

Тогда же начались первые эксперименты с нереляционными хранилищами данных. Первым сервисом, который был переведен на NoSQL (

), стала адресная книга. До этого момента у эксплуатации почты не было боевого опыта работы с внешними нереляционными технологиями хранения. Этот эксперимент удался — адресная книга и сегодня хранит книжки контактов в MongoDB.

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

Произошли изменения и в процессах разработки. Web Mail Interface, о котором говорилось выше, начал использовать Scrum и гибкие технологии разработки. Нам удалось реализовать цикл непрерывной выкладки новой функциональности, при котором каждая фича или исправление дефекта выкладывается отдельно, но при этом проходит полный производственный цикл: разработку, автоматическое тестирование, функциональное тестирование, нагрузочное тестирование, и, наконец, двухэтапная выкладка в бой — сначала на один сервер, а потом уже на весь кластер. Такой процесс позволяет очень быстро реагировать на появление новых продуктовых требований и устранять дефекты.

Наши дни

Запуск Яндекс.Диска значительно изменил наши протоколы эксплуатации оборудования. Диск, так же как и Почта, использует Mulca, чтобы хранить файлы пользователей, но при этом объемы загружаемой информации превосходят почтовые в несколько раз. Каждый месяц мы добавляем не менее пяти стоек серверов в Mulca, чтобы обеспечить надежное хранение ваших писем и файлов. Пропорционально выросли и потребности в пропускной способности опорной сети и сети внутри ДЦ. Объемы данных таковы, что в долгосрочной перспективе мы перешли от планирования установки стоек к планированию открытия новых дата-центров.

Чтобы оживить почтовый ящик, мы разработали и запустили технологию «Ева», которая из открытых источников собирает аватары пользователей и показывает их. Все аватары масштабируются, обрезаются и кешируются в специальном хранилище, в основе которого лежит другая наша разработка, — Elliptics — отказоустойчивое распределенное key-value хранилище, распространяемое под лицензией GPL.

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

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

Тем временем в интернете назрели крупные перемены. Пространство адресов IPv4 подошло к концу, а 6 июня 2012 года считается Днем IPv6. К этому событию мы подготовили нашу внутреннюю архитектуру к работе в сетях IPv6. Сегодня IPv6 работает для домена mail.yandex.com и для отправки почты. Мы активно работаем над полной поддержкой IPv6 во всех компонентах и для всех наших доменов.

XScript, устраивавший нас долгое время, был окончательно исключен из работы почты. Теперь почта представляет собой статическое web-приложение, которое общается с бекендом посредством коротких вызовов API. Вызовы по-прежнему обрабатываются внутри WMI сервером Baida и транслируются через один из его модулей.

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

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

«Яндекс» обеспечит Россию серверами | ComNews

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

«Яндекс» и Gigabyte предоставят патенты, технологии и собственные разработки серверного оборудования. Специалисты Gigabyte также будут заниматься запуском и отладкой производства. «Яндекс» и «Ланит» выделят инвестиции для проекта, кроме того, «Ланит» обеспечит дистрибуцию и сервисные центры. ВТБ выступит финансовым инвестором СП.

Еще до открытия завода «Яндекс» планирует частично перенести производство своих серверов из Китая и Тайваня в Россию. «Яндекс» не только будет устанавливать эти серверы в собственных дата-центрах и использовать для расширения облачной платформы Yandex.Cloud, но и вместе с партнёрами предложит их рынку.

По данным International Data Corporation (IDC), рынок серверного оборудования в России к концу 2020 г. оценивался в $1,3 млрд и за год вырос более чем на 18%.

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

«У «Яндекса» и Gigabyte есть уникальные разработки серверных технологий. У «Ланит» компетенции в дистрибуции и внедрении решений. Вместе мы сможем предложить конкурентоспособный продукт для клиентов в России и за рубежом», — отметили в пресс-службе «Ланит».

Пресс-служба «Ланит» не раскрывает, какой объем инвестиций планируется потратить на строительство завода. Основные инвестиции нематериальные — разработки и экспертиза участников.

«Первые серверы должны быть выпущены на заводе уже в 2022 г. Речь идет про полный цикл производства: от пайки до финальной сборки. Это будут заказчики как из корпоративного, так и из государственного сегмента», — сообщили в пресс-службе «Ланит».

«Инвестиция в новое СП с «Яндексом» и группой компаний «Ланит» является новым шагом в расширении сотрудничества ВТБ с «Яндексом». Мы наблюдаем устойчивый рост рынка серверов, а также рост спроса на услуги хранения данных, поэтому для нас это также и интересная финансовая инвестиция в перспективный сектор», — сообщили в пресс-службе ВТБ.

Руководитель направления вычислительных инфраструктур ИТ-компании «Крок» Александр Сысоев отмечает, что идея производить серверы или хотя бы просто локализовать это производство на территории России — весьма здравая. Она перекликается со стратегией импортозамещения. Продукция, которая будет занесена в реестр российской радиоэлектронной продукции, должна заинтересовать в первую очередь компании с государственным участием, так как им необходимо заменять импортное оборудование на российское. В целом, считает Александр Сысоев, инициатива может оказать положительный эффект на развитие всего ИТ-рынка, так как поможет расширить спектр представленных решений для более оптимального решения задач клиентов.

«Однако непонятны до конца перспективы этого совместного предприятия — пока мы видим лишь заявление о намерениях. Очевидно, что для локализованного производства понадобятся огромные инвестиции, а их окупаемость будет зависеть от качества продукции», — подчеркивает Александр Сысоев.

Начальник управления торговых операций на российском фондовом рынке «Фридом Финанс» Геогрий Ващенко отмечает, что размер потребных инвестиций — не менее $300-400 млн.

«Фактически речь может идти о локализации производства в России. Основная проблема, по всей видимости, не деньги, а нехватка чипов, дефицит которых, по некоторым оценкам производителей, исчезнет не ранее середины будущего года. Иначе завод будет загружен не в полную силу. Впрочем, строительство тоже займет не менее года, к тому времени проблемы с комплектующими могут быть решены. А кроме того, вопрос локализации производства важен с точки зрения продаж оборудования в сфере госзаказа. Для «Яндекса» очевидно не только использование в своих проектах, но и сдача в аренду мощностей», — отмечает Георгий Ващенко.

Аналитик ГК «Финам» Леонид Делицын оценивает стоимость запуска СП в 200-350 млн руб.

Почтовый сервер-сателлит Яндекса на базе ОС Debian и Postfix

Введение

Итак, у нас задача создать почтовый сервер для рассылки почты, но не хочется заморачиваться со всякими pgp, dkym и глубокими настройками почтовика…

Что нам нужно:

• аккаунт на яндексе, для примера пусть это будет «[email protected]» с паролем «mypassword»;
• доменное имя;
• …делегированное яндексу [https://pdd.yandex.ru]
• …с настроенным dns.

После того, как настроили несущий аккаунт яндекса и домен, нам необходимо настроить debian-сервер.

Установка Postfix

Первое, что делаем — устанавливаем postfix (я фанат постфикса по причине его гибкости, кучи простых и понятных вариаций настройки).

shapt-get install postfix

после чего aptitude снесёт установленный по умолчанию exim4

exim надо добить!
выясняем имена пакетов для добития

shdpkg -l|grep exim4

должен выплюнуть 4 пакета, которые удаляем командой

shdpkg -P \
    exim4 \
    exim4-common \
    exim4-base \
    exim4-common exim4-daemon-light \
    exim4-daemon-heavy

Останавливаем постфикс

shservice postfix stop

Настройка Postfix

Первым делом создаём файлы

Чистит логи почтовика — может понадобиться при глубокой настройке постфикса для чистоты эксперимента
/etc/postfix/_cleanup.sh

shell#!/bin/sh
clear
truncate -s0 \
	/var/log/mail.*

Создаёт lookup-карты паролей, «транспорта» итп
/etc/postfix/_postmap.sh

shell#!/bin/sh
clear
postmap /etc/postfix/generic
postmap /etc/postfix/mailpasswd
postmap /etc/postfix/transport

Запуск/перезапуск -скрипты, чтобы не носиться с консолью
/etc/postfix/_restart.sh

shell#!/bin/sh
clear
service postfix restart

/etc/postfix/_stop.sh

shell#!/bin/sh
clear
service postfix stop

/etc/postfix/_start.sh

shell#!/bin/sh
clear
service postfix start

Смотрит в реальном времени лог почтовика — понадобится для тестирования
/etc/postfix/_tail.sh

shell#!/bin/sh
clear
tail -f /var/log/mail.log

Запускает тест
/etc/postfix/_test.sh

shell#!/bin/sh
clear
mail -s "test" [ВАШ EMAIL АДРЕС] < /dev/null

/etc/postfix/generic
Файл несёт в себе отношения пользователя в системе ко внешнему пользователю.
То есть для каждого пользователя можно настроить разные внешние почтовые сервисы.
ВНИМАНИЕ! ИМЕННО «РАЗНЫЕ» ! То есть два аккаунта яндекса я настроить не смог, кто сможет — пишите.

[email protected]						[email protected]
[email protected]ВАШ_ДОМЕН						[email protected]

[email protected]					[email protected]
[email protected]ВАШ_ДОМЕН					[email protected]

ПОЛЬЗОВАТЕЛЬ@localhost					[email protected]
ПОЛЬЗОВАТЕЛЬ@ВАШ_ДОМЕН					[email protected]

Подразумевается, что виртуальный хост запущен от «ПОЛЬЗОВАТЕЛЬ», равно, как и PHP исполняется от него.
Смотри статью «Установка и настройка Debian Linux в качестве хостинга» [https://laravel.ru]

/etc/postfix/mailpasswd
Файл несёт в себе пароль от яндексового аккаунта

[smtp.yandex.ru]:587	[email protected]:mypassword

/etc/postfix/transport
Файл указывает на «транспорт» для сателлита для всей исходящей почты

*	smtp:[smtp.yandex.ru]:587

/etc/postfic/mail.cf

confsmtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
readme_directory = no
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
myhostname = ВАШ_ДОМЕН
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = ipv4
relayhost = smtp.yandex.ru:587
smtp_destination_rate_delay = 60
relay_destination_rate_delay = 60
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/mailpasswd
smtp_sasl_security_options = noanonymous
transport_maps = hash:/etc/postfix/transport
smtp_generic_maps = hash:/etc/postfix/generic
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_use_tls = yes

Создаём линк на сертификат (нужен для нормальной работы)

shcd /etc/postfix
ln -s cacert.pem /etc/ssl/certs/Equifax_Secure_CA.pem

Запуск и тест

Запускаем

shcd /etc/postfix
./_postmap.sh
./_cleanup.sh
./_start.sh
./_test.sh
./_tail.sh

Следом прячем доступ к чтению паролей не root-пользователям

shcd /etc/postfix
chmod 0600 generic
chmod 0600 mailpasswd
chmod 0600 transport
chmod 0600 *.db

Смотрим в почту — пришёл тест === работает
Не пришло — смотрим логи через tail и разбираемся.

От автора

Данный сетап идеален для VPS/VDS в виде сайт/машина или домен/машина или проект/машина.

Данный сетап идеален, если нет возможности содержать собственный DNS сервер и/или собственный Почтовый сервер, так как требует каких-то иных действий, недоступных пользователю/админу. За примерами далеко ходить не надо — стартап/1-3 работника в проекте и все программеры со слабыми скилами в администрировании итп.

В 9 из 10 случаев эта конфигурация запускается «сполпинка».
1 из 10 это случай, когда машина не голая (не только что установлена) и требуется поплясать с бубном.

Хоть исходящий адрес будет настраиваемым, промежуточный яндексовый может светиться, как релей в исходнике письма. Это БЕЛЫЙ способ рассылки, что-то спрятать не удастся.

И имейте ввиду, что у яндекса есть неявный лимит на рассылку, ~ стартапа конечно вряд ли коснётся, но всё же.

И да, тут приятная побочка…
Используя АП яндекса можно пользователям выдавать ящики 😉

Как вы считаете, полезен ли этот материал? Да Нет

  3600
  

  <сжатие>
    <кейс>
      ...
      ...
      <метод>...
      <уровень>...
    
    ...

  

  <сжатие вкл="clickhouse_compression">
    <кейс>
        10000000000
        0,01
        <метод>zstd
        <уровень>1
    

  

  <кодеки_шифрования>
    
        <ключ>1234567812345678
    

  

  <кодеки_шифрования>
    
        00112233445566778899aabbccddeeff
    

  

  <кодеки_шифрования>
    
        
    

  

  <кодеки_шифрования>
    
        00112233445566778899aabbccddeeff
        
        1
    

  

  <кодеки_шифрования>
    
        012345678910
    

  

  <кодеки_шифрования>
    
        abcdefabcdef
    

  

  настраиваемый_
  

  
    1073741824

  

  по умолчанию
  

  по умолчанию
  

  /clickhouse/tables/{uuid}/{shard}
  

  {replica}
  

  *_dictionary.xml
  

  истина
  

  
  format_schemas/
  

  <графит>
    <хост>локальный
    <порт>42000
    <время ожидания>0,1
    <интервал>60
    одна_мин
    истина
    <события>истина
    ложь
    истина

  

  
    <по умолчанию>
        <функция>макс
        <удержание>
            <возраст>0
            <точность>60
        
        <удержание>
            <возраст>3600
            <точность>300
        
        <удержание>
            <возраст>86400
            <точность>3600
        
    

  

  9999
  

  
  
]]>

  

  600000
  

  /etc/metrica.xml
  

  9009
  

  пример.clickhouse.com
  

  9010
  

  example.clickhouse.com
  

  
    <пользователь>администратор
    <пароль>111
    истина

  

  
    <пользователь>администратор
    <пароль>222
    <старый>
        <пользователь>администратор
        <пароль>111
    
    <старый>
        <пользователь>время
        <пароль>000
    

  

  10
  

  ::1
<слушающий_хост> 127.0.0.1
  

  4096
  

  <регистратор>
    <уровень>след
    /var/log/clickhouse-server/clickhouse-server.журнал
    /var/log/clickhouse-server/clickhouse-server.err.log
    <размер>1000M
    10

  

  <регистратор>
    1
    <системный журнал>
        <адрес>syslog.remote:10514
        myhost.local
        <объект>LOG_LOCAL6
        системный журнал
    

  

  
    true

  

  <макросы вкл="макросы" необязательные="истина" />
  

  5368709120
  

  0,9
  

  100
  

  100
  

  100
  

  5
  

  99
  

  10
  

  4096
  

  262144
  

  0
  

  12000
  

  1200
  

  12000
  

  <дерево_объединения>
    5

  

  <кликхаус>
    <метрика_лог>
        <база данных>система
        метрика_журнал
        7500
        1000
    

  

  <кликхаус>


  

  
    5

  

  
    <сервер>
        
        /etc/clickhouse-server/server.crt
        /etc/clickhouse-server/server.key
        
        /etc/clickhouse-server/dhparam.pem
        нет
        true
        true
        sslv2, sslv3
        true
    
    <клиент>
        true
        true
        sslv2, sslv3
        true
        
        <инвалидсертификатехандлер>
            
            Обработчик сертификатов отклонения
        
    

  

  
    <база данных>система
    part_log
    до понедельника(event_date)
    7500

  

  <путь>/var/lib/clickhouse/
  

  <прометей>
        <конечная точка>/метрики
        <порт>8001
        истина
        <события>истина
        истина
    
  

  <журнал_запроса>
    <база данных>система
    журнал_запросов
    Engine = MergeTree РАЗДЕЛЕНИЕ ПО event_date ORDER BY event_time TTL event_date + INTERVAL 30 day
    7500

  

  <журнал_потока_запроса>
    <база данных>система
    query_thread_log
    до понедельника(event_date)
    7500

  

  
    <база данных>система
    query_views_log
    доГГГГММ(event_date)
    7500

  

  <кликхаус>
    <текст_лог>
        уведомление
        <база данных>система
        текстовый_журнал
        7500
        
        Engine = MergeTree РАЗДЕЛЕНИЕ ПО event_date ORDER BY event_time TTL event_date + INTERVAL 30 day
    

  

  
    <база данных>система
    trace_log
    доГГГГММ(event_date)
    7500

  

  Азия/Стамбул
  

  9000
  

  9440
  

  9004
  

  9005
  

  /var/lib/clickhouse/tmp/
  

  8589

  /var/lib/clickhouse/user_files/
  

  users.xml
  

  <узел index="1">
        <хост>пример_хост
        <порт>2181
    
  

  Атрибут index указывает порядок узлов при попытке подключения к кластеру ZooKeeper.
  

  <смотритель зоопарка>
    <узел>
        <хост>пример1
        <порт>2181
    
    <узел>
        <хост>пример2
        <порт>2181
    
    30000
    10000
    
    /path/to/zookeeper/node
    
    пользователь:пароль

  

  
    
    /clickhouse/task_queue/ddl

    
    <профиль>по умолчанию

    
    1

    

    
    604800

    
    60

    
    1000

  

  
    
        <путь>/etc/clickhouse-server/users.xml
    
    <локальный_каталог>
        <путь>/var/lib/clickhouse/access/
    

  

  
    
        <путь>/etc/clickhouse-server/users.XML
    
    <реплицировано>
        /clickhouse/access/
    

  

  
    <сервер>мой_ldap_сервер
        <роли>