ECP и API управления процессами. InterSystems Meetup Sankt-Peterburg 2014
0 likes522 views
Документ описывает функции и ограничения протокола ECP (Enterprise Cache Protocol) и API управления процессами, разработанные Алексеем Масловым. Основное внимание уделяется распределённому кэшированию, управлению данными и процессами в сетевой среде с использованием уникальных дескрипторов процессов. Приведены примеры кода и обсуждаются перспективы развития API для улучшения взаимодействия между серверами.
ECP и API управления процессами. InterSystems Meetup Sankt-Peterburg 2014
- 1. ECP и API управления процессами Алексей Маслов, СП.АРМ
- 2. Терминология ECP • ECP – протокол распределённого кэширования. • Собственность InterSystems • Серверы приложений: обращаются к данным. • Серверы данных: хранят данные. ^a=4 Код: write ^a set ^b Сервер приложе- ний (клиент ECP) Запрашивает и изменяет данные ^b=8 Сервер данных Хранит данные Сервер данных Хранит данные
- 3. Горизонтальное масштабирование : плюсы • Распределение значительной вычислительной мощности по десяткам недорогих серверов. • 1 сервер с 128 ядрами или 8 серверов по 16 ядер CPU? • Распределённый кэш базы данных. • 1 сервер с 1 TB RAM или 8 серверов по 128 GB RAM? • Распределённая обработка данных. • Промежуточные данные не покидают серверов приложений (БД CACHETEMP локальны)
- 4. ECP: достоинства для программиста • При переносе программы в сетевую среду синтаксис операций с данными не меняется. • Иллюзия локальности базы данных. • Синхронные операции ($GET(), $ORDER(), …) не ждут завершения асинхронных операций (SET, KILL), инициированных тем же сервером приложений. • Короткие операции (LOCK, LOCK Release, Block Purge,…) объединяются в один TCP-пакет. • Эффективное использование сети
- 5. ECP: ограничения • Длинные строки (>~ ½ размера блока) не кэшируются на серверах приложений. • Для 8 KB-блоков: > 3992 B • Синхронные операции (LOCK, $INCREMENT, …) дороги: они всегда передаются на сервер данных. • Команда LOCK ждёт завершения записи данных, начатой предыдущим хозяином блокировки. • Истечение таймаута LOCK не гарантирует, что блокировкой владеет кто-то другой. • Обработка ошибок <NETWORK> • Правильно: откатить транзакцию и начать заново
- 6. ECP: прикладные проблемы • Номера процессов не уникальны в сети • $JOB • Нет доступа к таблице процессов другого сервера • ^$JOB, $zjob(), … • Нет доступа к свойствам процессов другого сервера • Class %SYS.ProcessQuery • Нет управления процессами другого сервера • Class SYS.Process
- 7. Util.Proc API: ответ на прикладные проблемы ECP • Дескрипторы процессов, уникальные в сети. • Общесетевая таблица процессов. • Доступ к свойствам процессов другого сервера. • Управление процессами другого сервера.
- 8. Дескрипторы процессов, уникальные в сети • Уникальность адреса в локальной сети. • Использование с минимальными преобразованиями. • Легко читаемый формат. Дескриптор как децимальный номер: xx.yy.zz.uu.Port.PID, где xx.yy.zz.uu – IPv4 адрес сервера Caché, Port – tcp-порт суперсервера Caché, PID – номер процесса на сервере Caché. • e.g.: "192.168.10.119.1972.9724"
- 9. Общесетевая таблица процессов • Глобал в централизованной БД • Индекс – дескриптор процесса • ^zzzzzzJob("proc","127.0.0.1.56774.12632") • Данные – основные свойства процесса • $LB("IVANOV","tdv","192.168.1.2","QTEST","READ","qARM.exe“, • Обновление таблицы – не чаще, чем 1 раз в 10 секунд • Снижение нагрузки на сеть • Доступ только через API: • Set proc = ##class(Util.Proc).NextProc("") Set Nsp = ##class(Util.Proc).GetProcProp(proc)
- 10. Доступ к свойствам процессов другого сервера • Доступ к свойствам процесса: • ##class(Util.Proc).GetProcProp("192.168.10.119.1972.9724", "NameSpace") • Доступ к переменным процесса: • ##class(Util.Proc).GetProcVar("192.168.10.119.1972.9724", $name(qARM("User")))
- 11. Управление процессами другого сервера • Полномочия администратора! • Удалить процесс на другом сервере: • ##class(Util.Proc).KillProc("192.168.10.119.1972.9724") • Обновляет общесетевую таблицу процессов.
- 12. Пример кода: удаление всех процессов, кроме текущего set (proc,res)="", curNS=$NAMESPACE for { set proc = ##class(Util.Proc).NextProc (proc) quit:proc="" if '$$$PROCISMY(proc) && (curNS = ##class(Util.Proc).GetProcProp(proc, "NameSpace") ) { set res= ##class(Util.Proc).KillProc(proc) } }
- 13. Немного о реализации • Выбор способа взаимодействия с процессами на других серверах: Сlass %SYSTEM.Event • Официально не работает в сети. Cобственный TCP-сервер • Необходим дополнительный TCP-порт (кроме 1972). • Дополнительные усилия по настройке. Web-сервисы Class %Net.RemoteConnection • Работает через порт супер-сервера (умолчание – 1972). • Не требует дополнительных настроек.
- 14. Немного о реализации (2) • Что считать сетевой работой? 1. Основная БД области является удалённой • Справедливо только на сервере приложений (СП). • Исключает работу на сервере данных (СБД). 2. СБД: 1 + {Не смонтировал ли кто-то нашу БД как удалённую?} • Дорого. • Ненадёжно из-за динамичной природы ECP. 3. СБД: 1 + {Не выполнил ли кто-то проверку 1 на СП?} • Нет: работаем с локальными адресами: 127.0.0.1.Port.PID • Да: переходим на сетевые адресацию: 192.168.1.1.Port.PID
- 15. Нужно ли универсальное макро-API? // Cписок процессов во всех областях set proc = "" for { set proc = $$$ZJOB(proc) quit:proc="" write proc, ?30 // дескриптор процесса write $$$ZU(67,6,proc), ! // область (namespace) }
- 16. Перспективы развития реализации Util.Proc • Опрос серверов приложений идёт медленно, если их много. => Параллельные запросы к серверам. => Возможно, пересмотр способа взаимодействия в пользу собственного протокола обмена сообщениями.