ЦОД. Часть1

Вначале, то есть лет эдак 12 назад, существовало, так называемое правило 80/20. Точнее не само правило, а его известная интерпретация для сетевого трафика, которая гласила, что 80 процентов трафика не покидает пределов рабочей группы, а остальные 20 процентов обрабатываются общекорпоративными серверами.

Такой подход выглядел логичным. По крайней мере, с точки зрения производительности сети. Однако на практике очень скоро был обнаружен и подводный камень, о который данная модель и разбилась. Дело в том, что за серверы рабочей группы отвечали администраторы, естественно, этой же рабочей группы, а забота об общекорпоративных серверах возлагалась на администраторов предприятия. Вот тут-то и всплыла проблема, даже целых две.

Во-первых для того чтобы серверы рабочей группы могли функционировать именно как серверы рабочей группы, администраторы должны были сформировать среду их функционирования, которая подразумевала среди прочего порядок доступа к ним членов своей рабочей группы, то есть правила их аутентификации и авторизации, правила групповой и/или индивидуальной политики обслуживания трафика, включая VLAN, ACL, QoS. Администраторы и определяли эти параметры, естественно, без оглядки на администраторов других рабочих групп, равно как и на администраторов предприятия в целом. Проблемы не замедлили себя ждать – согласование нескольких учетных записей – групповых и корпоративных – пользователей, согласование IP-адресов для пользователей рабочих групп, наконец, согласования параметров групповых и общекорпоративных политик обслуживания осуществлялись с большими трудностями. И если это получалось, то общекорпоративная сеть действительно вела себя как единая система. Однако, согласование параметров среды функционирования – рабочих групп и общекорпоративных – было делом весьма хлопотным, и пройти этот путь до конца удавалось редко. Одним словом, для всех проще было этого вообще не делать. И тогда, общекорпоративная сеть представляла собой или набор плохо согласованных между собой сетей рабочих групп, или одну сеть, в которой любой пользователь мог получить доступ к любому ресурсу без каких-либо ограничений.

Но, как я упоминал, была и вторая проблема, суть которой могла бы быть сформулирована вопросом: а где найти такое количество более или менее подготовленных администраторов рабочих групп, которые владели бы вопросами сопровождения как серверов с установленными на них приложениями, так и сетей? Таких администраторов и сейчас, вообще говоря, совсем немного, а в те времена их было ещё меньше.

Мне представляется, что именно эти две причины вкупе и явились тем фактором, который обусловил фазовый скачок в организации сетевых служб и приложений – как оказалось, консолидация, или централизация серверов и соответствующих приложений, предлагала гораздо более заманчивые перспективы. Другими словами, правило 80/20 было заменено правилом 20/80. По моему мнению, если быть точным, то это новое правило следовало бы сформулировать 0/100, то есть весь сетевой трафик приобретал вертикальный характер – от рабочих станций к серверам, которые были собраны в, так называемой, серверной ферме – прообразе нынешнего ЦОД.

Довольно логично события развивались и дальше. Консолидация серверов создала те условия, в которых виртуализация физических серверов не могла не появиться. Виртуализация серверов повлекла за собой необходимость управления созданием, активацией, выделением ресурсов, изменением статуса виртуальных серверов, то есть внедрения процедур автоматизации администрирования виртуальных сред. А это, в свою очередь, в сильной степени упростило или, лучше сказать, обусловило возможность осуществления миграции виртуальных серверов – виртуальных машин (VM) – с одного физического сервера на другой, пока в пределах одного ЦОД.

Далее…. А вот здесь на некоторое время пока остановимся. О других последствиях консолидации и виртуализации серверов и поговорим во 2-ой части.