Организация нескольких физических серверов при наличии одной лицензии QV Server

Автор savenyaav, 23 мая 2016, 04:25:55

« назад - далее »

savenyaav

Всем, привет.
Изложу проблему, может кто-то сталкивался и сможет подсказать варианты её решения.

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

Что уже имеется: еще один физический сервер, на который можно перенести часть приложений со всеми цепочками загрузок. К счастью разделить приложения на 2 части можно, модули загрузки и обработки данных у этих частей пересекаться не будут.

Но покупать еще одну лицензию QV Server желания у компании пока нет. Вот здесь и хотелось бы получить консультацию. Как организовать кластер? По сути 2 физических сервера, на мощностях которых будут крутиться приложения расположенные конкретно на них, но чтобы планировалось все и доступ к приложениям осуществлялся с одного QV Server.

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

p/s/ сервер в компании не Publisher.


Marina

Добрый день!
Вопрос хороший, для некоторых актуально. Но вендор, Qlik, тут все продумал - кластер нельзя организовать на одной лицензии QlikView Server. Нужно обязательно приобрести вторую лицензию QlikView Server, и только после этого разворачивать кластер.
К сожалению, обойти это лицензионные правила тут не удастся :(

Pavel Krasnopolsky

Добрый день!
Создать именно кластер, не имея соответствующей лицензии, не получится.
Если вопрос в том, можно ли разнести сами приложения на различные сервера (просто физически их переместить), то ответ - можно (просто указываете в qmc путь к этим приложениям, создаете папку).
Но вы должны понимать, что в таком случае все вычисления все равно будут производиться на сервере с QlikView Server, поэтому толку от этого не будет, наоборот, может стать только хуже

Иван

Привет!  :)

Могу предложить следующую схему:
1. Сервер с конечными приложениями QlikView (бизнес-приложения) - на котором не происходит никакой загрузки данных из внешних систем и никаких предрасчетов. Здесь запускаются только приложения пользователей QlikView.
2. Куча серверов для расчетов - на них ставится QlikView Personal Edition. НО: ни в коем случае нельзя код обработки данных располагать в приложениях, а делается это так. Код пишется в файлы, которые инклудятся одним файлом, а этот один файл инклудится в QlikView приложение. С помощью батников запускается с центрального QlikView сервера параллельный расчет остальных приложений на других серверах, а данные заливаются в расшаренную папку на центральном серваке.

Тыдым, профит: 1 лицензия на сервер, масштабирование производительности по предрасчетам, страхование себя от поломки предрасчетов (т.к. все скрипты в текстовых файлах).

admin

Привет.
Иван, сомнительная экономия получится.
Посчитай сколько надо будет развернуть станций именно для этих целей.
Кто это будет администрировать и сколько времени это будет занимать.
Плюс надо понимать какой объем крутится хотя бы за сутки. И т.д. и т.п.

А пока, можно  провести оптимизацию.

Иван

Женя, привет!  :)

Под "кучей" я подразумеваю разумное множество серверов) Вообще, достаточно освободить основной сервер приложений и ввести в строй 1 сервер "предрасчетов". А потом на отдельном сервере производить оптимизацию.
Это может быть и кластер, который позволит масштабировать производительность предрасчетов (когда будет достигнут потолок в оптимизации).
Просто, когда пользователи запускают приложения - часть памяти отъедается и для предрасчетов (если они производятся в QlikView) оперативки не хватает.

Оптимизировать можно еще конечные модели данных, чтобы оперативки меньше елось. Вообщем фантазии безграничны :)

Иван


savenyaav

Всем, привет! Спасибо за такую активную помощь)

Я вероятно не до конца конкретизировал задачу. На данный момент проблема не в производительности сервера во время выполнения загрузки и обновления данных. Возможно со временем она и возникнет, и вариант Ивана тогда я попробую применить в продуктиве. Загрузки сейчас происходят ночью и пока успевают к началу рабочего дня. Проблема в производительности наступает днем, когда пользователи начинают активно анализировать данные в приложениях. И хотелось бы разделив приложения на 2 части иметь доступ к ним с одного QV Server, но чтобы приложения эти, во время работы с ними пользователей, напрягали только сервер на котором они физически расположены. Но я так понимаю, без второй лицензии это невозможно?

admin

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

Иван

Цитата: admin от 25 мая  2016, 09:47:43  
Привет,
Скорее да, один сервер - одна лицензия.
Проанализируйте источник нагрузки в приложениях, возможно удастся снизить нагрузку если уменьшить количество рассчетов через оптимизацию модели данных.

+1

Так связать сервера невозможно.
Варианты:
1. Оптимизация приложений:
1.1. Оптимизация модели данных;
1.2. Оптимизация количества визуальных элементов на листе (когда их много они дольше рассчитываются и требуют больше ресурсов) - можно условие расчета сформировать, если скрыты некоторые элементы визуализации;
1.3. Оптимизация расчетов при визуализации (возможно часть расчетов имеет смысл перенести в загрузку данных в ночь);
2. Сегментирование данных по пользователям/отделам/подразделениям:
Имею ввиду, если пользователи из разных подразделений работают с одним большим приложением где расположено все все все, то имеет смысл разбить 1 модель на несколько моделей, определив предварительно цели каждого отдела и сделав самостоятельные модели для каждого отдела на основе тех или иных требований.

Советы по модели могу дать здесь на форуме, если пришлете модель данных (плюс другие добавят). Либо в личку, либо на почту ivan.shamaev@gmail.com

Яндекс.Метрика