Pull to refresh

Comments 5

"Поскольку гиперконвергенция на 100% определяется программным обеспечением "-

вызывает лёгкое сомнение.

Спасибо за описание подхода, но как обеспечить безопасность при гиперконвергенции? так мне по сути на одном ЦОДе закрывать нужно было 1/2 дырки, а так решето какое-то получается ?

Ну странно было (нет) не отметить главную проблему HCI архитектуры - невозможность независимого масштабирования (или ограниченную возможность) вычислительных ресурсов и ресурсов хранения? Т.е. если у вас кончилось место, но с Compute все хорошо, то все равно надо добавлять целиком сервера (т.е. и Compute, и Storage). И наоборот. А это не эффективно.

И разные производители, по-разному эту проблему решают. Отсюда и Compute-only nodes, и Storage-nodes, и шаринг емкости между кластерами, и вообще растаскивание компонентов обратно (aka dHCI, хотя ИМХО это ужасный термин).

Это популярное сомнение, но в vStack решается не так:  в vStack если у вас кончилось место, но с Compute все хорошо можно добавлять только Storage. Более того: в vStack нет запрета на комбинирование горизонтального масштабирование и вертикального.

Вертикальное масштабирование — это здорово, но имеет несколько существенных недостатков в реальной жизни. 1.) Вертикально от масштабировать вы можете только диски (вариант выкинуть процессоры и заменить их на новые я не рассматриваю, ибо в реальности так никто не делает). А это значит, что если у вас кончился Compute, то хочешь не хочешь добавляй узлы. 2.) Это приводит к зоопарку, т.к. у вас получаются разные узлы на разных кластерах (ведь вам нужно разное отношение Storage/Compute под разные нагрузки). На больших объемах это сложно/дорого, и с точки зрения закупок, и с точки зрения эксплуатации. Даже в вашей документации: "Одно из выгодных для промышленной эксплуатации преимуществ гиперконвергенции – идентичность элементов инфраструктуры, а именно: узлов кластера. Это позволяет иметь "под рукой" ZIP-пакет в виде шасси, которым можно оперативно заменить вышедший из строя узел кластера vStack." 3.) На больших кластерах вертикальное масштабирование дает большой шаг роста, ибо диски вам стоит добавлять более-менее равномерно во все хосты в кластере. Плюс, если у вас два тира (SSD и HDD), то вам нужно наращивать не только Capacity, но и Cache, чтобы не уменьшать Cache/Capacity ratio 4.) Для действительно крупных заказчиков закупать отдельно диски просто организационно бывает сложно, ибо играется рамочный контракт на узлы целиком.

А про Storage Only узлы - можно ссылки на материалы по этому поводу? В документации, почему-то, ничего не могу найти.

Sign up to leave a comment.