Комментарии 2
В связи с развитием современных распределенных систем на базе docker, в которых заранее предполагается возможность выхода из строя программных компонентов на различных уровнях: контейнер, сервер, стойка, датацентр, существует ли необходимость учитывать и проектировать с такой тщательностью аппаратную инфраструктуру? Ведь для правильной работы такой системы достаточно обеспечить безотказную работу и возможность восстановления аппаратуры на время синхронизации параллельно работающих распределенных систем, что сейчас может обеспечить самый обычный простой сервер на базе самой обычной линукс платформы на kvm. Не будет ли дешевле предусмотреть возможность самовосстановления системы на массивах простых серверов, чем гоняться за девятками после зяпятой?
Я бы разбил этот вопрос на два.
Если говорить вообще о синхронизации параллельно работающих простых серверов, то это вполне правомерный ход, и можно действовать именно таким образом. Но shared nothing отказоустойчивый кластер, на мой взгляд, просто сложнее корректно настроить, чем shared disk.
Что касается Docker, то он сам по себе не является средством обеспечения высокой готовности, хотя может быть использован совместно с такими средствами (как, например, описывается в статье HA-Cluster на основе Pacemaker под контейнерную виртуализацию LXC и Docker).
Если вы абстрагируетесь от контроля работы нижних уровней, и станете их рассматривать как просто доступные и недоступные для использования ресурсы, то таким образом потеряете целый класс ситуаций, когда они вроде бы работают, но как-то сбойно.
Если говорить вообще о синхронизации параллельно работающих простых серверов, то это вполне правомерный ход, и можно действовать именно таким образом. Но shared nothing отказоустойчивый кластер, на мой взгляд, просто сложнее корректно настроить, чем shared disk.
Что касается Docker, то он сам по себе не является средством обеспечения высокой готовности, хотя может быть использован совместно с такими средствами (как, например, описывается в статье HA-Cluster на основе Pacemaker под контейнерную виртуализацию LXC и Docker).
Если вы абстрагируетесь от контроля работы нижних уровней, и станете их рассматривать как просто доступные и недоступные для использования ресурсы, то таким образом потеряете целый класс ситуаций, когда они вроде бы работают, но как-то сбойно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
К вопросу реализации персистентных процессов в управляющих системах реального времени (часть 3)