Какие типы серверных ролей вы не можете запустить в кластере Linux (или другой OSOS)?
Я думал о том, чтобы попробовать какое-нибудь бесплатное программное обеспечение кластера. IIUC две основные вещи, для которых мы используем серверы, Apache и PostgreSQL, могут быть настроены для избыточной работы в кластерах с помощью модулей балансировки нагрузки и репликации Slony-I. Совместное использование файлов может быть, возможно, немного легче.
Какие типично важные сервисы вы не сможете разместить в кластере (т. Е. Вы более или менее застряли бы с хостингом на одной, мощной машине?)
1 ответ
Люди действительно креативны, и вы не поверите, чтобы кластеры работали и были надежными.
Когда дело доходит до кластеризации (или, по крайней мере, HA-кластеризации), существуют кластеры с общим хранилищем и кластеры без общего доступа. Кластеры общего хранилища обычно используют кластерные файловые системы в централизованном массиве, таком как SAN. Они используют OCFS, GFS или что-то подобное.
Службы, работающие на них, иногда являются активными / активными, где обе машины полностью способны предоставлять клиентам полный спектр услуг и обычно используют балансировку нагрузки в взвешенном или циклическом стиле, но также могут быть настроены как активные / пассивные, где "Предпочитаемый" компьютер действует как сервер до тех пор, пока не выйдет из строя, в этом случае другой член кластера вступает во владение.
Кластеры без общего доступа обычно являются активными / пассивными, поскольку для активации пассивного члена необходимо было изменить состояние. Это меняется с появлением таких вещей, как DRBD, который использует репликацию файловой системы на уровне блоков по сети.
Между одним из этих двух методов почти все службы, о которых я могу подумать, могут быть реплицированы на массив серверов, особенно если вам неважно, куда вы помещаете свои файлы состояния. Даже NFS может быть реплицирована без зависания клиентов, если на все, включая файлы блокировки, ссылаются из централизованного хранилища.
Корпоративные вычисления в целом были сосредоточены на том, что время безотказной работы одной машины не так важно, как доступность услуг. С этой целью службы были спроектированы таким образом, что отказ одной машины не означает сбои для пользователей.