• Сетевики (не) нужны
    0

    И да full view и не один держит не напрягаясь frr на рядовом железе, проблема в data plane и его задержках при использовании ядра linux, а не в control plane.
    Есть подвижки с DPDK и eBPF+XDP но они пока не могут быть применены достаточно широко т.к. это инструменты для разработки, а не готовое решение конкретных задач.

  • Сетевики (не) нужны
    0

    Нет TNSR пощупать не получилось, но щупал ванильный fd.io на самосборе с интеловвми картами — он показал line rate на маршрутизации без NAT и фильтров между 2 10G. TNSR построен на fd.io с рядом оптимизаций так что на базе опыта с fd.io я склонен доверять заявленным показателям.

  • Сетевики (не) нужны
    0

    Cumulus это про коммутаторы пока что, full view он там не переварит.
    10G на line rate это проблема если PPS большой, пока его пережёвывает только fd.io поверх DPDK и продукты построенные на нём, например https://www.tnsr.com/


    А вот MX и аналоги спокойно справляются.
    Стоковое ядро с тюненным sysctl живёт до первого DDoS на 10mpps потом становится весело.

  • Сетевики (не) нужны
    0

    Пока нет, возможно позже.
    С самим кумулусом проблем не сильно много, у нас больше проблем с обвязкой управления сетью которая досталась в наследство.


    Разница с вендорами — нужно детально понимать как работают все компоненты, что-бы всё было стабильно, впрочем как и с любыми комплексными OSS решениями из мира linux.

  • Сетевики (не) нужны
    0

    Какие решения посоветуете?
    Именно в разрезе замены MX?


    Софт роутер это хорошо, но при скоростях 10G+ становится грустно даже с NAT и просто маршрутизацией уже на средних PPS.

  • Сетевики (не) нужны
    0

    Не тут вопрос был в разрезе именно DPDK.


    Просто что вы описали я и так знаю — у меня сеть в ДЦ на white box коммутаторах и Cumulus.


    FRR так же активно используем.

  • Сетевики (не) нужны
    +1

    Про DPDK и MX разверните пожалуйста.
    Если это про fd.io то он IMHO пока больше Фреймворк для создания своего ПО чем продукт который можно в бой пускать.


    Если что-то иное — поделитесь пожалуйста тема интересна.

  • И снова о Legacy. Вечная боль техдира
    0

    Вам никто не мешает использовать bind mount и не использовать volumes.
    Но да в таком раскладе могут быть нюансы.

  • И снова о Legacy. Вечная боль техдира
    0
    Ну так в том то и вопрос, что стоимость поддержки докера в нашем случае оказалась выше. Не вижу как это может влиять на bus factor.


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

    Это упрощение. Факторов больше чем размер команды, но это конечно один из них.


    Основные факторы это:
    1. Сложность проекта
    2. Размер команды
    3. Необходимое значение Time to market


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

    Причём чем быстрее нужно вносить изменения, тем нужнее системы CI/CD, а в большой инфраструктуре сложного проекта docker сильно облегчает процессы тестирования и деплоя, особенно когда серверов не 2 и не 10.

    Ну а чем докер принципиально отличается от bash скрипта, Dockerfile это по сути и есть плюс минус bash-скрипт.

    Он принципиально отличается от bash, ansible и т.п. тем, что у вас нет предыдущего состояния (точнее оно всегда известно — это состояние образа с которого вы начинаете), поэтому он исключает класс проблем вида «для установки этой библиотеки для этой зависимости, мне сначала нужно откатить предыдущее», а так же ситуации, когда в среде исполнения приложения кто-то из администраторов и разработчиков что-то поправил руками, но не задокументировал и не вписал в тот же ansible.

    Другими словами с docker у вас всегда конфигурация системы начинается с чистого листа.

    Я не противник докера. Более того я его использую для тестирования bash-скриптов. (Хотя могу и без докера, через vagrant). Но я против бездумного пихания докера и микросервисов в каждый проект.


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

    В разрезе python / django это может быть установка пакетов, требующих компиляции нативных расширений, когда у вас 50 серверов это становится болезненно и долго — проще один раз собрать docker image, посте чего скачать его на все сервера и запустить тем же ansible.

    При использовании ansible без docker он очень быстро разрастается и сложность его понимания и входа для нового DevOps/SRE становится существенной.

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

    Я выше написал, что изначально докер был в проекте. Так что это не про нашу ситуацию.


    Не исключаю, что для вашего проекта эта технология не нужна, а волосы людей, ответственных за поддержку проекта со стороны инфраструктуры вместе с теми, кто отвечает за деплой, мягкие и шелковистые.
    Но всё это может быть не так в иных ситуациях.
  • И снова о Legacy. Вечная боль техдира
    0
    Да это есть, но не сильно отличается от настройки того-же apache/nginx, делается это один раз и работает потом долго.

    Доступ к docker socket в RO, это всё-таки не рут права (RW — можно так назвать).

    Бонусом докера является возможность не доставлять те же модули php на конечные машины, это не боль при условии, что у вас один сервер и свежий проект, а когда их несколько и проект требует старый php, которых нет в свежих дистрибутивах, или состав этих модулей периодически меняется.
    В таком случае вы получаете сильное упрощение в Operations с не не очень существенным усложнением в Dev.

    Кроме того очень простым становится откат и обновление.

    А если выйти за рамки php там вообще начинается дивный новый мир.
  • И снова о Legacy. Вечная боль техдира
    +2
    Может, вопрос в bus-factor данного решения и стоимости поддержки.

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

    IMHO сложность использования docker несколько преувеличена.
    На моём опыте, большая часть его противников или не хотят изучать технологию, или не хотят ничего менять в своей работе — им и так хорошо и всё устраивает, в том числе много ручных операций и портянки скриптов и/или YAML, т.к. это делает их незаменимыми.

    К сожалению аргументированный отказ от docker на основе именно его технических минусов — очень редкое явление, в основном аргументация на уровне «я слышал/читал что это плохо», без личного опыта и понимания технологии.
  • И снова о Legacy. Вечная боль техдира
    +1
    А как всё это повторить для 5 разных веток на 1 сервере?
  • Nokia N95, лучший смартфон старой школы
    +4
    А ещё в N95 есть встроенный SIP клиент, который очень вывозил в своё время когда внедрял IP телефонию.
  • Когда Linux conntrack вам больше не товарищ
    0
    Там то же механизм ядра для него используется
  • Пошаговое руководство по настройке DNS-сервера BIND в chroot среде для Red Hat (RHEL / CentOS) 7
    0
    А не проще в docker с network=host запустить?
  • Как переехать с ESXi на KVM/LXD и не сойти с ума
    0

    Посмотрите на Opennebula, возможно она вам подойдёт

  • Принимаем электронную почту на Node.js
    0
    Для отправки вы такой же самописный сервис используете, который сам ищет почтовые сервера в целевых доменах, общается с ними по smtp и управляет очередью повторов и т.п.?
    Я к тому, что прикрутить imap к существующему postfix/exim надежнее и дешевле.
    Как вариант, можно ещё просто складывать почту существующим почтовым сервером в mailbox/maildir форматах и просто разбирать файлы.

    В таком раскладе не нужно реализовывать проверки spf, dkim и т.п. и в дальнейшем поддерживать этот код, решать проблемы безопасности.

    Да, отбойники большинство сервисов шлют или в формате https://tools.ietf.org/html/rfc3464 или используя заголовки X-Failed-Recipients
  • Принимаем электронную почту на Node.js
    0
    Не проще ли было просто читать ящик через imap — в таком варианте нет зависимости от работоспособности models сервиса.
  • Релиз YouTrack 7.0: новая концепция Agile доски, диаграмма Ганта и многое другое
    +3
    Хорошо бы добавить в вашу систему web hooks — это откроет большие возможности по интеграции с другими системами.
  • Gitlab-CI
    0
    Мы у себя рассматривали gitlab-ci как альтернативу jenkins для сборки .net проекта. На текущий момент как ci он нормально работает, но есть пару моментов:
    — нельзя задать какое количество сборок, для которых нужно хранить артефакты, только время их хранения.
    — сам файл конфигурации хранится в репозитории как результат сложно сделать схему, когда deploy должен быть предварительно одобрен (или в ручную запущен) ограниченным количеством ответственных лиц. Это можно попробовать сделать при помощи protected branch, но никто не мешает разработчику изменить файл в своём бранче и залить что угодно на прод.
    В результате как cd его пока использовать сложно.

    Если есть у кого-нибудь опыт использования в реалиях, которые я описал, прошу поделиться своим опытом.
  • VMware Virtual SAN 6.2: технологическое будущее
    0
    Видимо имеется ввиду, что теперь можно совмещать гипервизор с системой хранения на одном хосте.
  • VMware Virtual SAN 6.2: технологическое будущее
    0
    Ceph доехал до VMware ;-)
  • Строим свое собственное отказоустойчивое облако на базе OpenNebula с Ceph, MariaDB Galera Cluster и OpenvSwitch
    +1
    Мы используем CEPH как block-storage, Gluster насколько я знаю это именно FileSystem, соответственно тут они не конкуренты.
    Основными причинами, почему мы начали использовать Ceph были:
    1. Quorum-based система выбора мастера, то есть при 2n+1 нодах split-brain мы не получаем.
    2. Самолечение при сбое ( то есть если произошёл отказ ceph сам создаст умершие копии / выведет — введёт osd в кластер и всё само нормализуется через некоторое время)
    3. Достаточно детальная документация и адекватная производительность (при условии следования документации — 2 разные сети, одна для виртуалок, вторая под ceph)

    ИМХО: кластерная система хранения должна сама отрабатывать сбои, а не требовать вмешательства администратора, всё что я читал про Gluster говорит о том, что он так не умеет.
  • Станет ли OpenStack «новым LAMP»?
    +3
    Не могли бы вы развёрнуто рассказать, почему OpenNebula не является конкурентом для OpenStack?
  • Чем заменить Cisco? Импортозамещение коммутаторов доступа
    0
    Расскажите как на CRS125 STP на всех портах сделать.
    У меня получилось только если свитч переводить в решим роутера с бриджём, после чего ожидаемо упала производительность.
  • Интерактивный C#
    0
    Посвежей: scriptcs.net
    Кстати судя по #r именно он и используется для repl в студии
  • От ASP.Net к Node.JS: как мы переписали серверную часть редакторов ONLYOFFICE
    0
    В моём проекте мы держим порядка 20к на 4-ядерном xeon + HT, 8GB ram, ASP.Net MVC + Signalr
  • От ASP.Net к Node.JS: как мы переписали серверную часть редакторов ONLYOFFICE
    0
    github.com/aspnet/Home/issues/1093 проблема с OSX и Linux
    По поводу красношапки — она вообще в RC1 не поддерживается, о чём написано в информации по релизу
  • От ASP.Net к Node.JS: как мы переписали серверную часть редакторов ONLYOFFICE
    –1
    Ага и mvc в нём под Linux не работает
  • Готовим ASP.NET 5: Continuous Deployment с Docker и Tutum
    +1
    >IIS у меня так и не заработал, если кто знает решение-буду рад.
    github.com/aspnet/Announcements/issues/69
  • Строим свое собственное отказоустойчивое облако на базе OpenNebula с Ceph, MariaDB Galera Cluster и OpenvSwitch
    0
    В случае если нужен shared datastore, можно поднять Metadata Server и использовать для этого Ceph FS.


    1. CephFS не production-ready
    2. При падении основного Metadata сервера, все клиенты, которые работают с ней встают в deadlock на уровне ядра, после этого помогает только перезагрузка, что не есть хорошо
  • Строим свое собственное отказоустойчивое облако на базе OpenNebula с Ceph, MariaDB Galera Cluster и OpenvSwitch
    +3
    У нас подобная схема не заработала стабильно ибо:
    1. Как БД использовали Precona Cluster (master-master) и он не стартовал сам в случае одновременного отключения всех нод и их последующего запуска (отказ по питанию в стойке)
    2. У вас в схеме нет shared system datastore / shared file datastore — соответственно не получится загружать файлы ядер или скрипты контекстуализации. Мы делали его сначала на NFS, потом на SAMBA и он перемещался между нодами вместе с OpenNebula тут тоже возникли проблемы из-за невозможности размонтировать rbd т.к. он используется.
    3. Проблемы с обновлением OpenNebula т.к. нужно обновлять все ноды.

    В итоге пришли к простой схеме:
    1. Всё хранится в CEPH
    2. OpenNebula + MySQL для неё работают на виртуалке, которая тоже хранится в CEPH
    3. На нодах лежит файл для virsh, с описанием виртуалки OpenNebula
    4. corosync занимается только тем, что запускает виртуалку с OpenNebula в virsh на одной из нод и следит, чтобы она всегда работала

    Как бонус — меньше кластеризованных сервисов — меньше коллизий.
  • Почтовый сервер на собственном сайте через sendmail
    0
    Я знаю про maildir, и dovecot'товские форматы, а также не использую формат mailbox практически нигде (где остался — требования стороннего ПО).
    В данном случае я показывал, что как минимум бонус в том чтобы иметь отдельный ящик на каждую учётку, а не общую помойку на всех.
  • Почтовый сервер на собственном сайте через sendmail
    +1
    вам exim + dovecot не просто так посоветовали, в этой связке (да и по отдельность) можно хранить данные про учётки (а также сопутствующую информацию) в БД. На выходе получаем возможность заводить учётку при регистрации пользователя на сайте без необходимости менять конфигурацию почтовика, а так же разложенную по учёткам почту (для каждой учётки — свой файл).

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


    Вот тут то и кроются проблемы, если поток почты будет достаточно большой, то ваш файл «для всех» будет быстро распухать, а дальше — либо будет требоваться большое количество RAM для быстрого разбора файла, либо получаем тормоза при чтении почты.
  • Динамические очереди звонков в Asterisk
    0
    А почему не воспользовались asterisk realtime? Я года 4 назад таким образом управлял очередями через самописную веб админку и не пришлось городить кучу выборок на ael
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Нам нужны мессенджеры. Ещё больше мессенджеров
    +2
    Чем sip поверх lte плох? Там и голос и передача коротких сообщений и видео, плюс он достаточно хорошо стандартизирован. Номера могут быть в формате user@domain.
    Для распределённой адресации по номеру уже сейчас есть такая вещь как ru.wikipedia.org/wiki/ENUM

    А то про h323 написали, а про sip забыли…
  • Правильное увеличение размера диска в виртуальной машине
    +2
    Можно в первом варианте не использовать сервисную машину, а подключить диск к хосту через qemu-nbd
  • Первые шаги к онлайн-офису на Linux или как мы портировали под Mono (о сложностях и их преодолении)
    0
    Но на этапе нагрузочного тестирования SignalR-сервер падал с исключением System.IO.IOException: «Too many open files» — примерно после тысячи подключений клиентов.


    Почитайте про ulimit — проблема возможно решится без правки SignalR