about NetApp

В практике каждого системного интегратора случаются проекты далекие от идеального “проекта мечты”, часто на пути к реализации “идеальный проект” обрастает правками, как днище корабля ракушками, настолько, что к реализации приходит уже совсем иная система, нежели та, что изначально планировалась. К сожалению, далеко не всегда эти изменения идут проекту на пользу. Давайте рассмотрим наиболее частые случаи.

«Перелет» – система «навырост».

Достаточно распространенный случай несбалансированной системы это покупка системы «навырост», под дальнюю перспективу, неоправданную на сегодняшний день, либо с переоценкой потребностей. Немалую роль в этом играют и сами системные интеграторы, которые всегда рады «исполнить любой каприз заказчика за его деньги», и, разумеется, поощряющие его на такие дорогостоящие капризы. Чаще всего они пользуются как неадекватной оценкой потребностей клиента (например, отсутствием или неверно выполненным анализом необходимой производительности информационной системы, частью которой становится система хранения, завышением требований), либо путаницей, зачастую преднамеренной, созданной многочисленными маркетинговыми обещаниями.

«Мы не хотим покупать систему с 2GB FC портами, ведь уже есть 4GB порты, а они вдвое быстрее!».
«Нам нужна система хранения с самыми быстрыми дисками, на 15K. Ведь когда у нас стояли в сервере два диска SCSI на 10K, все было очень медленно».
«Мы хотим библиотеку на дисках BluRay, потому что это самая новейшая технология. Библиотеки на магнитных лентах давно устарели!»

В защиту такого поведения системных интеграторов следует сказать, что зачастую процесс апгрейда имеющейся системы хранения для оборудования большинства вендоров-создателей систем хранения зачастую сопряжен с серьезными временными и денежными затратами (приятным исключением являются системы Network Appliance). Затраты настолько велики, что зачастую выгоднее становится, при малейшем подозрении на перспективы значительного роста (и зачастую невозможности провести адекватный «сайзинг»), потратить сегодня больше, с тем чтобы отодвинуть время необходимости смены системы хранения как можно дальше в будущее, а в идеале передать этот хлопотный и мучительный процесс следующему IT-менеджеру ;)

«Недолет» – всюду жмет.

Часто приходится сталкиваться и с обратным случаем. В особенности такое происходит в случае «предельно бюджетного» варианта. Недооценка в данном случае также вредна, как и переоценка. Покупка системы, не обеспечивающей решение запланированных задач является, как правило, бессмысленной тратой денег, безрезультатным расходом бюджета IT-отдела, который вместо этого можно было бы пустить на цели, могущие дать в этом случае реальный прирост производительности IT-системы. Ведь, как правило, «узкое место» бывает не одно. Приобретение такой системы бывает следствием мнений:

«Давайте купим самую дешевую систему, ведь главное, чтобы на нее поместилась наша база данных!»
«Может быть просто купить 6 дисков SATA для нашего сервера, и этого будет достаточно?»
«Мне выделили 3 тысячи долларов на покупку системы хранения, надо купить что-нибудь крутое за эти деньги. Например терабайта на два-три».

Результатом может быть лишь разочарование.
Впрочем даже не выполняющая свои задачи система хранения увеличивает общую капитализацию компании, и бонусы как продавца, так и покупателя, что в ряде случаев также может оказаться полезным ;)

Несбалансированная система – «перекосы».

Обычно это частный случай рассмотренного выше, сочетание первого и второго, когда в системе что-то одно «жмет», а что-то другое «навырост».

4GB FC ports и диски SATA
Диски 15Krpm на системе для резервного копирования данных.
Восьмипроцессорный сервер под 1С:Предприятием 7.7

При несбалансированности решения вполне можно потратить бездну денег и получить 5% прирост производительности. Хороший пример – недорогая система хранения начального уровня, наполненная дисками 15K. По сравнению с дисками 10K цена вырастает минимум на треть, однако вовсе не факт, что на недорогой системе хранения производительность вырастет в полтора раза, как это могло бы быть на более мощной системе с большим кэшем и более мощным процессором обработки. Просто возникает эффект «бутылочного горлышка»: как ни дави, сколько ни трать денег, все равно больше, чем просочится через самое узкое место, из системы не выжать. Происходит эффект мотора от Феррари на Жигулях. Много дыму, рева, расхода высококачественного бензина, однако реальная скорость передвижения практически не увеличилась.

В отличие от выше рассмотренных вариантов, где решение зачастую диктуется самим клиентом (или его финансами), в рассматриваемом случае, без сомнения, вина за продажу несбалансированной системы прежде всего ложится на системного интегратора

«Недодумали» или «переоценили».

Достаточно часто встречаются в жизни даже не столько «системные» перекосы, такие как рассмотренные выше, а мелкие, локальные, но имеющие не менее губительные последствия. Наиболее часто встречается несовместимость проданного оборудования и программного обеспечения или разного оборудования между собой.
В случае «многовендорного» интеграционного проекта, с множеством участников со стороны производителей оборудования и ПО, «матрица совместимости» проекта может расти в геометрической прогрессии. Учесть всю возможную специфику взаимодействия программных и аппаратных компонентов, взаимодействующих «каждый с каждым», бывает достаточно непросто.
В рассмотренном случае вина за проблемы ложится целиком на системного интегратора.
Однако зачастую проект начинает перекраиваться по требованию заказчика. Во множестве случаев у интегратора не оказывается достаточно «рычагов» и сил, чтобы воспрепятстсвовать такому вмешательству “специалистов, которые платят деньги и заказывают музыку”.

Пример из жизни
Крупный химический завод хочет создать отказоустойчивую систему управления производством, использующую базу данных Oracle. Для этого создается кластер на базе Veritas Cluster Server из двух серверов SUN, приобретается common storage EMC CLARiiON CX, к которому по FC подключаются два сервера SUN Fire V. Казалось бы, все хорошо: в случае выхода из строя одного из серверов, с помощью служб VCS задача системы управления производством, представляющая собой БД Oracle и написанные вокруг нее приложения, рестартует на резервном сервере. Однако в какой-то момент из спецификации «в целях экономии IT-бюджета» вычеркивается Veritas Storage Foundation с журналируемой файловой системой VxFS для Solaris. ?? все устанавливается на обычный UFS.

?? теперь в случае выхода из строя первичного сервера, резервный запускается, монтирует на себя common storage на EMC CLARiiON, и… запускает fschk.
На 20 минут.

«“Немного недодумали” чаще всего означает, что не думали вообще».