Добавлен: 04.04.2023
Просмотров: 274
Скачиваний: 2
Также необходимо выделить пакеты серверов и сопутствующих программ (к примеру, комплект веб-сервер/PHP/MySQL) для установки под Windows (для Unix свойственна модульная либо «пакетная» установка каждого компонента, поэтому такие решения редки).[6]
В интегрированных серверных решениях установка всех компонентов производится одновременно. Компоненты в той или иной мере тесно интегрированы и предварительно настроены друг на друга. Но в этом случае замена одного из серверов или вторичных приложений может образовать проблемную ситуацию.
Серверные решения необходимы для упрощения организации базовой ИТ-инфраструктуры компаний, а именно для оперативного построения полноценной сети в компании, в том числе и «с нуля». Концентрация отдельных серверных приложений в решение предполагает, что решение предназначено для выполнения множества однотипных задач, в данном случае значительно снижается сложность развёртывания и стоимость владения ИТ-инфраструктурой, построенной на таких решениях.
Прокси-сервер (от англ. proxy — «представитель, уполномоченный») служба в компьютерных сетях, предоставляющая клиентам возможность выполнять косвенные запросы к другим сетевым службам. Сперва клиент подключается к прокси-серверу и запрашивает какой-либо ресурс (например, e-mail), расположенный на другом сервере. Потом прокси-сервер либо подключается к указанному серверу и получает ресурс у него, или возвращает ресурс из собственного кеша (в случаях, если прокси имеет свой кеш). В некоторых случаях ответ сервера или запрос клиента может быть изменён прокси-сервером в определённых целях. К тому же прокси-сервер позволяет защищать клиентский компьютер от некоторых сетевых атак.[11]
1.3 Системная архитектура «клиент-сервер»
Очевидно, что в общем случае, чтобы прикладная программа, выполняющаяся на рабочей станции, могла запросить услугу у сервера, как минимум требуется некоторый интерфейсный программный слой, поддерживающий такое взаимодействие. Из этого, собственно, и следуют основные принципы системной архитектуры «клиент-сервер». [1]
Система разбивается на две части - клиентскую и серверную, которые могут выполняться в разных узлах сети. Конечный пользователь или прикладная программа взаимодействуют с клиентской частью системы, которая в простейшем случае обеспечивает просто над сетевой интерфейс. Клиентская часть системы обращается по сети к серверной части. Отметим, что в развитых системах сетевое обращение к серверной части может и не потребоваться, если система может предугадывать потребности пользователя, и в клиентской части содержатся данные, способные удовлетворить его последующий запрос.
Интерфейс серверной части определен и фиксирован. В связи с чем возможно создание новых клиентских частей существующей системы (пример интероперабельности на системном уровне).
Главной проблемой систем, основанных на архитектуре «клиент-сервер», является то, что в соответствии с концепцией открытых систем от них необходима мобильность в как можно более широком классе аппаратно-программных решений открытых систем. При том если ограничиться UNIX-ориентированными локальными сетями, в разных сетях применяется разная аппаратура и протоколы связи. Стремление создания систем, поддерживающих все возможные протоколы, приводит к их перегрузке сетевыми деталями в ущерб функциональности.
Ещё наиболее проблемный аспект этого вопроса связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах могут существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно значимо для серверов высокого уровня: телекоммуникационных, вычислительных, а также баз данных.
Основным решением проблемы мобильности систем, основанных на архитектуре «клиент-сервер» является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - RemoteProcedureCall). При применении таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, находится вся информация о специфике сетевых протоколов и аппаратуры локальной сети, переводит вызов в последовательность сетевых взаимодействий. В связи с этим, специфика сетевой среды и протоколов скрыта от прикладного программиста. [7]
При вызове удалённой процедуры программы RPC делают преобразование форматов данных клиента в промежуточные машинно-независимые форматы и затем преобразуют в форматы данных сервера. При передаче ответных параметров производятся аналогичные преобразования.
В случае если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду.
Технология «клиент-сервер» применительно к СУБД сводится к разделению системы на две составляющие – приложение-клиент (front-end) и сервер базы данных (back-end). Данная архитектура совмещает лучшие черты обработки данных на мэйнфреймах и технологии «файл-сервер». От мэйнфреймов технология «клиент-сервер» взяла такие черты, как централизованное администрирование, безопасность, надежность. От технологии «файл-сервер» унаследованы невысокая стоимость и возможность распределенной обработки данных, используя ресурсы компьютеров-клиентов. В настоящее время графический интерфейс пользователя стал стандартом для систем «клиент-сервер». Помимо этого, архитектура «клиент-сервер» значительно упрощает и ускоряет разработку приложений из-за того, что правила проверки целостности данных находятся на сервере. Неправильно работающее клиентское приложение не сможет привести к потере или искажению данных. Все эти возможности, ранее свойственные только сложным и дорогостоящим системам, сегодня доступны даже небольшим организациям. Стоимость оборудования, обслуживания и программного обеспечения для персональных компьютеров значительно ниже, чем для мэйнфреймов.[1]
1.4 Серверы баз данных
Термином «сервер баз данных» как правило обозначают всю СУБД, основанную на архитектуре «клиент-сервер», в том числе и серверную, и клиентскую части. Такие системы предназначаются для хранения и обеспечения доступа к базам данных.[13]
Хотя, как правило одна база данных целиком хранится в одном узле сети и управляется одним сервером, серверы баз данных представляют собой простое и не дорогое приближение к распределенным базам данных, так как общая база данных доступна для всех пользователей локальной сети.
1.5. Понятие прикладных протоколов
Нужно отличать понятия сетевых приложений и протоколов прикладного уровня. Протоколы прикладного уровня – это часть сетевых приложений. В этой связи следует рассмотреть два примера. Web является сетевым приложением, позволяющим пользователям получать веб-документы по запросу и состоящим из множества компонентов, в том числе и стандарта формата документов (HTML), браузеры (Opera, Microsoft Internet Explorer и др.), web-серверы (например, Apache, Microsoft или nginx), протоколы прикладного уровня. Протокол прикладного уровня для веба носит название протокола передачи гипертекста (HyperTextTransferProtocol, HTTP) и описывает формат и порядок обмена сообщениями между клиентом и сервером (RFC 2646). Таким образом, HTTP является лишь частью веб-приложения.[14]
Второй пример - приложение электронной почты. Электронная почта Интернета состоит из большого количества компонентов: почтовых серверов, программ для просмотра и создания электронных писем, протоколов прикладного уровня, стандартов, описывающих структуру электронных писем, а также интерпретацию полей, из которых состоят электронные письма. Главным протоколом прикладного уровня для электронной почты является протокол простой передачи сообщений (SimpleMailTransferProtocol, SMTP). Здесь можно убедиться в том, что SMTP (RFC 2821) — лишь часть (хотя и достаточно большая) структуры приложений электронной почты.[11]
Как заявлено выше, протоколы прикладного уровня определяют способ обмена сообщениями между двумя процессами, которые выполняются на разных оконечных системах. Как правило, протокол устанавливает такие элементы:
• типы используемых сообщений, например, запросы и ответы;
• синтаксис каждого из типов сообщений;
• семантику полей;
• описывающие события правила (причём события, вызывающие генерацию сообщений).
Определённые протоколы прикладного доступа (HTTP, SMTP и др.) являются официально документированными в RFC. Это значит, что если разработчик нового браузера следует стандарту, то у браузера будет возможность получать документы с любого web-сервера, построенного по этому же стандарту. Тем не менее существует большое число протоколов прикладного уровня, которые никак не стандартизированы и при этом используются для поддержки коммерческих продуктов. В частности, это свойственно для Интернет-телефонии.
1.6. Принципы взаимодействия между клиентскими и серверными частями
Доступ к базе данных от прикладной программы или пользователя производится с помощью обращения к клиентской части системы. В качестве основополагающего интерфейса между клиентской и серверной частями выступает язык баз данных SQL.[2]
Данный язык представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер касается всех серверов баз данных, основанных на SQL.
Серверы баз данных, интерфейс которых основан только на языке SQL, обладают своими преимуществами и своими недостатками. Очевидное преимущество – стандартность интерфейса.
Недостаток так же довольно очевиден. В таком высоком уровне интерфейса между клиентской и серверной частями системы на стороне клиента работает слишком мало программ СУБД. Это оправданно, если на стороне клиента используется маломощная рабочая станция. Но если клиентский компьютер имеет достаточную мощность, то в таком случае возникает желание возложить на него больше функций управления базами данных, разгрузив сервер, который является узким местом всей системы.
Одним из перспективных направлений СУБД является гибкая настройка системы, при котором распределение функций между серверной и клиентской частями СУБД определяется при установке системы.
1.7 Преимущества протоколов удаленного вызова процедур
Протоколы удаленного вызова процедур важны в системах управления базами данных, основанных на архитектуре «клиент-сервер».[1]
Во-первых, использование механизма удаленных процедур позволяет перераспределять функции между клиентской и серверной частями системы, так как в тексте программы удаленный вызов процедуры не отличается от удаленного вызова, и следовательно, теоретически любой компонент системы сможет располагаться и на стороне сервера, и на стороне клиента.
Во-вторых, механизм удаленного вызова убирает различия между взаимодействующими компьютерами. На физическом уровне неоднородная локальная сеть компьютеров приводится к логически однородной сети взаимодействующих программных компонентов. В результате этого пользователям нет необходимости серьезно заботиться о разовой закупке совместимых серверов и рабочих станций.
1.8 Типичное разделение функций между клиентами и серверами
В типичном на сегодняшний день случае на стороне клиента СУБД функционирует только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается к серверу с использованием языка SQL.[5]
В отдельных случаях хотелось бы включить в состав клиентской части системы определенные функции для работы с «локальным кэшем» базы данных, т.е. с той частью, которая интенсивно используется клиентской прикладной программой. В современной технологии это можно осуществить только путем формального создания на стороне клиента копии сервера базы данных и рассмотрения всей системы как набора взаимодействующих серверов.
С другой стороны, в некоторых случаях хотелось бы перенести большую часть прикладной системы на сторону сервера, если разница в мощности клиентских рабочих станций и сервера слишком велика. В общем-то при использовании RPC это сделать нетрудно. Однако необходимо, чтобы базовое программное обеспечение сервера действительно позволяло это. В частности, при использовании ОС UNIX трудности практически не возникают.
1.9 Архитектуры процессора базы данных
Основная часть любой системы «клиент-сервер» – это сервер БД. С момента возникновения архитектуры «клиент-сервер» появилось много вариантов архитектуры процессора БД, так как он во многом определяет успех всей системы. Главное требование к серверу БД – обеспечение минимального времени выполнения запросов при максимально возможном числе пользователей. Имеются две основные архитектуры для построения процессора БД: архитектура с несколькими процессами и многопоточная архитектура. [7]
1.9.1. Архитектура с несколькими процессами
Данная архитектура характеризуется тем, что несколько экземпляров исполняемого файла работают одновременно. Данные системы отличаются хорошей масштабируемостью, но требуют значительных расходов памяти, так как память каждому экземпляру приложения выделяется отдельно. Данная архитектура подразумевает наличие эффективного механизма взаимодействия процессов и полагается на операционную систему в разделении процессорного времени между отдельными экземплярами приложения. Самый известный пример сервера, построенного по этой архитектуре, - OracleServer.[12] При подключении пользователя к БД Oracle, он в действительности запускает отдельный экземпляр исполняемого файла процессора базы данных.[7]
1.9.2. Многопоточная архитектура
Многопоточная архитектура использует только один исполняемый файл, с несколькими потоками исполнения. Основное преимущество – более скромные требования к оборудованию, чем для архитектуры с несколькими процессами. В данном случае сервер берет на себя разделение времени между отдельными потоками, иногда давая преимущество некоторым задачам над другими. Кроме того, отпадает необходимость в сложном механизме взаимодействия процессов. По такой архитектуре построены MS SQL Server и Sybase SQL Server. [14]