Оглавление (стр. 5 )

И еще один довод за создание кластеров на базе Oracle9iAS Web Cache – это возможность одного Web Cache взаимодействовать с другими кэшами на этом кластере, чтобы тем самым увеличить общую пропускную способность. Каждый Web Cache обнаруживает новый контент у своего “напарника” и может сохранить его в своем собственном кэше. Также отслеживается и случай выхода из строя “напарника”. Например, если кэш в одном центре данных засбоил, то другие кэши этого кластера могут взять на себя дополнительную нагрузку.

Oracle9iAS Web Cache может не только прозрачно справляться со сбоями узлов, но и также прозрачно управляться со своими собственными сбоями. Вот это по настоящему хорошо!

Кластеризация на уровне J2EE

Oracle9iAS позволяет осуществить кластеризацию на отдельных уровнях J2EE (Java 2 Platform Enterprise Edition): клиентском, Web, EJB (Enterprise JavaBeans) и EIS (Enterpise Information System)—при условии, что приложение спроектировано и разработано в соответствии с четко определенными уровнями. Поэтому, например, приложения с бизнес-логикой на уровне EJB, реализованное с применением уровня JSP (Java Service Pages) не подходит для кластеризации.

Архитекторы/проектировщики всегда должны рассматривать возможность кластеризации на стадии проектирования своих J2EE-приложений. Расщепление уровня J2EE на отдельные уровни позже позволит и далее кластеризировать приложение, обеспечивая тем самым и более высокий уровень высокой готовности в случае сбоев. В недавнем онлайновом опросе об обеспечении максимально возможной высокой готовности J2EE-приложений, подавляющее большинство респондентов отметили, что они рекомендуют разработку приложений с Servlet и EJB на двух уровнях.

Компоненты J2EE-кластеризации

Рассмотренные ранее способы кластеризации были сфокусированы на аспектах масштабирования и производительности кластеров, что само по себе очень важно. Но эти способы не решают жизненно важные проблемы отказоустойчивости (fault-tolerance) приложений, которые обрабатывают большие объемы пользовательских данных за время длительных сессий, иначе говоря, приложений с долго живущими сессиями (long-life session-state applications).

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

Для решения этой критической проблемы для приложений, обремененных обширными данными состояния, Oracle9iAS Containers for J2EE поддерживают "cluster islands" (кластерные острова), наборы серверов на уровне J2EE, на котором параметры состояния сессии могут быть значительно легче воспроизведены, обеспечивая, тем самым, прозрачное перенаправление запроса клиента к другому компоненту, который сможет обслужить этот запрос, если некоторый J2EE-компонент выйдет из строя.

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

Принятие решений

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

Не менее важно определить расходы, связанные выходом приложений из строя. Ответственные приложения, такие как онлайновая торговля или обработка записей о пациентах госпиталей, в случае сбоев могут вызвать большие потери. С другой стороны, простые, презентационного типа приложения могут хорошо обслуживаться простыми “пещерными” технологиями.

Как архитектор приложений, вы должны рассмотреть ряд вопросов, связанных с кластеризацией: Что произойдет, если приложение выйдет из строя из-за какой-то своей ошибки или отключения питания или здание, в котором расположено ваше оборудование, сгорит? Что если откажет важный электронный компонент, или испортится корневая файловая система, приведя к краху резервные (standby) машины, или на вашем основном диске появились сбойные секторы? В какой защите нуждается ваше приложение, и как много вы готовы заплатить за такую защиту (или за ее отсутствие)?

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

И, наконец, приложения должны быть спроектированы и разработаны с использованием четко определенных уровней - клиент, Web-, EJB - и EIS - уровни. (Это очень хорошее правило в любых обстоятельствах.) По мере развития приложения его потребности в кластеризации, вероятно, будут изменяться, так что старайтесь сохранять гибкость своих приложений, насколько это возможно.

Сквозная кластеризация

Oracle9iAS предоставляет архитекторам приложений широкий набор готовых к развертыванию средств, которые помогут при решении в случаях сложной неочевидной кластеризации. Способы кластеризации простираются от простых “пещерных” методов для балансировки нагрузки до методов кэш-кластеризации приложений с богатых информационным содержанием. Кластеризация может быть организована на уровне Web-сервера и на J2EE-уровне. Архитекторы приложений могут даже выбрать кластеризацию на уровне отдельных компонентов J2EE, а с помощью “кластерных островов” (cluster islands) они могут поддерживать состояние сессий без потери производительности. Oracle9iAS – это действительно полный, всесторонний (end-to-end) инструмент реализации кластеризованных решений, способных противостоять сбоям на любых уровнях методами, прозрачными для конечных пользователей.

В данной статье вопросы кластеризации были только затронуты. Более детальные советы и технические рекомендации можно найти в “Белой Книге” о кластеризации на Oracle9iAS и на бесплатном Internet-семинаре по J2EE-кластеризации. Оба источника, как и многие другие ресурсы, доступны на OTN в Middleware Architecture Series.

Рисунок 1 Сквозная кластеризация

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

5. Модель OSI.

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

Средства взаимодействия делятся на 7 уровней : прикладной, представительный, сеансовый, транспортный, сетевой, канальный и физический.

В модели OSI есть два типа протоколов- с установленным соединением (телефон) и без предварительной установки соединения (почтовый ящик).

Физический уровень- передача потока битов по кабелям. Не вникает в смысл информации, которую передаёт.

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

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

Транспортный уровень обеспечивает приложениям или верхним уровням стека - прикладному и сеансовому- передачу данных с той степенью надёжностью, которая им требуется. Модель OSI определяет 5 видов сервиса, предоставляемых транспортным уровнем - эти виды сервисов отличаются качеством предоставляемых услуг - срочностью, возможностью восстановления прерванной связи, возможностью к обнаружения и исправлению ошибок передачи, таких как искажение, потеря и дублирования пакета.

Сеансовый уровень фиксирует, какая из сторон является активной в настоящее время, предоставляя средства синхронизации.

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

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

6. Протокол TFTP. Модель, основные команды, безопасность, производительность.

7. Конвергенция сетей.

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

Сближение локальных и глобальных сетей

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