Примеры использования
Возможности применения проекта Imserver практически безграничны, тем не менее, мы постараемся описать некоторые из успешно работающих вариантов.
Масштабирование
Благодаря функциям клонирования серверов и линейному способу расчета стоимости услуг, система Imserver позволяет плавно наращивать мощности занятые под ваши задачи, не беспокоя вас возможной нехваткой ресурсов. Однако для того чтобы полноценно использовать эту возможность, программное обеспечение исполняемое на сервере должно поддерживать подобный функционал хотя бы частично.
В качестве примера возьмем веб сайт с высокой нагрузкой. В начале проекта этому ресурсу не требуется большая серверная производительность. И можно обойтись одной виртуальной машиной. Однако в процессе роста популярности ресурса объем посетителей и нагрузки может вырасти в десятки и сотни раз. Если использовать классическую систему вертикального масштабирования (один сервер - один сайт), то рост такого проекта будет ограничен исключительно производительностью этого одного сервера. В такой схеме, есть один большой недостаток, если нагрузка на Ваш проект вырастет, то придется тратить колоссальные суммы на приобретение крайне дорогостоящего оборудования. А если нагрузка вырастет еще больше? Выход есть.
Необходимо изначально заложить в проект возможность горизонтального масштабирования. А именно - возможность добавления в систему новых серверов и распределения нагрузки по ним. Для решения этой задачи как раз и приходит на помощь проект Imsever.
Существует несколько способов обеспечения горизонтального масштабирования. Одним из них является балансировка нагрузки между серверами. В простейшем варианте достаточно лишь выполнить клонирование сервера и распределить нагрузку по серверам с помощью DNS (два IP адреса на одну DNS запись). Пользователи, когда будут заходить на сайт, будут автоматически распределяться по этим двум серверам и тем самым снижая нагрузку на каждый из них в отдельности. Этот способ подходит для статичных сайтов, где изменение содержимого в процесс эксплуатации практически не происходит. Однако такой вариант будет мало применим для динамичных сайтов с постоянным взаимодействием с пользователем.
Для решения этой задачи понадобится разделить проект на несколько частей. Первая часть будет отвечать за прием сообщений, их распределение по серверам и формирование ответов посетителям. Вторая часть будет обеспечивать вычисление, работу PHP скриптов и прочего. Третья часть - непосредственно хранение данных. Локальные (частные) сети между этими частями обеспечат безопасность и скорость работы. ( см рис.1.)
Первая часть может представлять из себя простейший сервер с запущенным на нем кеширующем Веб сервером nginx. Его задача: принять HTTP запрос посетителя, проанализировать его и, если такой запрос ранее не производился, передать его на вычислительный узел. Если же такой запрос уже был, то сразу же отдать данные посетителю не нагружая вычислительные узлы и базы данных. Для реализации балансировки нагрузки можно использовать специально предназначенные для этого пакеты. Например такие как Zen load balancer или haproxy. На этом этапе, как правило, отсекается более трети нагрузки на систему. В случае, если нагрузка продолжает расти, то такой балансировщик можно просто клонировать, тем самым разделив нагрузку уже между двумя (или более) балансировщиками.
Веб сервер представляет из себя виртуальный сервер с запущенным на нем веб сервером Apache и предназначен непосредственно для работы приложений. Именно к нему перенаправляют запросы посетителей серверы балансировщики. Их задача - подготовка контента для ответа посетителю. Именно они выполняют запросы к базам данных и готовят ответ посетителям. При создании таких серверов нужно понимать, что их задача - динамичный контент.
Эти серверы тоже можно клонировать в один клик, так как, по сути, их содержимое не меняется в процессе работы, за исключением механизмов обновления самих приложений (php скриптов и прочего).
Третья и самая сложная часть, это хранение данных, СУБД. Веб серверы получают информацию как раз от них. Именно на них ложится основная дисковая нагрузка, однако практически все современные СУБД имеют встроенный функционал репликации между базами данных, позволяют использовать возможности шардинга (архитектура базы данных строится таким образом, чтобы каждая атомарная операция при работе с БД не зависела от других таблиц и может располагаться на других базах, например фамилии начинающиеся на буквы от "А" по "Р" храним в одной базе данных а фамилии начинающиеся на буквы от "C" по "Я" в другой).
Немаловажным значением является и тот факт, что стоимость услуг в проекте imserver является линейной, это значит что два сервера с 1 ядром, 1 гб оперативной памяти и диском на 5 гб каждый, будут стоить столько же, сколько и сервер с 2-мя ядрами, 2 гигабайтами оперативной памяти и 10 гб места на диске. Иначе говоря, совершенно не важно какой путь вы выберете для увеличения масштабов своего проекта. Стоимость будет расти пропорционально используемым ресурсам. Все это позволяет наращивать производительность системы по мере роста проекта, на задумываясь, что в какой то момент вам просто не хватит производительности железа или объемов памяти. Остается только добавить, что подобный подход позволяет рассчитать точную стоимость обслуживания посетителей и линейно экстраполировать эту информацию на расчетный объем, тем самым точно планировать бюджет Вашего проекта.
Отказоустойчивость
Сбои и поломки бывают всегда и везде, так как не существует в мире ничего постоянного. Как правило, отказоустойчивость достигается методом одиночного или многократного дублирования всех возможных систем с целью избежать появления в системе единых точек отказа, тех самых элементов, выход из строя которых, приведет к фатальным для всей системы последствиям.
Используя возможности горизонтального масштабирования, можно создать несколько параллельных путей прохождения запросов посетителей. ( см рис. 2). Например, если у Вас используется несколько балансировщиков нагрузки, то выход из строя одного из них не приведет к недоступности сайта в целом, а лишь отразится в виде снижения производительности. А если произошел сбой на одной из СУБД, всегда есть актуальная копия данных на другом сервере. Более того, ваш ресурс будет доступен до тех пор пока в системе доступен хотя бы один полный путь (балансировщик, веб сервер, база данных). Современные системы балансировки нагрузки, автоматически определяют вышедший из строя компонент и перестают передавать на него запросы, они же способны общаться друг с другом, определяя состояние соседа и в случае необходимости подхватывая нагрузку на лету.
В некоторых ситуациях критично важным является время восстановления работоспособности, если сбой все же произошел. Использование функционала клонирования позволяет обслуживающему персоналу в течении нескольких минут вернуть производительность системы в норму. При создании новых виртуальных машин Imserver автоматически распределяет виртуальные серверы по разным физическим серверам, по разным стойкам и возможно даже по разным датацентрам, тем самым обеспечивая устойчивую работу даже в случае частичного выхода из строя физического оборудования проекта Imserver.
Разработчикам
Результаты работы разработчиков программных продуктов, крайне зависят от качества их тестирования. В некоторых ситуациях ошибки в коде могут привести к краху и, как итог, потере драгоценного времени. Проект Imserver в своей работе использует метод посекундной тарификации ресурсов. Это означает, что виртуальные серверы можно создавать на любое время, при этом оплачивая лишь реальное время их использования. К примеру, у нас есть один сервер, где установлен дистрибутив и нам надо проверить, как этот дистрибутив поведет себя в реальных "боевых" условиях. Мы создаем виртуальный сервер, устанавливаем на него дистрибутив, и, если что-то пошло не так, просто удаляем виртуальную машину, при этом оплачивая лишь те минуты которые сервер работал. Еще один пример применения системы - в качестве временного создания полнофункциональных копий вашей разработки для демонстрации потенциальным заказчикам. Не нужно закупать собственное железо, не нужно его поддерживать, следить за актуальностью драйверов, долго и сложно устанавливать программное обеспечение. Достаточно один раз подготовить шаблон и, используя этот шаблон, создать новый временный сервер, а затем удалить, когда он перестанет быть нужным. Весь функционал проекта Imserver доступен для управления и через API. Это позволяет с помощью не сложных скриптов, автоматизировать рутинные задачи.
Услуги хостинга
Основой деятельности любого хостинг провайдера является надежное технологическое оборудование, жизнеспособная бизнес модель и масштабируемость. В качестве примера, разберем структуру программного комплекса ISPmanager Business предлагаемую компанией ISPsystem. Количество серверов, которое возможно включить в состав ISPmanager 5 Business, не ограничено. Для работы с каждым конкретным сервером при включении его в состав серверов, на нём определяется операционная система, подключаются необходимые репозитории, производится установка необходимого программного обеспечения. Для удалённого управления на каждый сервер устанавливается специальная панель управления - ISPmanager 5 Node. Каждый из серверов в комплексе исполняет отведенную ему техническую роль. Веб сервер, Почтовый сервер, Сервер доменных имен, и т.д. Любая роль, кроме роли основного сервера имён, может быть назначена любому серверу, любому количеству серверов, тем самым обеспечивая возможность горизонтального масштабирования всего проекта хостинга в целом. Возможности интеграции системы ISPmanager c другими продуктами ISPsystem позволяют без особых усилий создать полноценную техническую платформу для оказания услуг хостинга. Разворачивание такой системы на ресурсах проекта Imserver занимает всего несколько минут и может быть выполнено специалистами без специальной технической подготовки.