Сначала я ознакомился с коммерческими решениями и рассмотрел, в частности, компанию Synology, которая, как предполагалось, предоставляет лучшие NAS-системы потребительского уровня на рынке. Однако стоимость этого сервиса оказалась достаточно высока.
Замечу, что Synology (а точнее Disk Station Manager ) это операционная система сделанная на базе Linux. Авторы, согласно GNU GPL — ее исходники периодически выкладывают в опенсурс.
С-нно существует проект построенный на базе этих исходников — XPEnology. Его можно поставить практически на любую железку и из коробки, с удобным интерфейсом задействовать большинство фичей (Time Machine — в том числе).
Отличный разбор про tcp bitflip, спасибо.
Для меня было новостью, что FCS чексумма в Ethernet — не особо то и помогает, если фрейм бьется на коммутаторе.
Верно я понимаю, что ipv4 в этом плане, за счет чексуммы ( ipv4 header checksum ), более защищен чем ipv6? И при переходе всех на последний — ожидается что количество подобных сбоев увеличится значительно, в ближайшие годы?
Шифрование данных тоже же должно помочь, чтобы такого не происходило (https)?
Это вопрос еще. Если вы собираете venv на серверах с одной ОС а используете на других, с другим окружением — вы огребаете)
В пакете то вы, хотя бы, фиксируете наличие определенного окружения, через зависимости.
Другой разговор — если говорить про venv в контексте докероподобного образа (ну или, может, вы чрут захотите использовать). Но тогда и окружение вам при деплое все нужно будет собирать, а не только venv.
Иными словами, venv должен как то быть привязан к версии ОС.
Вы исходите из ложной в данном случае предпослыки что код написанный выше надо улучшить усложняя.
В данном случае — вы не правы.
Я, правда, знаю про logging. Я также знаю что код не идеален. Но, предположим, что код рассчитан на школьников и студентов, вообще не имеющих представления об веб разработке.
Предложите, пожалуйста, вариант без включения дополнительных модулей. Предложите упрощение кода без усложнения?
Ну первая часть — она про знакомство с технологиями, вообще и в принципе.
Но спасибо за идею.
Может быть в следующих частях статьи я изображу какой-нибудь авторизующий декоратор на методы.
В принципе — ничто не мешает проставить пару кук в сервисе, поднять oauth, разместить сервис за nginx с basic http authorization/auth_request через какой-нибудь скрипт в xinetd.
Ну да, почему бы и нет.
Можно использовать docker, virtualenv, катить бинари каким-нибудь chef'ом.
Но, позволю себе заметить, что правильная настройка всего этого — тема для отдельной статьи.
Deb пакеты — это инфраструктура с минимальными трудозатратами из коробки.
Именно то, что нужно для маленького, наколеночного сервиса.
Потому что на production сервере не должно стоять dev-пакетов.
Иными словами, нужно стремиться к тому чтобы все файлы на сервере обладали принадлежностью к каким-либо пакетам.
Неорганизованный pip/pear/gem приводит к бардаку в системе и поломкам в самых неожиданных местах.
1. Хм. On-fail=standby? Когда я пробовал, — он работал совсем не так, как надо. Не помню правда что именно было не так. И предсказывать веса, то есть планировать работу кластера по весам — толком не получается. В итоге веса мы стали менять правилом которое смотрело на параметр для самодельного ocf ресурса.
Вообще, конечно, тут скорее важен подход — ваш кластер предоставляет определенный сервис. И именно предоставление этого сервиса надо мониторить, лучше всего тем же паттерном (или максимально приближенным к нему) который используют пользователи этого сервиса. Для примера — если у вас там http сервер то нужно тягать страничку с кластерного ip адреса и проверять не изменился ли ее md5 хеш, например.
Проверкой по shutdown — в данном контексте, это когда проверка работоспособности ресурсов кластера напрямую не производится, а считается, что ресурс всегда доступен — пока нода жива. Нода умерла — значит ресурс не доступен.
К слову, в двухнодовой конфигурации так же хорошо бы настроить stonith. А лучше сделать третью ноду (в комментариях к предыдущей статье об этом писали), можно только с арбитром и кворумом — по всем канонам так бцдет верно.
2. Смотрите, гипотетически, у вас отваливается DRBD на одной из нод.
Во-первых, вполне возможно что вся pacemaker нода не уйдет в ребут по kernel panic сразу.
Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?
DRBD добавили таки в ядро? Ну надо же. Клёво.
3. Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала? Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?
Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.
1.Это что же, отвал кластера фиксируется только если нода становится недоступной?
Вы тесты проводили какие нибудь, типа kill -9 *drbd*?
Нода то может жить, но не быть функциональной.
В таких системах нужно делать проверку которая изменяет веса на основании — получилось записать что-то в хранилище или нет. Не получилось — правим вес, перетягиваем мастера на другую ноду.
А у вас — вроде и ресурсы заведены, а проверка по шатдауну. Это как-то совсем круто.
2. Были сбои/тесты с такой системой кроме выключения питания одной из нод?
А переброс ip шника с ноды на ноду не заставляет ESXi вылетать по какому-нибудь таймауту? Там, насколько я помню большой довольно таймаут (в сравнении, конечно) прежде чем нода решает перетянуть на себя ресурсы если другая нода недоступна.
Замечу, что Synology (а точнее Disk Station Manager ) это операционная система сделанная на базе Linux. Авторы, согласно GNU GPL — ее исходники периодически выкладывают в опенсурс.
С-нно существует проект построенный на базе этих исходников — XPEnology. Его можно поставить практически на любую железку и из коробки, с удобным интерфейсом задействовать большинство фичей (Time Machine — в том числе).
Для меня было новостью, что FCS чексумма в Ethernet — не особо то и помогает, если фрейм бьется на коммутаторе.
Верно я понимаю, что ipv4 в этом плане, за счет чексуммы ( ipv4 header checksum ), более защищен чем ipv6? И при переходе всех на последний — ожидается что количество подобных сбоев увеличится значительно, в ближайшие годы?
Шифрование данных тоже же должно помочь, чтобы такого не происходило (https)?
В пакете то вы, хотя бы, фиксируете наличие определенного окружения, через зависимости.
Другой разговор — если говорить про venv в контексте докероподобного образа (ну или, может, вы чрут захотите использовать). Но тогда и окружение вам при деплое все нужно будет собирать, а не только venv.
Иными словами, venv должен как то быть привязан к версии ОС.
Это существенное усложнение?
Я думал поговорить про это во второй части.
Вы все говорите правильно, и предлагаете правильный код, спасибо.
Надеюсь что тот, кто доберётся до вашего комментария возмёт его на вооружение.
В данном случае — вы не правы.
Я, правда, знаю про logging. Я также знаю что код не идеален. Но, предположим, что код рассчитан на школьников и студентов, вообще не имеющих представления об веб разработке.
Предложите, пожалуйста, вариант без включения дополнительных модулей. Предложите упрощение кода без усложнения?
Но спасибо за идею.
Может быть в следующих частях статьи я изображу какой-нибудь авторизующий декоратор на методы.
В принципе — ничто не мешает проставить пару кук в сервисе, поднять oauth, разместить сервис за nginx с basic http authorization/auth_request через какой-нибудь скрипт в xinetd.
Кажется сейчас очередной виток её развития.
Можно использовать docker, virtualenv, катить бинари каким-нибудь chef'ом.
Но, позволю себе заметить, что правильная настройка всего этого — тема для отдельной статьи.
Deb пакеты — это инфраструктура с минимальными трудозатратами из коробки.
Именно то, что нужно для маленького, наколеночного сервиса.
Иными словами, нужно стремиться к тому чтобы все файлы на сервере обладали принадлежностью к каким-либо пакетам.
Неорганизованный pip/pear/gem приводит к бардаку в системе и поломкам в самых неожиданных местах.
Его и ставить не нужно.
Есть же sysstat — достаточно только включить в /etc/default
В конце концов, если очень хочется достаточно:
while true; sleep 1; do top -b | head -n2 >> ~/top.log; donewatch -n1 tail 1000 ~/top.logНо ставить дополнительное приложение на сервер для того чтобы красиво посмотреть вывод команды top?
Это простите, за гранью.
маленькаянаргрузка? Вы шутите.Вообще, конечно, тут скорее важен подход — ваш кластер предоставляет определенный сервис. И именно предоставление этого сервиса надо мониторить, лучше всего тем же паттерном (или максимально приближенным к нему) который используют пользователи этого сервиса. Для примера — если у вас там http сервер то нужно тягать страничку с кластерного ip адреса и проверять не изменился ли ее md5 хеш, например.
Проверкой по shutdown — в данном контексте, это когда проверка работоспособности ресурсов кластера напрямую не производится, а считается, что ресурс всегда доступен — пока нода жива. Нода умерла — значит ресурс не доступен.
К слову, в двухнодовой конфигурации так же хорошо бы настроить stonith. А лучше сделать третью ноду (в комментариях к предыдущей статье об этом писали), можно только с арбитром и кворумом — по всем канонам так бцдет верно.
2. Смотрите, гипотетически, у вас отваливается DRBD на одной из нод.
Во-первых, вполне возможно что вся pacemaker нода не уйдет в ребут по kernel panic сразу.
Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?
DRBD добавили таки в ядро? Ну надо же. Клёво.
3. Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала? Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?
Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.
Вообще статья, супер, конечно, спасибо.
Вы тесты проводили какие нибудь, типа kill -9 *drbd*?
Нода то может жить, но не быть функциональной.
В таких системах нужно делать проверку которая изменяет веса на основании — получилось записать что-то в хранилище или нет. Не получилось — правим вес, перетягиваем мастера на другую ноду.
А у вас — вроде и ресурсы заведены, а проверка по шатдауну. Это как-то совсем круто.
2. Были сбои/тесты с такой системой кроме выключения питания одной из нод?
А переброс ip шника с ноды на ноду не заставляет ESXi вылетать по какому-нибудь таймауту? Там, насколько я помню большой довольно таймаут (в сравнении, конечно) прежде чем нода решает перетянуть на себя ресурсы если другая нода недоступна.
И вообще — системного администратора на них нет!
:)