Назад | Перейти на главную страницу

Как [вежливо?] Сказать поставщику программного обеспечения, что он не знает, о чем он говорит

Не технический вопрос, но тем не менее действительный. Сценарий:

HP ProLiant DL380 Gen 8 с двумя 8-ядерными процессорами Xeon E5-2667 и 256 ГБ оперативной памяти под управлением ESXi 5.5. Восемь виртуальных машин для системы данного поставщика. Четыре виртуальные машины для тестирования, четыре виртуальные машины для производства. Четыре сервера в каждой среде выполняют разные функции, например: веб-сервер, главный сервер приложений, сервер БД OLAP и сервер БД SQL.

Доли ЦП настроены так, чтобы тестовая среда не влияла на производственную среду. Все хранилище по SAN.

У нас было несколько вопросов относительно производительности, и поставщик настаивает на том, что нам нужно предоставить производственной системе больше памяти и виртуальных ЦП. Тем не менее, мы можем ясно видеть из vCenter, что существующие распределения не затрагиваются, например: ежемесячный обзор использования ЦП на главном сервере приложений колеблется в районе 8% с нечетным скачком до 30%. Всплески обычно совпадают с запуском программного обеспечения резервного копирования.

Аналогичная история с оперативной памятью - самый высокий показатель использования серверов составляет ~ 35%.

Итак, мы немного покопались, используя Process Monitor (Microsoft SysInternals) и Wireshark, и наша рекомендация поставщику состоит в том, чтобы они в первую очередь настроили TNS. Впрочем, дело не в этом.

У меня вопрос: как заставить их признать, что статистика VMware, которую мы им отправили, является достаточным доказательством того, что больше RAM / vCPU не поможет?

--- ОБНОВЛЕНИЕ 12.07.2014 ---

Интересная неделя. Наше ИТ-руководство заявило, что мы должны внести изменения в распределение виртуальных машин, и теперь мы ждем простоя от бизнес-пользователей. Как ни странно, именно бизнес-пользователи говорят, что некоторые аспекты приложения работают медленно (по сравнению с тем, что я не знаю), но они собираются «сообщить нам», когда мы сможем отключить систему (ворчание , ворчать!).

Кроме того, «медленный» аспект системы, по-видимому, не является элементом HTTP (S), то есть «тонким приложением», используемым большинство пользователей. Похоже, что установка «толстого клиента», используемая основными финансовыми службами, явно «медленная». Это означает, что теперь мы рассматриваем в наших исследованиях клиента и взаимодействие клиент-сервер.

Поскольку первоначальная цель вопроса заключалась в том, чтобы попросить помощи относительно того, следует ли пойти по пути "проткни это" или просто внести изменение, и сейчас мы вносим изменение, я закрою его, используя длинная шеяответ.

Спасибо всем за ваш вклад; как обычно, serverfault был больше, чем просто форум - это тоже что-то вроде кушетки психолога :-)

Я предлагаю вам внести необходимые изменения. Затем проверьте производительность, чтобы показать им, что это не имеет значения. Вы можете даже пойти так далеко, чтобы протестировать его с МЕНЬШЕЕ памяти и vCPU, чтобы подтвердить свою точку зрения.

Кроме того, «Мы платим вам за поддержку программного обеспечения с помощью реальных решений, а не догадок».

Если вы уверены, что находитесь в рамках заданных системных спецификаций, которые они документируют.

Затем любые заявления, которые они делают в отношении необходимости большего объема ОЗУ или ЦП, должны иметь возможность для резервного копирования. Как эксперт в своей системе я призываю людей к ответу по этому поводу.

Спросите их подробности.

  • Какая информация, представленная в системе, указывает на то, что требуется больше ОЗУ, и как вы это интерпретировали?

  • Какая информация, представленная в системе, указывает на то, что требуется больше ЦП, и как вы это интерпретировали?

  • Данные, которые у меня есть, на первый взгляд, противоречат тому, что вы мне рассказываете. Вы можете мне объяснить, почему я могу это неправильно интерпретировать?

  • Я интерпретирую этот [очевидный ряд данных] как [очевидную интерпретацию]. Можете ли вы подтвердить, что я правильно интерпретирую это в отношении моей проблемы?

Имея дело с поддержкой в ​​прошлом, я задавал те же вопросы. Иногда я был прав, и они неправильно фокусировали свое внимание на моей проблеме. Однако в других случаях я был неправильно и я неправильно интерпретировал данные или не включал другие данные, которые были важны для моего анализа.

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

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

Важно иметь возможность доказать, что вы используете передовые методы распределения ресурсов системы, в частности, резервирование ОЗУ и ЦП для вашего SQL-сервера.

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

Для этого конкретный ситуации (когда у вас есть VMware и разработчики приложений или третье лицо, которое не понимает распределения ресурсов), я использую метрики, полученные за неделю vCenter Operations Manager (vCops - при необходимости скачать демо), чтобы точно определить реальные ограничения, узкие места и требования к размеру виртуальных машин приложения.

Иногда мне удавалось удовлетворить более упорных потребителей, изменив резервирование виртуальных машин или изменив приоритеты для обработки сценариев конкуренции; "Если RAM | CPU тесны, ВАШ ВМ будет иметь приоритет!". Плохие-плохие вещи случились, когда Я позволил поставщикам программного обеспечения диктовать свои требования к моим кластерам vSphere без реального анализа..

Но в целом цифры и данные должны побеждать.


Пример того, что я использовал, чтобы обосновать размер виртуальной машины для разработчика приложения Tomcat:

Dev: ВМ нужен ЦП MOAR!

меня: Что ж, память - ваше самое большое ограничение, и вот тепловая карта вашей производительности в зависимости от времени ... Среда в 18:00 - самые напряженные периоды, поэтому мы можем уточнить этот пиковый период. О, и вот рекомендация по размеру, основанная на производственных показателях за последние 6 недель ...