Предыстория: наша компания размещает приложения SaaS DSS, в которых клиенты предоставляют нам данные ежедневно и / или еженедельно, которые мы обрабатываем и объединяем в их существующую базу данных. В рабочее время нагрузка на серверы довольно минимальна, поскольку в основном это пользователи, выполняющие простые предварительно определенные запросы через веб-сайт или запускающие сквозные отчеты, которые в основном попадают в куб SSAS OLAP.
Я руковожу группой ИТ-операций, и до сих пор это представляло для нас интересную проблему «масштабирования». Для наших ежедневно обновляемых клиентов сервер «занят» только около 4-6 часов ночью. Для наших клиентов с еженедельным обновлением сервер "занят" только 8-10 часов в неделю!
Мы сделали все возможное, чтобы использовать несколько простых методов распределения нагрузки, равномерно распределяя ежедневных клиентов между серверами, так что мы не пытаемся обрабатывать ежедневных клиентов один за другим в течение ночи. Но в долгосрочной перспективе эта стратегия масштабирования создает две заметные проблемы. Во-первых, он будет потреблять огромное количество оборудования, которое простаивает в течение длительных периодов времени. Во-вторых, требуются значительные затраты на производственную поддержку, чтобы в основном «запланировать» ETL, чтобы они не перекрывали друг друга, и перемещать клиентов / расписания, если они превышают ресурсы на конкретном сервере или выделенном временном интервале.
Как следует из названия, один из вариантов, который мы пробовали, - это запуск нескольких пакетов SSIS параллельно, но в большинстве случаев это давало ОЧЕНЬ противоречивые результаты. Наиболее частые сбои - это DTExec, SQL и SSAS, борющиеся за физическую память и вызывающие ошибки нехватки памяти, а также ETL, работающие в 3,4,5 раза дольше, чем ожидалось. Итак, исходя из моего практического опыта, похоже, что запуск нескольких пакетов ETL на одном и том же оборудовании - не лучшая идея, но я не могу быть первым человеком, который не хочет масштабировать несколько пакетов ETL вокруг ручного планирования и последовательного обработка.
Один из вариантов, который мы рассмотрели, - это виртуализация серверов, которая, очевидно, не дает вам никаких дополнительных ресурсов, но переносит конкуренцию за ресурсы на гипервизор, который (по моему опыту), похоже, управляет одновременным вводом-выводом ЦП / ОЗУ / диска. немного более изящно, чем позволить DTExec, SQL и SSAS бороться с этим в Windows.
Вопрос к форуму: Мой вопрос к форуму: не упускаем ли мы здесь чего-то очевидного? Существуют ли инструменты, которые могут помочь управлять запуском нескольких пакетов SSIS на одном оборудовании? Было бы более «эффективным» с точки зрения параллельного выполнения, если бы вместо запуска DTExec, SQL и SSAS на одном и том же компьютере (с каждой машиной, выполняющей эту конфигурацию), мы работали бы парами из трех машин с SSIS, работающим на одной машине, SQL на другой , а SSAS на третью? Очевидно, это имело бы смысл только в том случае, если бы мы могли обрабатывать более трех ETL, которые мы могли обрабатывать на машине независимо.
Другой вариант, который мы рассмотрели, - это полностью изменить архитектуру нашего пакета SSIS, чтобы иметь один «главный» пакет для всех клиентов, который пытается разумно выбрать сервер в зависимости от того, насколько он уже «занят» с точки зрения использования ЦП / памяти / диска, но это было бы титаническим усилием, и похоже, что мы пытаемся заново изобрести что-то, что, как вы думаете, кто-то продаст (хотя мне не повезло найти это).
Итак, вкратце, не хватает ли нам очевидного решения для этого, и знает ли кто-нибудь, есть ли какие-либо инструменты (бесплатные или платные, не имеют значения), которые облегчают запуск нескольких пакетов SSIS ETL параллельно и на нескольких серверах? (То, что я бы назвал системой «на основе очереди и узла», но это не официальный термин). В конечном итоге планировщик распределенных ресурсов VMWare решает эту проблему, поскольку вы просто запускаете постоянное количество клиентов на каждую виртуальную машину, что, как вы знаете, никогда не будет конфликтовать с планированием, а затем оставляете VMWare перемещать виртуальные машины, чтобы сбалансировать использование оборудования. Я определенно не против использования VMWare для этого, но, поскольку мы на 100% являемся стеком приложений Microsoft, кажется, что кто-то решил бы эту проблему на уровне приложения, а не на уровне гипервизора, проверив ресурс. использование на уровнях ОС, SQL, SSAS.
Я открыт для ЛЮБОЙ дискуссии по этому поводу и помню, что ни одно предложение не является слишком сумасшедшим или радикальным! :-) На данный момент VMWare - единственный вариант, который мы нашли, чтобы уйти от «ручной» балансировки наших ресурсов, поэтому любые предложения, которые оставляют нас на чистом стеке Microsoft, были бы замечательными.
Спасибо, парни,
попробуй это: http://blogs.msdn.com/b/sqlperf/archive/2011/05/25/the-balanced-data-distributor-for-ssis.aspx
вы также можете вырастить решение с помощью Service Broker (или другой очереди сообщений)
и пакеты слушателя, которые ждут работы, и дипатч для рабочих пакетов в ферме ящиков с установленными SSIS.