декабрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

показать все 

13.12.2024

Рынку индустриального ПО нужна стратегия развития Итоги III Конференции по матмоделированию

Читать далее 

07.12.2024

Avanpost FAM/MFA+ стали еще безопаснее: вышла обновленная версия системы аутентификации

Читать далее 

07.12.2024

M1Cloud: Итоги 2024 года на российском облачном рынке

Читать далее 

06.12.2024

Действия сотрудников назвали главной причиной утечек информации

Читать далее 

06.12.2024

САТЕЛ представляет систему записи разговоров СИЗАР

Читать далее 

показать все 

12.12.2024

Что следует учитывать ИТ-директорам, прежде чем претендовать на должность генерального директора?

Читать далее 

11.12.2024

Сетевая инфраструктура, сетевые технологии: что лучше – самостоятельная поддержка или внешнее обслуживание?

Читать далее 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

показать все 

Главная / Архив номеров / 2012 / Выпуск №3 (16) / Информационные системы масштаба предприятия

Рубрика: ИТ-управление

 Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии

Информационные системы
масштаба предприятия

В этой статье мне хотелось бы рассказать о некоторых особенностях обслуживания нагруженных информационных систем, которые также называются системами масштаба предприятия (enterprise level)

В каждом номере «Системного администратора» можно найти массу интереснейших обзоров, аналитических статей и просто ценных советов о том, как работать с той или иной программой или что можно внедрить. Однако далеко не каждое из предлагаемых решений может работать под высокой нагрузкой и готово для использования в качестве полноценного и долговременного решения той или иной информационной проблемы в масштабе предприятия или выводе в онлайн.

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

Принято считать, что нагруженная система – это ИТ-структура, имеющая свыше 100-200 серверов, которые занимаются достаточно однородным видом обработки данных.

Например, это может быть веб-трафик крупного издательства, обработка видеофайлов, электронный магазин, поисковая система, система монетизации «кликов», распределенный почтовый кластер. Согласимся, что проектирование и обслуживание такой армады серверов и всего, что для них должно прилагаться, имеет определенную специфику. Об этом и пойдет речь.

О чем забывают руководители ИТ-отделов

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

Первый момент. Кадры

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

Когда я работал в поисковых гигантах и общался с различными системными администраторами, понял, что разница между теми, кто работал с небольшим (до 20) количеством серверов, и теми, кто держал под управлением армады в 200, 300, а то и 1000 серверов, поистине огромная.

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

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

Простейший вопрос, как скопировать файл /tmp/document на 500 серверов, сразу выявит человека, которому подобную операцию приходилось делать, и того, кого  одобная информация интересует лишь с теоретической точки зрения.

Можно попробовать в качестве решения скопировать «в лоб», через цикл, установив и настроив предварительно ключи по ssh. Второй вариант – можно разделить 500 серверов на иерархически построенные кластеры и копировать на главной сервер кластера. Тот, в свою очередь, копировал бы их на подглавы, потихоньку спускаясь вниз, пока не будет «по цепочке» скопирован нужный файл на все 500 серверов. Можно также использовать низкоуровневую команду netcat, а можно организовать, установить и настроить протокол torrent, который распространен у любителей пиратской кинопродукции. Ничто же не мешает организовать внутреннюю сеть из 500 означенных серверов?!

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

Второй момент. Цена онлайн транзакции

Как правило, ИТ-инфраструктура – это достаточно затратная часть бюджета любой организации, а ИТ-инфраструктура высоконагруженной системы может стоить поистине астрономическую сумму.

Беда многих организаций в том, что они не до конца понимают, как приобрести и содержать такого дорогостоящего монстра. В ряде статей [1, 2] этот вопрос уже поднимался.

Понятно, что все руководители хотят иметь бесперебойно работающую информационную систему, которая способна обслужить десятки, сотни и тысячи заказчиков. Другой вопрос, что такая система недешева, а масла в огонь подливают постоянно растущие запросы на разные сертификации (PCI, в США – SAS-70, а в России – системы защиты персональных данных), которые становятся неотъемлемой частью маркетинговых проспектов любой уважающей себя ИТ-фирмы.

Если раньше соглашение о деловом партнерстве по информационному обслуживанию заключалось без оглядки на качество ИТ-системы партнера, то теперь приходится доказывать, а то и демонстрировать, что предлагаемые для работы и продажи программы написаны не на коленке, программисты набраны не из числа гастарбайтеров, серверы надежно защищены, а вся структура сертифицирована. Все это влетает в копеечку. Та же сертификация PCI [4] стоит от 20 до 50 тысяч долларов, а может, и дороже, в зависимости от сложности аудита.

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

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

Тут нужно ввести понятие «цена транзакции» – ключевое в оценке стоимости информационной услуги. Высокое значение этой цены и большой спрос на транзакции помогают фирме развиваться, а вот низкое значение и падающий спрос (который постоянно сбивают конкуренты) очень опасны для баланса с точки зрения ИТ.

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

Поясним сказанное. Некоторое время назад фирмы, которые обеспечивали доступ к электронной почте, брали с клиентов сначала 20 долларов в месяц (в России, возможно, и больше), потом стоимость подписки упала до 5 долларов в месяц, потом стала 19 долларов в год.

Всех конкурентов, как известно, обогнал Gmail, который сумел диверсифицировать статьи доходов и стал предлагать подписку к gmail.com на БЕСПЛАТНОЙ ОСНОВЕ – представляете, какая инфраструктура находится в Google, чтобы обеспечивать бесперебойную работу Gmail?! Просто оплата ее берется из других источников, а структура и масштаб поискового гиганта Google.com позволяют обеспечивать доступ к почте для пользователей.

Анализ главных операционных параметров

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

Стабильность

Ничто так не действует на нервы системному администратору, да и любому сотруднику фирмы, как нестабильность программы, с которой приходится работать. Именно из?за постоянно «падающей», по закону Мерфи в пятницу после 18.00 , системы или ночных авралов увольняются с работы компьютерщики, которые все же предпочитают плановые профилактические работы и отдых с семьей ненормированному рабочему дню и сопряженным с этим постоянным стрессом.

Любую программу, аппаратное решение, да и информационную систему в целом надо всегда оценивать в первую очередь с точки зрения стабильности работы. Одно дело, когда какой-нибудь недавно установленный из sourceforge.com менеджер проектов под Linux почему-то не работает на трех компьютерах в одной комнате – их пользователям можно вежливо предложить перекурить 10-15 минут, а самому разобраться с проблемой.

Совсем другое дело, если из-за ошибки тысячи пользователей не могут работать. Когда летом 1999 года у знаменитой фирмы eBay были проблемы со стабильностью системы, то их ценные бумаги рухнули с 20 с лишним долларов за акцию в апреле 1999-го до 10.42 доллара в августе того же года [5], а это многомиллионные убытки! Хорошо, что у eBay дела потом пошли круто в гору, а как быть всем остальным?

Как правило, считается, что все компоненты системы должны быть продублированы [3], а в общем случае надо применять правило N+1 при оценке количества аппаратных средств, что сразу удваивает или даже утраивает стоимость.

Безопасность

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

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

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

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

Масштабируемость

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

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

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

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

Колоссальный успех систем типа Cassandra, Hadoop, Dssh, Amazon EC2 и тому подобных именно в том, что они изначально проектировались как масштабируемые решения, которые понимают, как организовать работу с 10 серверами, со 100 и с 1000 серверами.

Частным случаем масштабируемости является автоматизированное обслуживание системы через программы типа Puppet., cfengne, chef и им подобные. Понятно, что никто вручную не управляет конфигурацией и не добавляет пользователей в веб-кластер, состоящий из 600 серверов. Если такую возможность программа не предоставляет, то масштабировать ее нельзя.

Доступность системы

Часто путают со стабильностью, но это другой индикатор. Нередко системы масштаба предприятия оказываются перегруженными и недоступными для конечного пользователя. Для подобных систем недостаточно просто проверить, что тот или иной процесс запущен в памяти или система доступна по сети с терминала системного администратора. Это распространенная ошибка, которую допускают многие начинающие системные администраторы – «у меня это программа работает, значит, она работает для всех».

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

Поэтому для системы масштаба предприятия необходимо организовать мониторинг «со стороны» или хотя бы из другого сегмента сети. Например, для этого можно использовать программу AlertSite. На рис. 1 показано, как выглядит сайт при доступе из Лондона, Нью-Йорка и Сан-Франциско.

Рисунок 1. Отчет по доступности сайта из Лондона, Нью-Йорка и Сан-Франциско

Доступность для конечного пользователя или для другой программы – это качественный показатель, который является итогом многих слагаемых; производительность серверов (см. ниже), скорость аплинка, качество коммутаторов, здоровье базы данных и многое другое должны соединиться вместе, чтобы пользователя порадовала нормальная веб-страничка, а не стандартная страничка «Система недоступна». Важно, чтобы все «звенья цепи» работали без перебоев, так как система становится недоступна, как только слабое звено «цепи» выходит из строя.

Это самый опасный и коварный враг фирмы, потому что ничто не распространяется так быстро и не приносит такой колоссальный ущерб, как информация о том, что «их веб-сайт постоянно лежит».

Производительность

Все высоконагруженные системы просто обязаны быть высокопроизводительными. Если ваш директор по ИТ или старший системный администратор с гордостью заявляет, что кластер обслуживает 200 миллионов запросов в час, на каждом сервере успешно работает 300 процессов apache, а команда uname -a, запущенная в цикле на 30 000 серверах, возвращает ответ через несколько секунд – есть, чем гордиться.

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

Есть задачи в мире баз данных, которые решаются на Microsoft Access, а есть те, для которых ничто, кроме Oracle Enterprise Server, к сожалению, не подойдет – и есть масса промежуточных вариантов.

И среди межсетевых экранов есть такие, которые начинают «виснуть» и перегружаться при количестве соединений свыше 1000 в секунду, а есть такие, которым одновременный пул в два миллиона соединений (Cisco ASR-1002) не страшен, вот только последние, к сожалению, стоят значительно дороже первых.

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

Дополнительно надо заметить, что производительность, масштабируемость и стабильность часто связаны друг с другом. Программа или система может отлично себя вести при малых боевых или при больших тестовых нагрузках, если тесты проводились в отрыве от реальности. Если ваш веб-сервер дает неплохие результаты по команде:

ab -n 100 -c 5 -f SSL2 https://api.certain.com/docs

то это не означает, что пять реальных пользователей успешно могут работать одновременно с этим разделом. Проектирование и измерение нагрузки – очень важный этап системной архитектуры. Если программа выводит данные наружу, например, через XLS, как это делается? Используется ли выделенный сервер для генерации отчетов, чтобы не «валить» боевые серверы? Используется ли асинхронная генерация [6]? Какие есть ограничения? Может ли она сгенерировать таблицу, состоящую из 14 миллионов записей? А если пять человек захотят сделать это же самое? Все эти вопросы должны быть тщательно рассмотрены перед обкаткой системы под реальной нагрузкой.

Управляемость

Последняя в нашем списке, но не по значимости, это концепция управляемости информационной системы. Что это такое? Если программа или информационная подсистема начинают «размножаться» на все большее число серверов и разных офисов или выходят в онлайн, то надо начинать учитывать используемое количество активных пользователей или соединений, а также вести статистику, кто и как ее использует.

Особенно актуальной эта проблема становится при выводе приложения в онлайн, когда на удачную программу или интересный веб-сайт могут свалиться тысячи, а может быть, и миллионы запросов. Даже если инфраструктура выдерживает эту нагрузку, всегда важно понимать, что делают пользователи с программой, а если фирма предлагает SaaS, PaaS, Iaas-услуги, то мы просто обязаны иметь «панель управления», а лучше несколько вариантов этой панели для разных функциональных отделов фирмы (см. рис. 2).

Рисунок 2. Панель управления программой

«Главная панель управления» – показ в реальном времени, а также возможность получать различные виды хронологических отчетов, кто и как работал в системе («фронт-офис» – это важнее скорее бизнес-структуре фирмы), что конкретно работало и не работало («бэк-оффис» – это важнее для системных администраторов).

Знают ли руководство фирмы и отдел клиентских отношений, кто в настоящий момент подключен к серверу фирмы? Кто работал сегодня в 7 часов утра? А кто работал вчера в 23.58 (см. рис. 3)? С какими модулями программы были проблемы? Знают ли системные администраторы, сколько и какого веб-трафика проходило через фирму за последние четыре часа? Что за 500 Гб появились за последние полчаса в /var/log?

Рисунок 3. Временной отчет трафика по сотрудникам

Наличие или отсутствие ответов на эти и десятки других возможных вопросов показывает, в какой степени мы управляем (владеем) ситуацией с нашей информационной системой.

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

«Системный администратор» неоднократно публиковал развернутые статьи по Nagios, Cacti, Zenoss, Ganglia и другим аналогичным системам. А вот что делать с мониторингом на уровне приложения? Важно выяснить не только те параметры, за которыми мы будем следить, но и какие-то базовые значения нормы, от которых будем отталкиваться при дальнейшей оценке. Это может быть количество сообщений в почтовом ящике пользователя, отношение платных «кликов» к бесплатным, время на сайте – все, что угодно. Но эти параметры должны существовать, по ним очень важно вести статистику и понимать, что эта статистика означает.

***

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

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

1. Кондаков К. Ловушки для ИТ-менеджеров. //«Системный администратор», №7-8, 2010 г – С. 112-116 (http://samag.ru/archive/article/993).
2. Кондаков К. Формула успеха. Бизнес-составляющая в ИТ .//«Системный администратор», №9, 2010 г – С. 66-69 (http://samag.ru/archive/article/1011).
3. Кондаков К. Поддержка системы 24х7. Организация круглосуточной работы ИТ-отдела. //«Системный администратор», №9, 2011 г – С. 108-112 (http://bit.samag.ru/archive/article/1123).
4. Кондаков К. PCI – стандарт надежности ИБ. //«Системный администратор», №10, 2011 г  – С. 106-112 (http://bit.samag.ru/archive/article/1127).
5. Martin L. Abbott, Michael T. Fisher. The art of scalability. – Addison-Wesley, 2009.
6. Что такое асинхронная событийная модель, и почему она сейчас в моде? – http://habrahabr.ru/blogs/nodejs/128772.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи