СОДЕРЖАНИЕ Введение ................................................................................................................... 2 1 Теоретические аспекты реализации тонких клиентов ..................................... 5 1.1. Определение и особенности тонких клиентов ........................................ 5 1.2. Клиент-серверная архитектура в реализации тонких клиентов ............ 6 1.3. Виртуализация и тонкие клиенты ........................................................... 13 2 Организация тонких (терминальных) клиентов в ИП Коровянских Екатерина Олеговна .............................................................................................. 21 2.1. Выбор программного обеспечения ......................................................... 21 2.2. Установка и настройка программного обеспечения для реализации тонких клиентов в сети. ..................................................................................... 23 2.2.1. Развертывание сборочной среды DevStation ..................................... 30 2.2.2. Сборка служебного образа ThinStation ............................................... 31 Заключение ............................................................................................................ 40 Список использованных источников .................................................................. 42 Изм. Лист № докум. Разраб. Попов Д.. Руковод. Сомова Н.С. Консул. Реценз. Пред. ЦМК. Переволоцкая И.Н. Подпись Дата ОГАПОУ БПК О. 09.02.06 ДП. 677г. ПЗ книжки. ПЗ Реализация тонких клиентов в компьютерной сети ИП Коровянских Екатерина Олеговна Лит. Лист Листов 1 46 ОГАПОУ БПК 41 СА Введение С развитием информационных технологий и повышением требований к эффективности рабочих процессов предприятий и организаций становится все более актуальной проблема выбора оптимальной архитектуры компьютерных систем. В этом контексте особенное внимание уделяется реализации тонких(терминальных) клиентов в компьютерной сети – технологии, позволяющей эффективно управлять и обеспечивать доступ к вычислительным ресурсам через централизованный сервер. Терминальные клиенты представляют собой инновационный подход к построению информационных систем, в котором основная вычислительная нагрузка перемещается с рабочих станций на серверы, а пользовательские устройства служат всего лишь интерфейсом для доступа к удаленным ресурсам. управления Такая архитектура системой, обеспечивает повышение значительное безопасности и упрощение снижение общей стоимости владения информационной инфраструктурой. В современном информационном обществе, где бизнес-процессы и рабочие задачи становятся всё более комплексными и динамичными, вопрос оптимизации информационных технологий и управления ресурсами становится ключевым. В этом контексте особую значимость приобретает тема реализации тонких клиентов в компьютерной сети. Современные тенденции в области ИТтехнологий удовлетворить требуют поиска растущие эффективных потребности в решений, безопасности, способных гибкости и предприятий к эффективности в управлении информационными ресурсами. Актуальность темы основана на стремлении максимальной оптимизации рабочих процессов, сокращению затрат на обслуживание информационной инфраструктуры и повышению уровня безопасности. Внедрение тонких клиентов предоставляет новые возможности для достижения этих целей, улучшая управление вычислительными ресурсами и ВВЕДЕНИЕ Изм. Лист № докум. Подпись Дата Лист 2 обеспечивая централизованный контроль над данными. Современные рабочие сценарии все более ориентированы на мобильность и удаленную работу. Работники ожидают гибкости в доступе к информации независимо от местоположения. Тонкие клиенты, интегрированные в компьютерную сеть, позволяют эффективно удовлетворять эти требования, обеспечивая безопасный и удобный доступ к корпоративным ресурсам. С ростом объемов данных и их критической роли в бизнес-процессах, вопросы эффективного управления, безопасности и доступности данных становятся более важными. Тонкие клиенты предоставляют решения, способные справиться с этими вызовами, обеспечивая централизованное управление и защиту данных. Внедрение тонких клиентов обещает значительные выгоды для организаций. Экономия аппаратных средств, уменьшение времени на администрирование и обновление, а также повышение безопасности данных это лишь некоторые из практических преимуществ, которые могут быть получены в результате исследования и внедрения данной технологии. Это особенно актуально в современных условиях, когда требуется обеспечить эффективное удаленное взаимодействие сотрудников, учесть возрастающие требования к безопасности данных и улучшить управление информационной инфраструктурой предприятий. Целью данной выпускной квалификационной работы является анализ, проектирование и реализация терминальных клиентов в компьютерной сети с целью оптимизации управления вычислительными ресурсами, повышения безопасности данных и достижения эффективности и гибкости рабочих процессов. Методы исследования: теоретический анализ технической литературы и практические методы Объект исследования - компьютерная сеть предприятия, предмет реализация терминальных клиентов в данной сети. Анализ технологии терминальных клиентов и их интеграция в сетевую инфраструктуру станут основой исследования ВВЕДЕНИЕ Изм. Лист № докум. Подпись Дата Лист 3 Для достижения поставленной цели предполагается решение следующих задач: 1. Провести анализ существующих технологий терминальных клиентов и выявить их преимущества и недостатки. 2. Разработать методологию внедрения терминальных клиентов, учитывая особенности конкретной сетевой инфраструктуры. 3. Оценить эффективность реализации терминальных клиентов с точки зрения управления ресурсами и повышения безопасности данных. В ходе исследования будут рассмотрены следующие проблемы: 1. Эффективность применения терминальных клиентов в условиях существующей сетевой инфраструктуры. 2. Проблемы внедрения и интеграции терминальных клиентов в рабочие процессы предприятия. Практика проходила в ИП Коровянских Екатерина Олеговна, компания занимается логистикой и отправкой грузов. Диплом состоит из двух частей, в первой части рассматривается теоретические сведения о терминальных клиентах, во второй части рассказывается о настройке терминальных клиентов и подготовке эталонных файлов для установки. ВВЕДЕНИЕ Изм. Лист № докум. Подпись Дата Лист 4 1 Теоретические аспекты реализации тонких клиентов 1.1. Определение и особенности тонких клиентов Тонкий клиент — это компьютер или устройство, которое выполняет ограниченные вычислительные функции и зависит от центрального сервера для выполнения более сложных задач и предоставления приложений. В отличие от традиционных персональных компьютеров, тонкие клиенты имеют минимальные аппаратные ресурсы и не загружены сложными вычислениями, так как большая часть вычислительной работы осуществляется на сервере [5]. Тонкие клиенты отличаются низкими аппаратными требованиями по сравнению с традиционными ПК. Они обычно имеют ограниченный объем оперативной памяти и накопителей, так как основная часть вычислений происходит на сервере. Основная особенность тонких клиентов — централизованное управление. Вся вычислительная мощность и управление приложениями распределены на сервере, что обеспечивает более простое администрирование и обновление. Тонкие клиенты требуют непрерывного доступа к сети для выполнения своих функций. Они зависят от качества сетевого соединения, и проблемы с сетью могут сказаться на производительности и доступности сервисов. Для взаимодействия с сервером тонкие клиенты используют различные протоколы передачи данных, такие как Remote Desktop Protocol (RDP), Independent Computing Architecture (ICA), или HTML5. 1. Remote Desktop Protocol (RDP): RDP обеспечивает виртуальное взаимодействие с удаленным рабочим столом, позволяя клиентам выполнять задачи на сервере. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 5 2. Independent Computing Architecture (ICA): ICA, разработанный для тонких клиентов Citrix, предоставляет протокол для передачи данных и управления сессиями. 3. HTML5 и веб-технологии: Использование веб-технологий позволяет реализовать тонких клиентов через браузер, что упрощает доступность и масштабируемость. Централизованный характер тонких клиентов обеспечивает более эффективное управление безопасностью и защитой данных. Критические данные остаются на сервере, что уменьшает риски утраты или кражи информации с клиентских устройств. Благодаря низким аппаратным требованиям, тонкие клиенты потребляют меньше энергии по сравнению с традиционными персональными компьютерами, что способствует энергосбережению в корпоративной среде. Таким образом, направленную на тонкие клиенты оптимизацию представляют использования собой технологию, ресурсов, упрощение администрирования и обеспечение безопасности данных при обработке информации в компьютерной сети [10]. 1.2. Клиент-серверная архитектура в реализации тонких клиентов Клиент-серверная архитектура является фундаментальным принципом в реализации тонких клиентов. Эта модель предполагает разделение функций между двумя основными компонентами: клиентской частью, которая обеспечивает взаимодействие с пользователем, и серверной частью, ответственной за обработку данных и выполнение более сложных операций. Принципы работы терминальных клиентов в компьютерных сетях основываются на концепции централизованного управления ресурсами, где центральный сервер выполняет вычисления, а клиентские устройства осуществляют лишь отображение результатов и ввод данных. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 6 Рассмотрим основные принципы функционирования терминальных клиентов [11]. Одним из ключевых принципов работы терминальных клиентов является централизация ресурсов. Все вычисления, обработка данных и хранение информации осуществляются на центральном сервере. Клиентские устройства служат лишь входной точкой для доступа к этим ресурсам. Это позволяет эффективнее использовать вычислительные мощности и обеспечивает стандартизацию рабочих окружений. Терминальные клиенты предназначены для минимизации нагрузки на клиентские устройства. Весь тяжелый вычислительный процесс, включая выполнение приложений и обработку данных, происходит на сервере. Клиентское устройство информации и передачи выполняет только пользовательского функции ввода, отображения что позволяет использовать даже более старое или слабое оборудование для клиентов. Централизованный принцип терминальных клиентов обеспечивает удобное централизованное управление инфраструктурой. Администраторы имеют возможность централизованно управлять пользователями, ресурсами, обновлениями и политиками безопасности на центральном сервере. Это облегчает задачи обслуживания и поддержки сети. Терминальные клиенты обеспечивают мобильность и гибкость в организации рабочих мест. Пользователи могут получать доступ к своим рабочим средам с любого устройства, поддерживающего технологию терминальных клиентов. Это особенно полезно для сотрудников, которые часто перемещаются или работают из удаленных локаций. Все данные и приложения хранятся на центральном сервере, что способствует повышенной безопасности и управлению доступом. Потери данных на клиентских устройствах минимизированы, так как все важные данные остаются на сервере, что облегчает обеспечение конфиденциальности и защиты информации. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 7 Принципы работы централизованный доступ терминальных клиентов, такие как управление, минимизация нагрузки на и клиентские устройства и обеспечение безопасности данных, делают эту технологию привлекательной для предприятий, стремящихся к эффективному и удобному управлению информационными ресурсами. Архитектура терминальных клиентов представляет собой структурный дизайн и организацию компонентов, обеспечивающих взаимодействие между центральным сервером и клиентскими устройствами. В данном разделе рассматриваются ключевые элементы архитектуры терминальных клиентов, выделяются их функциональные роли и взаимосвязи. Серверная часть архитектуры терминальных клиентов является центром управления и обработки данных. Она включает в себя следующие компоненты: Терминальный - сервер: Это центральное устройство, ответственное за обработку вычислительных задач и хранение данных. Терминальный сервер выполняет основные вычисления и предоставляет средства для взаимодействия с приложениями. База данных: Серверная архитектура предусматривает наличие - базы данных, где хранятся пользовательские профили, настройки и данные. Это позволяет пользователям получать доступ к своему персонализированному окружению независимо от того, на каком клиентском устройстве они работают. Средства управления: в архитектуре должны присутствовать средства управления, обеспечивающие администраторам возможность мониторинга и настройки терминального сервера, а также управление пользователями и ресурсами. Клиентская часть архитектуры терминальных клиентов предназначена для предоставления пользователю доступа к ресурсам и сервисам терминального сервера. Основные компоненты клиентской части включают: ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 8 Терминальный - клиент: Это программное обеспечение, установленное на клиентском устройстве, которое обеспечивает визуальное отображение данных и передачу ввода пользователя на терминальный сервер. Терминальный клиент является интерфейсом между пользователем и сервером [3]. Протоколы передачи данных: Для обеспечения эффективной - передачи данных между сервером и клиентом используются специальные протоколы, такие как RDP (Remote Desktop Protocol) или другие, в зависимости от выбранной технологии. Клиентские устройства: Это конечные устройства, на которых работают терминальные клиенты. Они могут быть персональными компьютерами, ноутбуками, тонкими клиентами или другими устройствами с поддержкой технологии терминальных клиентов. Сетевая инфраструктура играет ключевую роль в архитектуре терминальных клиентов, обеспечивая соединение между клиентскими устройствами и терминальным сервером. Это включает в себя сетевые протоколы, маршрутизацию, а также средства обеспечения безопасности для защиты передаваемых данных. Все компоненты архитектуры терминальных клиентов взаимодействуют для обеспечения стабильной и эффективной работы системы. Правильное проектирование и конфигурация каждого элемента становятся решающими факторами для успешной реализации технологии терминальных клиентов в компьютерной сети предприятия. Существует несколько видов решений для организации тонких (терминальных) клиентов. Клиентская виртуализация, или Virtual Desktop Infrastructure или VDI, является последним событием в тонких вычислениях. Это адаптация виртуальной серверной технологии. Используя корпоративные продукты виртуализации, такие, как Citrix XenDesktop, VMware View и Microsoft Hyper-VDI, гипервизор работает на сервере и управляет несколькими ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 9 виртуальными машинами внутри сервера, при этом каждая из них содержит операционную систему, приложения и поток данных пользователя[15]. Доступ осуществляется с помощью "тонкого клиента", а также современных протоколов (в том числе Citrix HDX, Microsoft RDP и RemoteFX (при наличии) и VMware View с PCoIP), что позволяет предоставить пользователю такой же опыт, как и при работе с обычным ПК. Клиентская виртуализация позволяет операционной системе, такой как Microsoft Windows, выполнится на своей выделенной виртуальной машине на сервере. Таким образом, исключается конфликт любых приложений разных пользователей. Более того, предприятия получают возможность доставлять безопасные, изолированные десктопы, доступные в любое время и с любого устройства. Каждый тонкий клиент, отображающий среду для пользователей, централизованно управляется и может быть размещен в любом месте сети. Клиентская виртуализация как правило обеспечивает полную совместимость приложений. Доставка ОС и приложений является мощным третьим вариантом в области виртуализации. Хотя приложения в виртуальном представлении и клиентской виртуализации, как правило, выполняются на сервере и отображаются на конечном устройстве клиента, в технологии доставки ОС и приложений, ОС, приложения и данные хранятся в центрах обработки данных и передаются по сети в режиме реального времени для исполнения на конечных устройствах, так как это было с ПК. Ценность данной модели состоит в том, что на конечном устройстве не нужен жесткий диск, хранение происходит в центре обработки данных, что делает безопасность, управление и поддержку операционной системы и приложений гораздо проще. Программное обеспечение доставляется для выполнения на десктоп в режиме реального времени, с производительностью равной современных ПК, но с гораздо меньшими затратами и требованиями к центрам обработки данных и инфраструктуре. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 10 Облачные вычисления используют технологии веб или все технологии, которые были упомянуты выше, для хоста приложений в частных (внутри дома) или общественных (в Интернете) центрах обработки данных, с доступом к ним по частной сети, или по защищенному каналу через Интернет. Использование общественных и частных облаков потенциально может сделать личные приложения и бизнес повсеместно доступными. В своем облаке виртуализации, можно выбрать виртуальное представление, VDI, или сочетание обоих технологий с помощью мощных корпоративных решений от компаний Vmware, Citrix, Microsoft и.т.д.. Технологии публичного облака применяются в Amazon, Microsoft, Google. Доступ в эти облака не требует ПК, по сути, ПК не нужен для многих приложений. Облачными системами называются системы, которые характеризуются следующими признаками: Ресурсами, которые динамически выделяются для удовлетворения потребностей пользователей в сфере ИТ. Ресурсами, которые доступны по первому обращению, за счёт эмуляцией пула. Возможность осуществлять динамически горизонтальное масштабирование, как в сторону уменьшения, так и в сторону увеличения, так называемая эластичность. Широкий спектр доставки для пользователей ресурсов ИТ и услуг, которые необходимы пользователю. Для данного определение характеризуется то, что в него попадает широкий спектр ИТ систем. Это создает проблему идентификации технологии инфраструктуры, как облачной. Необходимо дать определение модели, по которым услуги будут доставляться потребителям: ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 11 1. SaaS —является программным обеспечением в области качества сервиса. Этот метод является распространенным, он предоставляет доступ к программному обеспечению, которое обладает требуемым функционалом. При всем этом пользователь не может контролировать внутренние системы провайдера. Исключением может быть программное обеспечение, которое обладает управлением доступа к сервису 2. PaaS — является платформой разработки приложений в области качества сервиса. Облачный провайдер передает в использование платформы, которые необходимы для разработки приложений в облачной среде. При всем этом пользователь не может управлять облачной инфраструктурой и платформой, но может тестировать, создавать и выполнять свои приложения на платформе, которую ему предоставили. 3. IaaS — является ИТ инфраструктурой в качестве сервиса. Облачный провайдер передает в эксплуатацию пользователя системы, такие как хранилище данных, сетевое оборудование и виртуальный сервер. В представленной модели пользователь может устанавливать свое программное обеспечение и управлять операционной системой, хранилищами данных и сетевыми соединениями [13]. Модели облака, разделяют на классы, которые объединяют характеристики и методы пакетирования облачных услуг: 1. Public Cloud - Публичное облако. Модель является облачной инфраструктурой и предоставляется для использования всем желающим. Эта система была создана одним из глобальных провайдеров и тем самым услуги продаются через интернет. Любой человек имеет возможность приобрести нужную ему услугу, оплатив её банковской картой или иным, доступным методом. 2. Private Cloud - Частное облако. Эта система является созданной и эксплуатируемой только одной организацией. 3. Hybrid Cloud - Смешанное облако это облачная система, которая интегрирована с другой системой. К примеру, компания Amazon реализует ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 12 модель IaaS, имеющая облако ЕС2. Для создания облачной системы необходимы широкие меры по модернизации ИТ инфраструктуры. Предусмотрены различные методы доставки услуг потребителям, а также интеграция с облачными системами различных облачных провайдеров. В связи с этим можно сделать вывод что, клиент-серверная архитектура является основой для реализации тонких клиентов. Эта модель предполагает разделение функций между клиентской и серверной частями. Все вычисления, обработка данных и хранение информации происходят на центральном сервере, а клиентские устройства отвечают за отображение результатов и ввод данных. Централизованное управление ресурсами и стандартизация рабочих окружений упрощают обслуживание и поддержку сети. Терминальные клиенты обеспечивают мобильность и гибкость в организации рабочих мест, позволяя сотрудникам получать доступ к своим рабочим средам с любого устройства. Виртуализация и тонкие клиенты 1.3. Виртуализация рабочих столов — это подход, при котором происходит разделение среды (ОС, данные, приложения) и устройства, на котором обычно привык работать пользователь. Этот подход больше не привязывает пользователя к своему физическому рабочему месту в офисе, что позволяет пользователю работать с его привычными приложениями и данными с любого устройства и из любого места. Устройство может быть к примеру – планшет, телефон, тонкий клиент и т д. В основе этого подхода лежит не одна технология, а совместное использование различных решений в области клиентской виртуализации. Популярные технологии: 1. VDI(виртуальных инфраструктура рабочего стола) – это решение, позволяющее запускать ОС внутри виртуальной машины на сервере в ЦОД и ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 13 работать с ней удаленно, при помощи различных устройств. К такой технологии относятся: Citrix XenDesktop, VMware View, MS VDI. 2. Терминальные предоставляющий сервисы серверную – это операционную терминальный систему доступ, нескольким пользователям в конкурентном режиме. Решения – Citrix XenApp, Microsoft RDS. 3. Виртуализация приложений – это решение, позволяющее устанавливать различные приложения всего один раз и в дальнейшем передавать приложения пользователям автоматически по их запросам. Такое решение позволяет упростить администрирование рабочих станций, позволяет устанавливать приложения через единую консоль управления, разделяет приложения между собой и не позволяет происходить конфликтам из-за несовместимости [20]. 4. Решения – Microsoft App-V, Citrix XenApp, VMware ThinApp. Рассмотрим некоторые из предложенных систем. Citrix XenDesktop Представляет собой решение для виртуализации рабочего стола и приложений Windows в услугу по запросу, которая доступна пользователю из любого места и по любому устройству, будь то планшет, смартфон, тонкий клиент. XenDesktop предоставляет пользователям хорошие условия для работы, значительно лучше чем на ПК. Пользователям отображается мгновенно их рабочий стол, в котором содержатся все параметры и личные данные, в независимости от их устройства. Провижининг новых пользователей происходит при помощи создания учетной записи в Active Directory и привязке ее к рабочему столу. Приложения, которые необходимы пользователям, доставляются на их виртуальные рабочие столы. Profile Management предоставляет применение личных параметров пользователей к их виртуальным рабочим столам и приложениям, независимо от устройства и местоположения. XenDesktop доставляет рабочие столы пользователей, включающие самые последние обновления без каких-либо конфликтов. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 14 Хранение эталонного рабочего стола в ЦОДе, предоставляет пользователям первоначальный обновленный рабочий стол после каждого входа. Виртуальные приложения значительно уменьшают количество образов рабочих столов и упрощают их, уменьшают системные конфликты. Это позволяет увеличить плотность виртуальных рабочих столов. Размещенные и потоковые приложения позволяют разделять приложения из образа рабочего стола, это упрощает управление и повышает гибкость. Открытая архитектура интегрируется с Windows Server 2008R2 HyperV, VMware vSphere, Citrix XenServer, это говорит, о том, что в продукте отсутствуют ограничения на поставщика для пользовательских устройств и устройств виртуализации. Доступ к своему виртуальному рабочему столу можно получать с наиболее распространенных пользовательских устройств, включая Mac OS, Windows, Linux. Поддержка смарт-карт дает возможность пользователям использовать цифровую подпись и шифровать документы, поддержка карт общего доступа и usb карт. Аутентификация доступна для виртуальных рабочих столов, под управлением операционных систем Vista, Windows 7. Profile Management предоставляет достаточно надежный и эффективный метод управления параметрами персонализации пользователей в физических и виртуальных средах Windows. Он требует администрирования и минимальной инфраструктуры, но обеспечивает пользователям быстрый вход в систему и выход из системы. Desktop Delivery Controller установлен на сервере в ЦОД, осуществляет проверку подлинности пользователей, является брокером и управляет сборкой сред виртуальных рабочих столов. Он осуществляет управление рабочими столами, стартует и останавливает их в зависимости от конфигурации администратора. Так же Profile menegement позволяет управлять персонализацией пользователей в физических и виртуальных средах Windows. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 15 Virtual Desktop Provisioning создает виртуальные рабочие столы из эталонного образа, рабочего стола по запросу, предоставляет первоначальный рабочий стол каждому пользователю при входе в систему и оптимизирует использование памяти. Провижининг повышает гибкость и сокращает количество точек управления рабочих столов для приложений. Virtual Desktop Agent установлен на виртуальном рабочем столе, обеспечивает прямое подключение через ICA между рабочим столом и устройством пользователя. Citrix online plug-in установлен на устройстве пользователя, является модулем для опубликованных приложений, обеспечивает ICA подключение пользовательских устройств к виртуальному рабочему столу. Citrix XenApp. При помощи этого компонента можно использовать преимущества связанной с потоковой доставкой и виртуализации пользовательских приложений. Предоставляет как администраторам, так и пользователям условия работы с приложениями, лучше, чем с уже установленными. Приложения очень быстро запускаются, качество условий для работы пользователей значительно повышено, и достаточно сильно снижены расходы на директирование приложениями. Citrix XenServer — является решением инфраструктуры для виртуальных машин класса предприятий, создающее основы для доставки виртуальных рабочих столов и предоставляющее расширенные возможности для управления. XenServer позволяет запустить большое количество виртуальных машин при помощи последних процессоров AMD и Intel с поддержкой виртуализации. Secure delivery подключение пользователей за переделы брандмауэра, используется технология Citrix Access Gateway, которая использует протокол SSL, для безопасности подключения. Это устройство SSL VPN для развертывания в демилитаризованной зоне для обеспечения безопасной точки доступа через корпоративный брандмауэр. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 16 WAN optimization. В развёртываниях XenDesktop, где виртуальные десктопы доставляются пользователям в удаленных местонахождениях, например, в офисах филиалов, можно использовать технологию Citrix Branch Repeater для оптимизации производительности посредством управления качеством обслуживания. Branch Repeater может назначать приоритет различным частям условий работы пользователя, с тем, чтобы предотвратить, например, ухудшение условий работы пользователя в офисе филиала при отправке по сети большого файла или задания печати. Технология HDX IntelliCache с устройством Branch Repeater обеспечивает сжатие при помощи маркеров и редупликацию данных, значительно снижая требования к полосе пропускания и повышая производительность. Monitoring. Citrix EdgeSight для виртуальных рабочих столов позволяет произвести мониторинг отдельных рабочих столов. EdgeSight используется не только для анализа, но и также для заблаговременных предупреждений администратора о проблемах, которые могут быть возможны в будущем. EasyCall позволяет пользователям инициировать вызов со своего виртуального рабочего стола и совершить вызов между АТС и любым расположенным близко телефоном. Citrix HDX включает в себя обширную технологию, предназначенную для обеспечения высококачественных условий работы пользователя с виртуальными рабочими столами в современных средах мультимедиа. В ЦОД технологии HDX используют вычислительные мощности и масштабируемости серверов для получения высокой производительности при работе с мультимедийными данными и графикой, независимо от возможностей устройства пользователя. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 17 HDX в сети предусматривает улучшенные возможности оптимизации и ускорения для обеспечения прекрасных условий работы пользователя в любой сети, включая удаленный доступ к рабочему столу в низкоскоростных средах с большой задержкой. HDX использует в устройстве вычислительные возможности самого устройства для оптимизации и условий для работы пользователя. Microsoft RPD позволяет пользователям получать доступ к своему рабочему столу, находившемуся в ЦОД, с любого пользовательского устройства. Инфраструктура VDI выполняется на версии Windows Server 2016. - Windows Server 2016 предоставляет единую платформу для установки любых типов настольных компьютеров, в связи с этим упрощается их управление и развертывание. - Благодаря технологии Remote FX обеспечивается постоянное функциональная связь с пользователем, независимо от типа устройства и места. - В RDS подразумевается три варианта развертывания, устройства на основе сеансов, личные виртуальные машины и объединённые пулы виртуальных машин. Клиенты могут развернуть любое устройство подходящего типа с единой платформой для своих пользователей. Служба DirectAccess предоставляет удаленным пользователям доступ к ресурсам без наличия подключения к VPN. Администраторы могут отслеживать подключения пользователей к рабочему столу, еще до входа пользователя в систему, тем самым это позволяет управлять клиентскими устройствами, подключенными к интернету. - Позволяет упростить настройку и развертывание. - Позволяет упростить инфраструктуру, ведь теперь больше не требуется протокол Ipv6 и службы сертификатов. - Поддержка нескольких узлов, тем самым увеличивая производительность системы. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 18 Позволяет управлять удаленно. - Служба BranchCache кэширует данные, к которым имеют доступ пользователи такой подход позволяет автоматически и прозрачно оптимизировать доступ пользователей к данным на файловых серверах и серверах интернета через глобальную сеть. BranchCache обеспечивает: гибкое развертывание – распределение между одноранговыми - клиентскими компьютерами или размещенный кэш; упрощенное управление групповой политикой и Windows - PowerShell v3; - автоматическое шифрование кэша; - интеграцию с функцией хранилища файлового сервера в Windows Server 2016. Новый протокол RDP значительно снижает требования к полосе пропускания, что уменьшает объем трафика не затрагивая пользователя. В результате анализа теоретических аспектов реализации тонких клиентов в компьютерной сети становится ясным, что эта технология представляет собой значимый шаг в современной организации информационных систем. Глава обзорно рассмотрела ключевые компоненты и принципы, лежащие в основе концепции тонких клиентов, а также выявила их роль и важность в контексте сетевых инфраструктур. Определение тонких клиентов как технологии, где вычислительные ресурсы централизованы, интерфейсом, позволяет а клиентские подчеркнуть их устройства служат лишь основные преимущества: уменьшение нагрузки на клиентские устройства, централизованный контроль и управление, а также повышение безопасности данных. Одним из ключевых моментов главы стало рассмотрение клиентсерверной архитектуры в контексте тонких клиентов. Этот подход обеспечивает эффективное взаимодействие между центральным сервером и клиентскими устройствами, позволяя централизованно управлять ресурсами и обеспечивая стабильную работу всей системы. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 19 Итак, результаты анализа теоретических аспектов подтверждают, что тонкие клиенты современных представляют предприятий. Их собой перспективное внедрение обещает решение для улучшение производительности, уменьшение затрат на обслуживание и повышение уровня безопасности информационных ресурсов. Однако, несмотря на многие преимущества, необходимо учитывать потенциальные проблемы и тщательно планировать процесс внедрения, чтобы максимально эффективно воспользоваться возможностями технологии тонких клиентов в компьютерной сети. ТЕОРЕТИЧЕСКАЯ ОСНОВА ИССЛЕДОВАНИЯ Изм. Лист № докум. Подпись Дата Лист 20 Организация тонких (терминальных) клиентов в ИП Коровянских 2 Екатерина Олеговна Выбор программного обеспечения 2.1. Для построения решения по переходу на тонкие клиенты необходим сервер, который может обеспечивать оптимальную работу для пользователя. Терминальный сервер — чисто технически, представляет собой очень высокопроизводительный компьютер, который соединен по сети с тонкими клиентами. Для оптимального выбора терминального сервера, необходимо учитывать количество пользователей. В примере берется 10 пользователей, в качестве устройств берутся тонкие клиенты, на которых будут выполняться различного рода задачи, нам понадобиться один сервер, который сможет обрабатывать 10 подключений. Тонкие клиенты не будут иметь своего жесткого или SSD диска и все действия в том числе и загрузка ОС, будут выполнятся по сети. Для организации терминального сервера был выбран HPE PROLIANT DL360 GEN9 8SFF с данными техническими характеристиками представленные в таблице 1. Таблица 1 – Технические характеристики Процессор Intel Xeon E5-2620v3 2.40GHz 6 Core 85W TDP Оперативная память 4 шт. / 128 GB32GB PC4-17000 2133MHz ECC Reg Жесткий диск HDD 1.2TB SAS 10K 2.5 12Gb/s с салазкой (USED) 2 шт. Сетевая карта HP Ethernet 1Gb 4-port 331i Adapter Блок питания Мощность: 330W / 500WКомплект блоков питания (2 шт) HPE 500W РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 21 (Gen9) Операционная система Windows Server Standard 2016 Стоимость данного решения 150 000 рублей. В качестве тонких клиентов будут использованы уже имеющиеся компьютеры, но без жестких дисков. В качестве операционной системы для загрузки будет использован дистрибутив Linux «Thinstation». Этот небольшой, но обладающий множеством возможностей дистрибутив, позволяет превратить практически любые компьютеры в тонкие клиенты. Минимальные требования к аппаратной части— это Pentium 100Mhz и 16Mb оперативной памяти. Thinstation базируется на Linux, для его работы достаточно в своей сети поднять dhcp и tftp сервера и соответствующим образом их настроить (оба этих сервера есть и в составе продуктов Windows Server). Thinstation умеет работать со следующими серверами терминалов: - Сервера Microsoft Windows по протоколу RDP или через nxclient (Windows NT4TSE, W2k Server, W2k3 Server или же Windows XP в однопользовательском режиме); - Citrix servers по протоколу ICA (на серверах MS Windows, SUN Solaris и IBM AIX); - Сервера Tarantella - *nix-like сервера по протоколу X11; - подключение к VNC-серверам (tightVNC); - подключение к SSH и Telnet серверам. Для того, чтобы загрузить Thinstation по сети, от компьютера требуется лишь встроенная или внешняя сетевая карта, поддерживающая стандарт PXE. PXE расшифровывается как Pre-boot eXecution Environment — среда пред загрузочного выполнения. Этот стандарт был впервые реализован компанией Intel. РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 22 А сейчас вкратце рассмотрим процесс загрузки клиента Thinstation по сети. Сетевая карта по протоколу PXE запрашивает DHCP сервер - следующую информацию: IP адрес, маску подсети, шлюз, а также IP-адрес сервера TFTP (на котором лежат образы, в данном случае, ThinStation) и имя образа, которое она попытается загрузить. DHCP сервер возвращает запрашиваемую информацию (помечая - у себя, что выданный клиенту IP адрес — занят таким-то клиентом) Клиент подключается к TFTP серверу, IP-адрес которого ему - только что сообщили и скачивает с него файл загрузчика PXE (имя которого ему опять таки сообщил DHCP-сервер) Скаченный PXE загрузчик исполняется и, в свою очередь - скачивает с TFTP сервера конфигурационный файл, в котором прописаны имена файлов ядра ОС Linux — vmlinuz и образа файловой системы — initrd. Эти файлы скачиваются и управления передается ядру Linux После распаковки и загрузки ядра Linux с подмонтированным - образом файловой системы, Thinstation снова обращается к TFTP серверу для скачивания необходимых ему конфигурационных файлов (там, среди прочего, записаны адреса терминальных серверов, к которым нужно подключаться), после чего запускает нужный терминальный клиент (в нашем случае это будет rdesktop) и ожидает от пользователя ввода его логина с паролем. 2.2. Установка и настройка программного обеспечения для реализации тонких клиентов в сети. Сначала установим и настроим наш сервер Windows 2016 Standart. Установка операционной системы стандартная поэтому перейдем сразу к настройке ролей для удаленного подключения. РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 23 Для автоматического назначения IP адресации нашим тонким клиентам установим и настроим службу DHCP на нашем сервере управления. Устанавливаем роль DHCP Server через оснастку Server Manager. После установки роли откроем оснастку Server Manager и запустим мастер PostDeployment Configuration, после завершения которого роль сервера DHCP может считаться развёрнутой (Рисунок 1). Рисунок 1 – Установка DHCP сервера В нашем примере сервер DHCP разворачивается на компьютере, не являющемся членом домена, поэтому с авторизацией (активацией) службы DHCP не возникнет проблем – сразу после развёртывания сервер будет готов к работе. Создадим для тонких клиентов область с пулом выдаваемых IP адресов и активируем её: (Рисунок 2). Рисунок 2 – Активация области адресов РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 24 В оснастке управления правилами Windows Firewall проверяем правила относящиеся к серверу DHCP (как минимум нужно разрешить входящие подключения по протоколу UDP на порты 67/68). Роли Windows Deployment Services и Web Server понадобятся нам для возможности раздачи по сети (PXE) загружаемых образов Thinstation тонким клиентам по протоколам TFTP/HTTP. Устанавливаем роли, так же через Server Manager. Откроем консоль WDS и первым делом вызовем мастер конфигурирования сервера Configure Server (Рисунок 3). Рисунок 3 – Вызов мастера конфигурации На первом шаге мастер ознакомит нас с требованиями необходимыми для работы WDS. Первым пунктом идёт информация о том, что сервер может быть сконфигурирован как с поддержкой доменной инфраструктуры, так и в изолированном варианте (Рисунок 4). Службу сервера DHCP мы уже развернули. В процессе конфигурации WDS будет включена специальная опция DHCP сервера для поддержки PXEклиентов. Отдельный NTFS-раздел для хранения загрузочных образов сделан на нашем WDS-сервере (далее в примерах будет фигурировать как диск D:\). РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 25 Рисунок 4 – Окно мастера конфигурации На шаге выбора типа развёртывания WDS, согласно исходным условиям нашего примера, выбираем режим изолированного сервера Standalone server, если сервер находится в домене соответственно выбираем Integrated with Active Directory (Рисунок 5). Рисунок 5 – Выбор режима развертывания На шаге размещения каталога для файлов WDS и загрузочных образов по умолчанию предлагается каталог C:\RemoteInstall. В нашем примере путь изменён на диск D:\. РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 26 На следующем шаге мастер конфигурации, определив наличие на нашем сервере службы DHCP-сервера, предложит настроить параметры взаимодействия с этой службой. А именно, нам потребуется включить запрет прослушивания портов DHCP службой WDS и разрешить конфигурирование опций DHCP-сервера для поддержки PXE-клиентов (Рисунок 6). Рисунок 6 – Определение сервера DHCP На шаге настроек PXE по условиям нашей задачи разрешаем WDS серверу отвечать на запросы всех PXE-клиентов. По завершению работы мастера служба WDS будет запущена. В консоли WDS откроем свойства сервера и на закладке Boot отключим включенное по умолчанию требование нажатия F12 на стороне PXE-клиента для возможности загрузки по сети, выбрав опцию Always continue the PXE boot. Делается это для того что бы загрузка по сети происходила в автоматическом режиме. Теперь сделаем ряд действий по добавлению нашему WDS серверу поддержи SYSLINUX. SYSLINUX – это набор загрузчиков для систем Linux. Распакуем архив syslinux-6.03.zip и выполним следующие действия: - Скопируем в каталог D:\RemoteInstall\Boot\x64 на сервере WDS следующие файлы: \syslinux-6.03\bios\core\pxelinux.0 (переименовать в pxelinux.com) \syslinux-6.03\bios\com32\menu\vesamenu.c32 \syslinux-6.03\bios\com32\elflink\ldlinux\ldlinux.c32 РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 27 \syslinux-6.03\bios\com32\chain\chain.c32 \syslinux-6.03\bios\memdisk\memdisk Скопируем файл D:\RemoteInstall\Boot\x64\abortpxe.com в файл файл D:\RemoteInstall\Boot\x64\pxeboot.n12 в файл abortpxe.0. Скопируем pxeboot.0. Повторим действия, D:\RemoteInstall\Boot\x64 проделанные применительно для каталога к каталогу D:\RemoteInstall\Boot\x86 Создадим каталог D:\RemoteInstall\Boot\pxelinux.cfg (не файл, а именно каталог). В этом каталоге будут хранится конфигурационный файлы PXE, которые будет отдавать WDS-сервер PXE-клиентам. Создадим конфигурационный файл PXE "по умолчанию" с именем default в каталоге D:\RemoteInstall\Boot\pxelinux.cfg и добавим в него следующий контент (Рисунок 7): Рисунок 7 – Содержание файла pxelinux.cfg В командной строке с правами Администратора перейдём в каталог D:\RemoteInstall\Boot\x64 и создадим символическую ссылку (junction) на каталог D:\RemoteInstall\Boot\pxelinux.cfg: cd /d D:\RemoteInstall\Boot\x64 mklink /J pxelinux.cfg D:\RemoteInstall\Boot\pxelinux.cfg Повторим тоже самое для каталога D:\RemoteInstall\Boot\x86: cd /d D:\RemoteInstall\Boot\x86 mklink /J pxelinux.cfg D:\RemoteInstall\Boot\pxelinux.cfg РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 28 Создадим каталог D:\RemoteInstall\Images\Linux. В этом каталоге мы будем размещать загружаемые образы ОС тонких клиентов. В командной строке с правами Администратора перейдём в каталог D:\RemoteInstall\Boot\x64 и создадим символическую ссылку (junction) на каталог D:\RemoteInstall\Images\Linux: cd /d D:\RemoteInstall\Boot\x64 mklink /J Linux D:\RemoteInstall\Images\Linux cd /d D:\RemoteInstall\Boot\x86 mklink /J Linux D:\RemoteInstall\Images\Linux Для того, чтобы настроить WDS на использование добавленных нами загрузочных программ SYSLINUX (замена стандартного для WDS загрузчика pxeboot на pxelinux), выполним ряд команд с правами Администратора на сервере WDS (Рисунок 8): Рисунок 8 – Настройка использования загрузочных программ РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 29 2.2.1. Развертывание сборочной среды DevStation Для сборки собственных загрузочных образов проект Thinstation, в качестве одного из вариантов, предлагает использовать специальную загружаемую среду DevStation. Используя загрузочный дистрибутив DevStation, мы развернём выделенную Linux-систему, с помощью которой в дальнейшем будем собирать загрузочные образы Thinstation для конечных тонких клиентов. Прежде всего в DevStation будет сгенерирован специальный загрузочный образ Thinstation, с которого, в свою очередь, нужно будет загрузиться на всех используемых типах аппаратных конфигураций наших клиентов и сгенерировать профиль оборудования. На базе полученных профилей оборудования на нашем сервере DevStation будут скомпилированы конечные загрузочные сборки Thinstation под каждую аппаратную конфигурацию. Под задачу развёртывания DevStation можно использовать виртуальную машину. В сети можно найти примеры использования для этих целей виртуальных машин на базе VMWare и VirtualBox. В моём случае используются среды виртуализации VirtualBox (Рисунок 9). Созданная виртуальная машина имеет 2vCPU , 3GB ОЗУ, vHD 30GB (при меньшем размере диска, чем 30GB, DevStation может не установиться). Рисунок 9 – Установка вирутальной мащины РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 30 Процедура может занять некоторое время в зависимости от пропускной способности вашего Интернет-канала. 2.2.2. Сборка служебного образа ThinStation Подключаемся к консоли только что развёрнутой сборочной среды DevStation. Учётные данные при этом вводить не требуется, так как в системе настроен авто-вход. Пароль пользователя root на нашей виртуальной машине DevStation pleasechangeme. По умолчанию в DevStation включен Telnet-сервер и с этими учётными данными без проблем можно удалённо подключиться к системе. Итак, с рабочего стола графической среды DevStation запускаем ярлык (Рисунок 10). Рисунок 10 – Иконка запуска терминала В открывшейся консоли автоматически откроется файл справки README. Нажмём Q чтобы закрыть справочный файл и перейти в консоль. Сменим текущий каталог на /build. Здесь мы и будем выполнять практически всю работу – настройку конфигурации под наших клиентов и сборку образов для их загрузки. В первую очередь нас интересуют два основных файла build.conf и thinstation.conf.buildtime. Первый файл определяет порядок сборки образов Thinstation, то есть то, какие в образ будут включены драйверы для поддержки оборудования (например, поддержка определённых видеоадаптеров), какие РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата будут Лист 31 добавлены пакеты приложений сервисного уровня (например, поддержка NFS, NTP и т.п.) и прикладного уровня (например, наличие веб-браузера, RDP-клиента и т.д.) и ряд других параметров сборки. Второй файл добавляется в собираемый образ и в основном служит для передачи неких параметров/переменных, которые могут определять тот или иной порядок работы тонкого клиента и включённых в него приложений. На данном этапе перед нами стоит задача сборки служебного загрузочного образа Thinstation, который будет содержать в себе все драйверы, поддерживаемые средой Thinstation и с минимальными изменениями в файле build.conf. Этот служебный образ потребуется нам для того, чтобы на следующем этапе, загрузившись с него уже на конечных устройствах – тонких клиентах, выполнить процедуру генерации файлов профиля оборудования, которые в свою очередь будут использоваться для сборки конечных результативных образов тонких клиентов. Удалим имеющуюся символическую ссылку на конфигурационный файл build.conf и создадим новый файл на базе шаблона build.conf.example # rm build.conf # cp build.conf.example build.conf С помощью текстового редактора внесём минимальные корректировки в файл build.conf. Уберем комментарий в строке содержащей запись package extensions-x. Сохраним отредактированный файл build.conf и выполним команду сборки образа «./build –allmodules», включающего в себя все драйверы, которые поддерживает Thinstation. Процесс компиляции образа будет завершён созданием файла initrd размером около 175MB. Этот файл и содержит загружаемую ОС c ПО Thinstation для наших тонких клиентов. Нас интересуют два файла, появившихся после компиляции - initrd (Initial RAM Disk) и vmlinuz (Linux Kernel). РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 32 Файл vmlinuz служит для первичной загрузки и инициализации оборудования тонкого клиента, после чего начинается загрузка initrd. После завершения процесса компиляции оба эти файла можно найти в каталоге /thinstation/build/boot-images/pxe/boot/ (в консоли "Terminal Chroot" это каталог /build/boot-images/pxe/boot/). Нужно скопировать эти два файла на наш WDS-сервер в каталог D:\RemoteInstall\Images\Linux. Теперь на нашем Windows-сервере потребуется на время внести некоторые изменения: В оснастке управления сервером DHCP создадим резервирование IP для эталонной машины В оснастке управления сервером WDS отключим опцию интеграции с DHCP Чтобы заставить нашу эталонную машину тонкого клиента загружать образ по сети не с WDS сервера, а с машины DevStation, создадим на DHCPсервере резервирование IP адреса для эталонной машины с опциями 66 и 67 (Рисунок 11): 66 = <IP-адрес DevStation> 67 = boot/pxelinux/pxelinux.0 Рисунок 11 – Порядок загрузки по сети РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 33 Так, как мы планируем использовать PXE сервер с DevStation, то в нашей конфигурации потребуется на время отключить PXE сервер, встроенный в WDS, чтобы из опций DHCP-сервера исчезла опция 060 = PXEClient. Если этого не сделать, то WDS может передавать PXE-клиенту не тот адрес PXE-сервера, который нас интересует. Переходим на DevStation и разрешаем запись всем пользователям в корневой каталог встроенного TFTP сервера. Для этого можно либо выполнить консольную команду: chmod 777 /thinstation/build/boot-images/pxe Включаем эталонный компьютер. При старте клиент получит с DHCP зарезервированный нами IP-адрес с опциями, указывающими на PXE-сервер DevStation и начнёт оттуда загружать образ. На загруженном эталонном клиенте в графической оболочке открываем меню Applications > Utilities и выбираем Terminal Emulator. В окне терминала запускаем генерацию профиля оборудования с передачей на машину DevStation командой: # /bin/hwlister.sh. Перейдем в каталог /thinstation/build/boot-images/pxe на DevStation машине. Здесь появятся файлы, переданные с клиента (в зависимости от аппаратной конфигурации клиента): module.list, package.list, firmware.list. На DevStation создаём новый подкаталог для профиля клиента в каталоге /thinstation/build/machine/ (/build/machine/ в chroot-окружении) и переносим туда только что полученные с эталонного клиента list-файлы. Далее созданный профиль под названием HPt610 мы будем использовать при сборке конечного рабочего образа (будем указывать имя этого каталог в build.conf). РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 34 Туже самую процедуру создания нового профиля из list-файлов, попавших в каталог /thinstation/build/boot-images/pxe, можно сделать и с помощью графической оболочки DevStation. Для этого будет достаточно вызвать пункт меню Start> DevStation> Make Machine Profile и указать имя нового профиля. Отключаем право на запись в PXE-сервере DevStation через ранее упомянутый пункт меню Start> DevStation > Toggle PXE Read/Write. Возвращаемся на наш Windows-сервер и в консоли WDS не забываем обратно включить опцию поддержки интеграции PXE с DHCP (вторую галочку). А в консоли управления DHCP-сервером удаляем созданное ранее резервирование, которое мы делали под эталонного клиента. Следующим правим конфигурационный файл thinstation.conf.buildtime, Основную массу имеющихся в файле thinstation.conf.buildtime параметров можно оставить без изменений. Изменим и добавим лишь те параметры, которые относятся к специфике нашей задачи (Рисунок 12): Рисунок 12 – Конфигурация загрузки РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 35 Добавленными параметрами NET_FILE_* мы укажем на необходимость загрузки конфигурационных файлов Thinstation по сети по протоколу HTTP. конфигурационные Это позволит файлы нам разместить на thinstation.conf-<MAC>, веб-сервере настраивающие конкретных тонких клиентов, не меняя при этом настройки внутри раздаваемого образа. Далее мы рассмотрим пример такого файла. В параметрах SESSION_0_* вместо используемого по умолчанию графического оконного менеджера xfwm4 мы сразу будем вызывать RDPклиента freerdp. А общие для всех наших клиентов параметры подключения RDP-клиента к RDS-серверу (имя сервера, опции RDP-сессии) мы также вынесем в дальнейшем на веб-сервер в файл thinstation.conf.network. Его пример мы также рассмотрим далее. В перечисленных параметрах NET_* мы зададим те опции тонкого клиента, которые могут повлиять на корректность инициализации сети в загружаемой системе и успешность загрузки по сети, как таковую. Например, первая опция NET_USE=LAN задаёт приоритет использования проводных сетевых адаптеров перед беспроводными (может быть полезно, если тонкий клиент имеет и беспроводной и проводной адаптеры и один мешает загрузке другого). Опции задержки и таймаутов нужны для ожидания инициализации драйвера сетевого адаптера. На практике столкнулся с тем, что неуспевающий пройти инициализацию сетевой адаптер ломал загрузку по сети через HTTP. Так как на этапе сборки рабочего образа Thinstation мы включили опцию поддержки fastboot в build.conf, а в thinstation.conf.buildtime указали расположение веб-сервера Fast Boot, то теперь нам нужно разместить получившийся ранее Squash-файл на этом веб-сервере, чтобы в процессе загрузки основной "тяжёлой" части образа использовался не протокол TFTP а протокол HTTP. РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 36 В нашем случае в качестве веб-сервера выступает IIS, который мы уже развернули ранее вместе с WDS, поэтому выполним его настройку, например через IIS Manager. Нам нужно сделать две вещи. Включить поддержку нового MIME-типа .squash и убедиться в том, что к сайту разрешён анонимный доступ. В оснастке IIS Manager выберем сайт, в нашем случае это Default Web Site (Рисунок 13). В настройках сайта выберем пункт MIME Types и используя в меню Actions ссылку Add добавим новый MIME-тип: filename extension = .squash , MIME type = application/octet-stream. Рисунок 13 – Настройка IIS Если не выполнить данную настройку, то наш веб-сервер IIS приходящим к нему PXE-клиентам попросту не будет отдавать squash-файл, а будет возвращать ошибку доступа. Перейдём к разделу настроек сайта Authentication и убедимся в том, что включена анонимная аутентификация. Скопируем с DevStation появившийся после компиляции файл /thinstation/build/boot-images/pxe/boot/lib.squash в подкаталог ThinClients каталога, в котором размещена корневая папка сайта IIS (по умолчанию C:\Inetpub\wwwroot). Вспомним, что именно этот подкаталог веб-сервера мы РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 37 указывали в параметре basepath в файле build.conf перед компиляцией рабочего образа Thinstation. На веб-сервере в каталоге, где уже размещаются squash-файлы создадим общий для всех клиентов конфигурационный файл thinstation.conf.network (Рисунок 14): Рисунок 14 – Общий файл конфигурации Этот файл будет содержать общие для всех клиентов параметры работы ОС Thinstation (запуск оболочки в опциях SESSION_0_*) и адрес RDS-сервера (SESSION_0_FREERDP_SERVER). RECONNECT_PROMPT=FORCE, позволит автоматически Опция выполнять переподключение к RDS-серверу в случае попыток завершения сессии и/или проблем с временной недоступностью сервера. Перед тем, как выполнять проверочный запуск тонкого клиента, ещё раз проверим, какие файлы мы имеем для его автоматической загрузки и настройки, и где эти файлы расположены на нашем Windows-сервере управления. После компиляции рабочего образа Thinstation мы имеем три файла, которые распределены на сервере следующим образом: D:\RemoteInstall\Images\Linux\HP-t610\vmlinuz D:\RemoteInstall\Images\Linux\HP-t610\initrd C:\inetpub\wwwroot\ThinClients\HP-t610\lib.squash Файл настроек загрузки PXE-клиента: D:\RemoteInstall\Boot\pxelinux.cfg\ Конфигурационные файлы Thinstation: C:\inetpub\wwwroot\ThinClients\thinstation.conf.network РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 38 При запуске клиент с PXE-сервера получит по TFTP файлы vmlinuz и initrd, указанные в \pxelinux.cfg\ и загрузит их в память тонкого клиента. На следующем этапе с веб-сервера будет загружен файл lib.squash и произведено применение конфигурационных файлов thinstation.conf.network. И так мы произвели настройку и конфигурацию тонких клиентов для подключения к нашему терминальному серверу. Была создана эталонная конфигурация для загрузки образа, провел проверочный запуск тонкого клиента через локальную сеть по протоколу PXE. РЕАЛИЗАЦИЯ ТОНКИХ КЛИЕНТОВ Изм. Лист № докум. Подпись Дата Лист 39 Заключение В контексте современной динамичной информационной среды реализация тонких клиентов в компьютерной сети представляет собой актуальное и стратегически важное направление для организаций. Проанализировав теоретические аспекты, преимущества и ограничения, а также применение технологии в существующих сетевых средах, можно сделать несколько ключевых выводов. В сфере теоретических аспектов реализации тонких клиентов выявлены основные принципы и компоненты этой технологии. Определение тонких клиентов, клиент-серверная архитектура и влияние виртуализации рассмотрены в контексте их внедрения в компьютерные сети. Применение тонких клиентов в существующих сетях выявляет значительные преимущества клиентских устройств, данной технологии. Экономия централизованное управление и ресурсов повышенная безопасность данных являются ключевыми достоинствами. Однако, следует учитывать зависимость от качества сетевой инфраструктуры и возможные проблемы с локальными приложениями. В заключении хочется подчеркнуть, что реализация тонких клиентов предоставляет компаниям эффективный инструмент для оптимизации рабочих процессов. Экономия затрат, упрощенное управление и повышенный уровень безопасности создают благоприятное окружение для успешного функционирования организации. Однако, успешное внедрение технологии тонких клиентов требует внимательного планирования, инфраструктуры, а предприятия. учетом С также учета адаптации выявленных особенностей под существующей конкретные преимуществ и потребности ограничений, необходимо балансировать технологические выгоды с возможными рисками и затратами. ЗАКЛЮЧЕНИЕ Изм. Лист № докум. Подпись Дата Лист 40 В целом, реализация тонких клиентов в компьютерной сети представляет собой перспективное решение для современных организаций, что позволило повысить эффективность работы, снизить затраты и обеспечить высокий уровень безопасности информационных ресурсов. Сократились расходы на приобретение новых компьютеров, так как все вычисления выполняются на сервере, а не рабочей машине сотрудника. ЗАКЛЮЧЕНИЕ Изм. Лист № докум. Подпись Дата Лист 41 Список использованных источников 1. Боброва И. И. Тонкие клиенты в сети: перспективы применения / И. И. Боброва // Сетевые технологии. — 2020. — № 8. — С. 45-56. 2. Иванов П. Н. Интеграция тонких клиентов в корпоративные сети: преимущества и риски / Иванов П. Н. // Вестник Информационных Технологий. — 2021. — № 12. — С. 78-89. 3. Смирнов А. А. Развитие клиент-серверных систем на основе тонких клиентов / Смирнов А. А. // Информационные технологии в бизнесе. — 2021. — № 6. — С. 112-125. 4. Громов С. В. Технологии тонких клиентов: особенности реализации в условиях современных предприятий / Громов С. В. // Компьютерные системы и сети. — 2021. — № 9. — С. 34-45. 5. Казаков В. П. Внедрение тонких клиентов в образовательные учреждения: опыт и перспективы / Казаков В. П. // Образование и информационные технологии. — 2020. — № 7. — С. 56-67. 6. Новикова Е. С. Современные тенденции в использовании тонких клиентов в бизнесе / Новикова Е. С. // Экономика и управление. — 2021. — № 4. — С. 89-101. 7. Попов А. И. Тонкие клиенты в системах государственного управления: опыт внедрения / Попов А. И. // Государственное управление и информационные технологии. — 2020. — № 5. — С. 120-133. 8. Рыбкин А. В. Тонкие клиенты в медицинских информационных системах: применение и перспективы / Рыбкин А. В. // Медицинская информатика. — 2021. — № 11. — С. 67-78. СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ Изм. Лист № докум. Подпись Дата Лист 42 9. Соколова Н. С. Технология тонких клиентов: применение в банковском секторе. / Соколова Н. С. // Банковское дело и финансы. — 2020. — № 8. — С. 45-56. 10. Хлопонин Д. В. Эффективность использования тонких клиентов в системах дистанционного обучения / Хлопонин Д. В. // Информационные технологии в образовании. — 2021. — № 10. — С. 112-125. 11. Кузнецов Е. В. Интеграция тонких клиентов в корпоративные сети: опыт предприятий России / Кузнецов Е. В. // Корпоративные информационные системы. — 2020. — № 6. — С. 78-89. 12. Васильева Л. М Сравнительный анализ тонких и толстых клиентов в современных информационных системах / Васильева Л. М // Информационные технологии и вычислительные системы. — 2021. — № 9. — С. 34-45. 13. Прохоров Г. С. Развитие клиент-серверных систем на основе тонких клиентов / Прохоров Г. С. // Корпоративные технологии. — 2020. — № 7. — С. 56-67. 14. Дмитриев А. А. Проблемы и перспективы внедрения тонких клиентов в государственных учреждениях / Дмитриев, А. А. // Вестник общественных наук. — 2021. — № 3. — С. 89-101. 15. Горбунов В. В. Технологии тонких клиентов: опыт применения в образовательных учреждениях / Горбунов В. В. // Инновации в образовании. — 2020. — № 9. — С. 34-45. 16. Беляков П. С. Тонкие клиенты: применение в системах здравоохранения / Беляков П. С. // Здравоохранение и информационные технологии. — 2021. — № 11. — С. 67-78. СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ Изм. Лист № докум. Подпись Дата Лист 43 17. Шарипова Н. Г. Современные тенденции в использовании тонких клиентов в банковском секторе / Шарипова Н. Г. // Банковское дело и информационные технологии. — 2020. — № 8. — С. 45-56. 18. Сухарев А. А. Эффективность технологии тонких клиентов в системах медицинского обслуживания / Сухарев А. А. // Медицинская информатика. — 2021. — № 11. — С. 67-78. 19. Кузьмин С. Н. Тонкие клиенты в бизнес-процессах: практика применения / Кузьмин С. Н. // Корпоративные технологии. — 2020. — № 7. — С. 56-67. 20. Максимов В. П. Применение тонких клиентов в образовательных организациях: опыт и перспективы / Максимов В. П. // Информационные технологии в образовании. — 2021. — № 10. — С. 112-125. 21. Лебедева Е. А. Инновационные технологии тонких клиентов: влияние на банковскую сферу / Лебедева Е. А. // Экономика и управление. — 2022. — № 3. — С. 89-101. 22. Головачева М. В. Тонкие клиенты в системах государственного управления: проблемы и перспективы / Головачева М. В. // Государственное управление и информационные технологии. — 2021. — № 5. — С. 120-133. 23. Красильникова Н. И. Тонкие клиенты в системах здравоохранения: особенности и перспективы / Красильникова Н. И. // Здравоохранение и информационные технологии. — 2020. — № 11. — С. 67-78. 24. Петрова А. С. Интеграция тонких клиентов в корпоративные структуры: проблемы и пути решения / Петрова А. С. // Корпоративные информационные системы. — 2020. — № 6. — С. 78-89. СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ Изм. Лист № докум. Подпись Дата Лист 44
