1. Производительность и
отказоустойчивость в больших
проектах
Сергей Кудинов, InterSystems
Владивосток, 2015

2. • Как предотвратить ошибки в ПО
– [Unit]Test
– Continuous integration
– Agile
– Alpha/Beta/RC
– …
• Как предотвратить проблемы с
производительностью
– Перестать считать это
проблемой?..

3. Нельзя управлять тем,
что нельзя измерить!
3

4. • Первый шаг для контроля
производительности приложения
• Отражает объем работы и скорость
работы приложения
– Время открытия окна приложения
– Время составления отчетов
– № транзакций в минуту/ секунду
Метрики приложения

5. Системные факторы ограничения
производительности
CPU
Ввод/Вывод
(Передача данных
от/к CPU)

6. Системные факторы ограничения
производительности
CPU
Ввод/Вывод
- Дисковая система
- Сеть
Память

7. Системные метрики
CPU
Ввод/Вывод
- Дисковая система
- Сеть
Память
Загрузка CPU Задержки /
очереди
Доступно памяти

8. Метрики Caché
CPU
DB I/O
CACHE.DAT, WIJ,
Journals
Память
Не DB I/O
(файлы, сеть)
Routine Commands
Метрики приложения
Global References

9. Ключевые метрики Cachè
• GloRef
– Одиночное обращение к глобалу (get, set, kill)
– Зависит от I/O (файлы DB и память)
• Routine Commands
– Выполнение одиночной команды COS
– Зависит от загрузки CPU
• Время выполнения
– Осязаемая оценка производительности
GloRef
Routine
Commands
Время
выполнения

10. Epic Systems
• Выручка в 2014 году $1.8 млрд.
• 7000 сотрудников
• В США ЭМК 173 млн. пациентов (54%)
• В мире ЭМК 182 млн. пациентов
• Крупнейший клиент Kaiser Permanente (50 000)
• 2014 год – 31 новый клиент (8 не США)
• Ежегодный семинар Epic 10 300 участников из 326
организаций
• Из аттестованных по Stage 7 используют Epic
(http://www.epic.com/recognition-stage7.php):
– 69% госпиталей
– 91% амбулаторий

11. • Собственный TCP/IP протокол
• Прикладной разработчик модуля приложения
ОБЯЗАН написать код для генератора (Caché
Сервер)
• Прикладные программисты могут использовать
только высокоуровневое API
Генератор Нагрузки

12. • Постоянный мониторинг всех клиентов
– Метрики
• Сервер
• Caché
• Приложение
• Citrix
• Превентивное вмешательство
– При отклонении метрик от нормы – расследовать и
устранять проблему до того как она стала очевидна
пользователям!

13. Upgrade до 2015.1 !!!
• Наиболее значимые улучшения
– Более быстрая компиляция
– Более быстрая работа с локальными переменными
– Управление размером памяти процесса
– XML
– Async I/O
– Параллельный SQL
– Значительное улучшение производительности на
многоядерных системах

14. Заветные 24x7
а также «пять девяток» и прочие изыски маркетологов
Когда вам говорят о доступности «пять девяток», уточните: после которой из них стоит точка.
Народная мудрость
Девятки и проценты Время «простоя системы» в год
99% 87 часов 40 минут
99.5% 43 часа 50 минут
99.9% 8 часов 46 минут
99.95% 4 часа 23 минут
99.995% 26 минут 18 секунд
99.999% 5 минут 16 секунд
99.9999% 31,6 секунды

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

16. Отказоустойчивость
Microsoft Windows Server Clusters
HP ServiceGuard
IBM PowerHA SystemMirror
Veritas Cluster Server
Red Hat Enterprise Linux HA
Кластеризация

17. Отказоустойчивость
Виртуализация

18. Зеркалирование
Primary Backup
ECP / Clients

19. Зеркалирование
Primary Backup
ECP / Clients
Журналы

20. Зеркалирование
Primary Backup
ECP / Clients

21. Зеркалирование
Primary Backup
ECP / Clients

22. Зеркалирование
Асинхронные узлы (катастрофоустойчивость)

23. Зеркалирование
Асинхронные узлы (отчетность)

24. • Быстрое, автоматическое и безопасное переключение при
возникновении сбоя системы
• Время переключения - секунды
• Полное резервирование компонентов; нет разделяемых
элементов
• Уменьшает время простоя при обновлении версий и замене
аппаратных компонентов
Для отказоустойчивости…
Почему зеркалирование?

25. • Поддержка нескольких географически разделенных ЦОД
• Простота переключения на резервный ЦОД без потери данных
• Простота обратного переключения на основной ЦОД
• Сравнение с дисковыми репликациями…
– Меньшая стоимость
– Нет ограничений на трубуемую задержку
– Минимизация трафика между резервными серверами
Для катастрофоустойчивости…
Почему зеркалирование?

26. Простая зеркальная пара
Failover
MembersA B
Mirror
Virtual IP
Data Center Private LAN for Mirror
Communication (optional)
Mirror
Arbiter
Campus LAN / WAN Accessible to Users and
Other Systems

27. Добавляем DR и Reporting Async
Failover
Members
Reporting
Async
DR
Async
A B C D
Mirror
Virtual IP
Campus LAN / WAN Accessible to Users and Other Systems
Data Center Private LAN for Mirror Communication
(optional)
Mirror
Arbiter

28. Зеркалирование только для DR и отчетности
Failover
Member
Reportig
Async
DR
Async
A C D
Campus LAN / WAN Accessible to Users and Other
Systems
Data Center Private LAN for Mirror Communication
(optional)

29. Полностью дублируемое зеркало
Failover
Members
DR
Async
DR
Async
Data Center 1
A KJB
Mirror
Virtual IP
Internet
DMZ DMZ
Data Center 2
Reserved
VIP
Mirror
Arbiter
the Entire OrganizationLANs & WAN Accessible to

30. Вопросы?
Спасибо за внимание!

31. Спасибо!
Сергей Кудинов
sergey.kudinov@intersystems.com