Я думаю, что имелось в виду, что это костыль для управления слоями.
При правильно дизайне управление слоями было бы реализовано как-то по другому, например:
Основной источник это список пакетов в репозиториях ALT: packages.altlinux.org
Sisyphus — нестабильный репозиторий для разработки
p8 — текущий стабильный репо для выпуска дистрибутивов
c8 — текущий стабильный репо для дистрибутивов с сертификацией
Но всё равно какие-то неравноценные сведения в обзоре.
В ALT есть и QEMU, и libvirt, и VirtualBox.
Хотя в рамках этой статьи это мало что меняет, т.к. диагноз один, в реестре минкомсвязи есть только KVM для production-виртуализации.
Картинка неправильная. Республика Коми живет по Московскому времени.
Наверное есть и еще неточности.
Она вроде бы относится к проекту изменений в часовых поясах, который так и не был принят.
Да, вы правильно поняли проблему.
Только не из пушки по воробьям получится, для отдачи нескольких файлов разворачивать кластерную ФС? Лишний расход вычислительных ресурсов, снижение надежности и скорости доступа, расходы на администрирование.
Вариант 2. Копировать файлы приложения в оба контейнера (и в nginx и в php), мне как-то тоже не понравился из-за перерасхода дискового пространства.
В итоге я пришел к мысли, что запихать nginx в контейнер к приложению будет наименьшим злом.
А как вы решаете вопрос с доступам к файлам статики из контейнера с nginx?
Этот вопрос легко решается пока все находится на машине разработчика, просто монтируем папку с проектом в контейнеры с nginx и php как volume.
Сложность начинается тогда, когда это всё надо перенести с машины разработчика, скажем в Kubernetes. Поэтому я для себя пока остановился на решении с nginx и php в одном контейнере. Т. к. этот вариант показался меньшим злом, по сравнению с теми решениями, что пришли в голову.
Эта слегка необычная XP, внутри вполне себе XP, но она еще поддерживается, в отличие от «обычной» и поэтому для неё есть патч от этой уязвимости. Я думаю, что патча бы небыло, если бы не было самой уязвимости.
Ждем продолжения с тестами.
Мои тесты этой системы показали катастрофическое падание производительности при зеркалировании.
Без зеркалирования производительность не сильно отличалась от ожидаемой, в зависимости от железа.
После включения зеркалирования показатели снижались до неприемлемого уровня.
Но и тестовый стенд был собран из г-на и веток, поэтому на нормальном стенде может все и хорошо.
У меня узлы соединялись сетью 1 Гбит.
Машина может переехать на хост, если на нем есть свободные лицензии.
Да, лицензий нужно больше, чем у вас есть ВМ. На каждом хосте должны быть несколько дополнительных (запасных) лицензий, на случай если на него будет осуществляться переезд.
Но не надо каждую виртуалку лицензировать на все ядра, как написан в статье.
В документе есть картинка 4C с описанной мной ситуацией. А по вашему на каждый хост нужно по 6 лицензий.
На картинке 12 виртуалок, а лицензий на 16.
Логичнее было бы конечно на каждый сервер по 3 лицензии, тогда любой сервер можно безболезненно выключить.
Чем больше хостов в кластере, тем запасных лицензий нужно меньше.
Не надо на каждом сервере все ВМ лицензировать. На каждом сервере надо лицензировать максимальное количество ВМ, которое на нем может(должно) быть запущено.
Допустим, есть у нас 3 сервера и 12 одинаковых по ресурсам ВМ. В обычном режиме они распределены по 4 на сервер. Вышел один сервер из строя, его 4 ВМ переехали на два других, и сейчас на них по 6 ВМ.
Вот по 6 ВМ на сервер и надо лицензировать. Если предположить, что сдохнут 2 любых сервера и все ВМ как-то буду вкорячены (с уменьшением ресурсов) на оставшийся, то тогда да, надо на все сервера лицензировать 12 ВМ. Но ситуация притянута за уши.
При правильно дизайне управление слоями было бы реализовано как-то по другому, например:
LAYER 1
RUN…
RUN…
COPY…
LAYER 2
RUN…
RUN…
COPY…
sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
sync percentiles (usec):
| 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
| 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
| 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
| 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
| 99.99th=[15795]
Скорее всего вы используете версию fio меньше 3.5, в которой вообще не выводится нужная информация, о чем указано в статье.
Sisyphus — нестабильный репозиторий для разработки
p8 — текущий стабильный репо для выпуска дистрибутивов
c8 — текущий стабильный репо для дистрибутивов с сертификацией
В ALT есть и QEMU, и libvirt, и VirtualBox.
Хотя в рамках этой статьи это мало что меняет, т.к. диагноз один, в реестре минкомсвязи есть только KVM для production-виртуализации.
СПТ это старая версия, сертифицированная ФСТЭК, в реестре под номером 9
Новая версия — 8 СП, под номером 4305
В реестре минкомсвязи есть позиции со следующими номерами, относящиеся к ALT:
9 — reestr.digital.gov.ru/reestr/61248
1541 — reestr.digital.gov.ru/reestr/87620
1292 — reestr.digital.gov.ru/reestr/87364
1912 — reestr.digital.gov.ru/reestr/89517
4305 — reestr.digital.gov.ru/reestr/125868
Есть новее: www.basealt.ru/products/alt-8-sp-sertifikat-fstehk-rossii/alt-8-sp-server
Наверное есть и еще неточности.
Она вроде бы относится к проекту изменений в часовых поясах, который так и не был принят.
Только не из пушки по воробьям получится, для отдачи нескольких файлов разворачивать кластерную ФС? Лишний расход вычислительных ресурсов, снижение надежности и скорости доступа, расходы на администрирование.
Вариант 2. Копировать файлы приложения в оба контейнера (и в nginx и в php), мне как-то тоже не понравился из-за перерасхода дискового пространства.
В итоге я пришел к мысли, что запихать nginx в контейнер к приложению будет наименьшим злом.
Этот вопрос легко решается пока все находится на машине разработчика, просто монтируем папку с проектом в контейнеры с nginx и php как volume.
Сложность начинается тогда, когда это всё надо перенести с машины разработчика, скажем в Kubernetes. Поэтому я для себя пока остановился на решении с nginx и php в одном контейнере. Т. к. этот вариант показался меньшим злом, по сравнению с теми решениями, что пришли в голову.
Мои тесты этой системы показали катастрофическое падание производительности при зеркалировании.
Без зеркалирования производительность не сильно отличалась от ожидаемой, в зависимости от железа.
После включения зеркалирования показатели снижались до неприемлемого уровня.
Но и тестовый стенд был собран из г-на и веток, поэтому на нормальном стенде может все и хорошо.
У меня узлы соединялись сетью 1 Гбит.
Да, лицензий нужно больше, чем у вас есть ВМ. На каждом хосте должны быть несколько дополнительных (запасных) лицензий, на случай если на него будет осуществляться переезд.
Но не надо каждую виртуалку лицензировать на все ядра, как написан в статье.
В документе есть картинка 4C с описанной мной ситуацией. А по вашему на каждый хост нужно по 6 лицензий.
На картинке 12 виртуалок, а лицензий на 16.
Логичнее было бы конечно на каждый сервер по 3 лицензии, тогда любой сервер можно безболезненно выключить.
Чем больше хостов в кластере, тем запасных лицензий нужно меньше.
Допустим, есть у нас 3 сервера и 12 одинаковых по ресурсам ВМ. В обычном режиме они распределены по 4 на сервер. Вышел один сервер из строя, его 4 ВМ переехали на два других, и сейчас на них по 6 ВМ.
Вот по 6 ВМ на сервер и надо лицензировать. Если предположить, что сдохнут 2 любых сервера и все ВМ как-то буду вкорячены (с уменьшением ресурсов) на оставшийся, то тогда да, надо на все сервера лицензировать 12 ВМ. Но ситуация притянута за уши.