есть положительный опыт на centos6 и соответственно drbd8+heartbeat+openvz6. Минус этого решения — при переключении роли с одного сервера на другой виртуалки «как бы перезагружаются», то есть HA есть, а FT нет (в терминалогии vmware) и большие накладные расходы (не в смысле производительности серверов, а в том смысле, что у меня 2 независимых кластера по 2 машины в каждом, то есть 2 сервера в работе и 2 в резерве. А хотелось бы конечно «два в работе, и один в резерве»). За те 3-4 года, что это работает пару раз происходило «нештатное» переключение (первый раз память начала сбоить, второй раз материнка) и все отработало нормально (правда загрузка 40 контейнеров разом — не самое простое испытание для дисковой подсистемы, процессор до половины времени в iowait проводил первые несколько минут после переключения).
Eдинственный вариант, которым у меня удалось поломать drbd и потребовалось руками чинить — это потеря связанности между хостами при нормальной работе обоих хостов (ha переводит drbd в UP и получаем split brain). Поэтому в работе оба узла связаны по 2 каналам, один через свич, он же для клиентского трафика, второй канал напрямую между сетевыми картами серверов.
проблемы «генерировать валидный сертификат на лету» нет, есть есть доступ сертификату удостоверяющего центра которому вы (ваше ПО) доверяет. Есть проблема «не палится генерируя левые сертификаты», ибо есть certificate-transparency.org и DNS CAA (они конечно пока только набирают обороты, но со временем надеюсь будут полностью решать проблему «плохие парни получили корневой сертификат и генерят что хотят»)
ну как минимум я вижу что сертификаты 4pda вам прилетают правильные (точно такие же как и мне), а потом от сервер не получает от вас подтверждения получения пакетов (то есть ACKки вы ему отправляете, а он вам в большом количестве Retransmissions присылает (то есть постоянно повторяет одни и те же данные, как будто ваши ACKки до него не доходят)). Скорей всего тут не вмешательство в https, а некая ошибка в конфигурировании сети от вас до сервера и скорей всего она непреднамеренная (ну либо с целью «выгнать пользователей к конкурентам»). То, что на одной симке проблема наблюдается, а на другой нет скорей всего объясняется тем, что разные симки ходят через разные NAT\Bras\etc (не знаю как мобильные операторы строят свои сети в общем случае и как билайн в частности).
Варианта развития как мне кажется 2: либо проблему заметят и исправят без вашего дальнейшего участия (по системе мониторинга, по куче однотипных заявок, по этому топику в конце концов), либо придется общаться с саппортом, но не по телефону, а текстом, прикладывать дампы трафика и призывать инженеров в тикет
Строчки будут появляться на экране по мере записи в файл. Не очень удобно, тем что они «перемешиваются», но в один лог падает много, а в другой мало (например access и error логи, в error очень редко что-то попадает), то вполне приемлемо.
У меня вопрос\уточнение по формату статьи: мне всегда казалось что правильный формат использования selinux это:
1) Выключаем selinux
2) Настраиваем сервис
3) Пишем документ с названием 'Политика ...'
4) Настраиваем selinux на основании п.3
5) Включаем новые политики на тестовом сервере
6) На основании п. 5 редактируем п. 3 и п. 4
7) Повторяем п. 6 до получения нужного результата
Причем мне всегда казалось что логично поручить п. 2, 3 и 4-7 разным людям что бы они могли "родить истину в споре".
Что думаете о подобном подходе к проблеме?
> В Windows у меня над этим контроля нет (на сколько я знаю). Где я не прав?
Есть, просто он спрятан от рядового пользователя (современные версии ОС я вижу очень редко, но мне кажется этот момент там не сильно изменился)
бизнесу не нужно «работает и ладно», бизнесу нужно «что бы работало не хуже чем у конкурентов, а если даже лучше, то вообще замечательно», но почти все конкурируют друг с другом почему то на линуксах, виндусах и иногда бздях, а план9, инферно и остальные не очень распространенные ОС занимают свою небольшую нишу и пока что не претендуют на «ОС общего назначения»
а если вы сделаете «apt install php7.0-fpm; apt install apache2»? первая команда видит что апача нет и конфиг дня него не кладет, вторая команда ставит апач, а конфига для php7-fpm нет, тут нужно либо усложнять пакетный менеджер «списками кросс-зависимостей файлов» и после установки апача вызывать что-то типа «перераскладывания примеров конфигов для php7-fpm и всех остальных, у кого могли быть примеры конфигов для апача» при этом попутно решая что делать с «вручную исправленными конфигами». К тоже же кмк идеологически неверно при установке апача как-то реконфигурировать совершенно другой пакет. Да и к тому же не очень понятно чем вам мешает лишняя директория в /etc. Все таки это не так критично влияет на производительность, как замусоренный реестр в windos.
В домашней директории пользователей лежат не конфиги, а файлы пользователей. Да, это может быть какой-нить .softname/config, но это файл пользователя, который пользователь или явно написал сам, или натыкал в графическом меню программы softname(есть конечно вариант что он «автосгенерировался» при первом запуске). И пользователь может сделать что-то типа «apt remove softname && apt-add-repository… && apt update && apt install softname» и ожидает увидеть новую версию softname, поставленную из «правильного» ppa, но со своим старым конфигом (я например уже лет 10 таскаю ~/.purple/, ~/.mozilla/ и ~/.thunderbird/ по разным ноутбукам, дискам и ОСям).
И я считаю что трогать данные пользователя никогда не нужно. Пользователь может потом захотеть снова поставить тот же софт, может захотеть перенести конфиг на другую машину или просто сохранить конфиг в какой-нить git на всякий случай).
> Кому? Разработчикам Ceph, чтоб они у себя на сайте картинку поправили?
Я слабо представляю внутренне устройство ceph, но мне кажется что в данном споре лучше оперировать ссылками на строки в исходниках, чем картинками на сайте.
Я про KVM ничего не говорил, его действительно удобнее держать сверху, при необходимости подключение серверов из соседней стойки («кмк» это сокращение фразы «как мне кажется»).
2) usb2com стоит копейки и нужен только первые 2 минуты, потом обычного ethernet вполне хватает
3) Стойки у вас были заранее. Обжимать (а лучше покупать) патчи тоже можно было заранее в спокойной обстановке (или даже из старого ДЦ привести). Так же не понятно зачем зажимать кабеля в не разборные стяжки и почему они одной колбасой идут, а не уходят в право (в лево), а потом возвращаются на уровне свича.
Ps кмк свич практичнее ставить в середину стойки, а не сверхку(снизу). Так провода менее кучно к нему подходят. Если хотите — сделаю завтра пару фото как это в реале выглядит.
у меня крайне положительные впечатления от них остались, несмотря на то, что во время собеседования объявили учебную пожарную тревогу и часть вопросов пришлось обсуждать эвакуируясь из здания, правда на админа собеседовался.
Eдинственный вариант, которым у меня удалось поломать drbd и потребовалось руками чинить — это потеря связанности между хостами при нормальной работе обоих хостов (ha переводит drbd в UP и получаем split brain). Поэтому в работе оба узла связаны по 2 каналам, один через свич, он же для клиентского трафика, второй канал напрямую между сетевыми картами серверов.
Варианта развития как мне кажется 2: либо проблему заметят и исправят без вашего дальнейшего участия (по системе мониторинга, по куче однотипных заявок, по этому топику в конце концов), либо придется общаться с саппортом, но не по телефону, а текстом, прикладывать дампы трафика и призывать инженеров в тикет
Дамп то трафика из wireshark остался? Выложите куда-нить посмотреть
После вашей оплаты картой продавцы по несколько суток ждут пока они смогут этими деньгами распоряжаться, а тут всего полчаса и почти без процентов.
Покупая батон хлеба за 20 рублей тоже даёте тысячу и принципиально не берете сдачу?
Вполне можно сделать
Строчки будут появляться на экране по мере записи в файл. Не очень удобно, тем что они «перемешиваются», но в один лог падает много, а в другой мало (например access и error логи, в error очень редко что-то попадает), то вполне приемлемо.
У меня вопрос\уточнение по формату статьи: мне всегда казалось что правильный формат использования selinux это:
1) Выключаем selinux
2) Настраиваем сервис
3) Пишем документ с названием 'Политика ...'
4) Настраиваем selinux на основании п.3
5) Включаем новые политики на тестовом сервере
6) На основании п. 5 редактируем п. 3 и п. 4
7) Повторяем п. 6 до получения нужного результата
Причем мне всегда казалось что логично поручить п. 2, 3 и 4-7 разным людям что бы они могли "родить истину в споре".
Что думаете о подобном подходе к проблеме?
Есть, просто он спрятан от рядового пользователя (современные версии ОС я вижу очень редко, но мне кажется этот момент там не сильно изменился)
И я считаю что трогать данные пользователя никогда не нужно. Пользователь может потом захотеть снова поставить тот же софт, может захотеть перенести конфиг на другую машину или просто сохранить конфиг в какой-нить git на всякий случай).
Я слабо представляю внутренне устройство ceph, но мне кажется что в данном споре лучше оперировать ссылками на строки в исходниках, чем картинками на сайте.
Я про обычный свич: выглядит примерно так
3) Стойки у вас были заранее. Обжимать (а лучше покупать) патчи тоже можно было заранее в спокойной обстановке (или даже из старого ДЦ привести). Так же не понятно зачем зажимать кабеля в не разборные стяжки и почему они одной колбасой идут, а не уходят в право (в лево), а потом возвращаются на уровне свича.
Ps кмк свич практичнее ставить в середину стойки, а не сверхку(снизу). Так провода менее кучно к нему подходят. Если хотите — сделаю завтра пару фото как это в реале выглядит.