Полезная практика
Содержание
- Полезная практика
- Малый и средний бизнес
- Массивные вычисления и обработка результатов в реальном времени
- Предоставление вычислительных мощностей
- Коллективное использование дорогостоящего оборудования и ПО
- Масштабируемые хранилища с настройкой под персональные нужды
- Работа с большими данными в реальном времени
- Настройка стека ПО
- Предоставление ресурсов и служб на продажу
- Единые управление, контроль и диспетчеризация
Сегодня облачные решения для малого и среднего бизнеса уже не находятся далеко "в облаках". Вы можете самостоятельно строить полноценные SD DC и дома, и в маленьком офисе из двух- трёх сотрудников. Тем более, что волка ноги кормят и вам постоянно приходится перемещаться, а не всегда всё что нужно оказывается под рукой в ноутбуке. Да канал в 1- 2 Мегабита в секунду уже давно доступен, в общем- то уже и десятком Mbps не удивишь. А аппаратные средства тоже уменьшились в размерах при своём развитии, и программное обеспечение с открытым исходным кодом стало надёжнее, а Microsoft выпустил Windows Server 2016, который может делать большую часть того, для чего раньше требовались VMware/ Citrix, а Hyper-V вообще свободно доступен!
Исходные данные: небольшая частная клиника на 10- 20 человек персонала с очень ограниченным бюджетом.
Решение: один сервер на базе двухпроцессорной платформы с одним процессором стоимостью около 150 тыс. руб. и Windows Server 2012R2, плюс 20 штук неттопов около 12 тыс. руб. каждый с RDP терминалом на базе Linux, с пробросом USB в обе стороны, и один из неттопов в качестве резервного сервера Active Directory. Ко всеобщему удовольствию. В сравнении с обычными настольными компьютерами основная экономия осуществляется за счёт затрат на программные средства. При этом, применяя свободно доступные на рынке неттопы вместо проприетарных терминальных станций мы оставили заказчику возможность превращения имеющегося у него терминала в полноценную рабочую станцию. По началу были проблемы с подключением локальных портов USB к терминалам. Однако, после решения этой проблемы часть пользователей попросила оставить свои USB ключи в сервере. Это объясняет сказанную ранее фразу о пробросе USB в обе стороны. Пока хватает одного процессора.
Совместное применение решений PLM уровня Siemens PLM - MOM / Dassault Systèmes Catia
По самой своей природе решения управления жизненным циклом изделий промышленных предприятий и их производством предполагают динамичность и подвижность как самого решения, так и его персонала. Одно и то же сложное изделие может проходить разные стадии проектирования, разработки, производства и сопровождения в существенно распределённых географических местоположениях. В свою очередь их комплектование из составляющих частей также сопровождается сложной логистикой. Габаритные размеры современных изделий зачастую предполагают решение сложных инженерных задач, причём порой прямо на площадке их текущего расположения. Существенная трёхмерность данных изделий требует для осуществления всего цикла разработки, производства и сопровождения применения рабочих мест, которые позволяют работать со сложными объёмными продуктами в реальном масштабе времени. А наложение временной шкалы на весь процесс обязывает к точному соблюдению последовательностей операций и аккуратному выполнению предписанных инструкций и регламентов. Сложной задачей также является согласованная поддержка всей сопроводительной технической документации для большого по числу участников и к тому же распределённого работающего с ней персонала с чётким соблюдением полномочий каждого участника процесса. Необходимость внесения необходимых изменений "на лету" при соблюдении необходимой конфиденциальности данных и авторизации осуществляющего эту работу персонала вносит дополнительные сложности. Современные методы централизованных хранения всех данных и их обработки позволяют решать все эти задачи, осуществляя их в специально предназначенном для этого центре обработки данных или даже в согласованно функционирующих нескольких распределённых ЦОД.
На приведённой выше схеме отображается пример реализации частного облачного решения подобной задачи. Такие решения предполагают возможность создания отказоустойчивого единого центра обработки информации, обладающего необходимым заказчику числом девяток в показателе высокой доступности. При этом реализуется строгая централизованная система управления списками прав доступа ко всем предоставляемым данным и ресурсам. Применение современных решений обработки графических данных позволяет предоставлять удалённому клиенту отображение данных и работу в режиме реального времени практически с любого оконечного (терминального) устройства в диапазоне от рабочих станций и ноутбуков вплоть до смартфонов и планшетных устройств. При этом начальным требованием для канала связи является полоса пропускания, начинающаяся со значений в 1-2 мегабита в секунду для видеорежимов с разрешающей способностью вплоть до 4k. И это на сегодняшний день вполне приемлемое условие.
Данные технологии удалённой работы со сложными трёхмерными объектами предполагает применение достаточно дорогостоящего оборудования Nvidia® Tesla/ Grid, AMD® FirePro™/ MxGPU и Intel® GVT-g. Хорошей новостью является возможность совместного использования как самого подобного оборудования, так и программных средств. Аппаратные средства графического процессинга могут выделяться для коллективного использования различными способами и их реализация осуществляется на основании анализа решаемых задач и применяемых программных средств.
В случае решения сложных вычислительных задач и осуществления окончательной прорисовке объектов (рендеринга) может осуществляться выделение такого графического процессора целиком (а при наличии необходимости и сразу нескольких устройств), причём современные технологии позволяют осуществлять прямой проброс (pass-trough) таких аппаратных средств напрямую в использующее их приложение и/ или виртуальную машину сводя до минимума в несколько процентов потери в эффективности их использования в сравнении с применявшимся ранее вариантом использования таких устройств, находившихся в распоряжении гипервизора.
В случае решения менее сложных задач по отображению уже скомпонованных изображений допускается одновременное совместное использование одного устройства графического процессинга большим числом пользователей (до 16-32 на момент написания). Такая работа может быть реализована как за счёт разделения ресурсов единого, находящегося в распоряжении гипервизора драйвера, так и путём предоставления индивидуальных драйверов виртуальных устройств графического процессинга, реализующих в себе лишь часть аппаратных средств общего устройства.
Стоит также отметить и значение обсуждаемых графических средств в решении задач упаковки и шифрации передаваемых данных (например, в виде протоколов H.264/ H.265), которые в совокупности с согласованно выбираемыми сетевыми средствами позволяют решать задачи уплотнения на порядки гигантских обменов данных, сопровождающих удалённую работу со сложными трёхмерными объектами в реальном режиме времени больших коллективов пользователей.
В свою очередь, решения удалённого графического доступа предлагают два основных класса возможных решений: первый, наиболее традиционный, предполагает возможности полноценного удалённого рабочего места, являющегося эмуляцией привычной пользователю обстановки его персональной рабочей станции. Здесь с точки зрения новаций, разве что, стоит отметить возможность удалённым клиентам Windows Server 2016, наконец- то, получить права администратора для хоста своего персонального сеанса.
Вторым вариантом является веб публикация исключительно самого программного средства, что существенно снижает общую нагрузку на имеющиеся ресурсы и делает возможной более динамичную и более гибкую организацию процессов обработки. При данном методе доступа к приложению следует уделять пристальное внимание правильной организации прав доступа и авторизации в системе, а также организации политик и доверительных отношений. Рекомендуем придерживаться предварительной аутентификации и воздерживаться от проброса доступа для авторизации приложением. Для данного варианта реализации удалённого доступа более естественным является применение совместимых с HTML-5 браузеров, хотя метод доступа через такой браузер начинает широко применяться и для доступа к удалённым рабочим местам.
В зависимости от решаемых вами задач, мы предлагаем системную интеграцию на основе следующих представленных в настоящее время на рынке наиболее развитых средств удалённого графического доступа:
-
DCV (Nice s.r.l./ Adaptive Computing)
-
Horizon7 (VMware)
-
HDX™ XenDesktop/ XenApp (Citrix)
Обращаем внимание на интересную новацию rCUDA испанских коллег в области HPC.
-
Windows Server 2016 (Microsoft)
-
HDP™ FusionAccess (Huawei)
-
KVM (Red Hat) также готовит своё решение для данной отрасли, пока довольствуемся текущим состоянием VNC.
На схемах ниже иллюстрируются реализации Nvidia® Grid и AMD® MxGPU на примере решения VMware:
|
|
Для сопровождения регламентных работ и планов- графиков предлагаем вам совместно разработанные с их производителем оконечные устройства под ваши конкретные задачи. Данные терминалы позволяют гарантировать достоверность и своевременность проводимых персоналом операций. Такие гарантии осуществляются за счёт закрытия доступа к установленным на данных терминальных устройствах персоналу, который не имеет на то полномочий. Широкие возможности представленных сегодня на рынке подобных гаджетов простираются от геолокации и временной синхронизации вплоть до индикации RFID и штрих-кодами, а также осуществления некоторых измерений и регистрационных записей. Отметим, что современные RFID- метки способны хранить в себе не стираемой информацию о жизненном цикле данной детали в объёмах, достигающих мегабайтов. При этом они обладают широчайшим температурным рабочим диапазоном и способностью устойчивости к агрессивным внешним средам. Пакетный режим доступа позволяет осуществлять их считывание на больших скоростях по отношению к соответствующему устройству. В случае необходимости выполнение сопроводительных работ может фиксироваться видео- и фото- съёмкой с привязкой к геолокации, а отсутствие у персонала доступа к программному обеспечению гарантирует синхронизацию временных меток.
Организация обработки больших данных в оперативной памяти
Вынесенная в подзаголовок задача решается совместной реализацией следующих мероприятий:
-
Организация максимально возможного объёма оперативной памяти: порой этого может быть вполне достаточно: приложение просто считывает все имеющиеся данные в оперативную память и дальше выполняет операции обмена с дисковыми хранилищами только для синхронизации изменений с их постоянно хранящейся копией. Современные системы делают возможным наличие в одной системе от Терабайтов до десятков и даже сотен и тысяч терабайт реально установленной оперативной памяти. Основная проблема- стоимость таких систем. В качестве варианта реализации общего адресного пространства у нас имеется опыт его организации поверх нескольких соединённых высокоскоростным интерконнектом систем, что может существенно снизить общую стоимость решения, но оставляет открытой проблему различий латентности имеющихся доменов адресного пространства.
-
Кэширование данных: если объёма оперативной памяти начинает не хватать, система должна принимать решение и оставлять в оперативной памяти только часто используемые данные, своевременно выполняя сброс не актуальных данных. Некоторое понимание об организации такого рода решений можно почерпнуть, например в Главе 7, Кэширование нашего перевода книги "ZFS для профессионалов", Майкл В. Лукас и Аллан Джуд, апрель 2016, или в переводе Главы 8, Множество уровней в Ceph "Полного руководства Ceph", Ник Фиск, Packt Publishing, май 2015.
-
Репликация данных: позволяет решать проблемы синхронизации данных в различных узлах системы в случае, когда объём поступающих запросов на обработку данных настолько велик, что одна система не в состоянии справляться с ним, либо сама обработка требует очень большого объёма вычислительных ресурсов и при наличии даже небольшого числа такого рода запросов требуется множество систем для их обработки в реальном масштабе времени. Проблема поддержания множества копий данных в непротиворечивом состоянии во многом определяется самой природой этих данных и решается либо средствами самой системы обработки данных, которые имеются, например, в большинстве современных систем баз данных, так и средствами систем хранения. В качестве примера реализаций с открытым исходным кодом последнего подхода можно привести современные решения Ceph, например см. Главу 3, BlueStore и Главу 5, Разработка при помощи librados нашего перевода "Полного руководства Ceph", Ник Фиск, Packt Publishing, май 2015. На более низком уровне рекомендуем обратить внимание не реализацию системы асинхронного обмена сообщениями, реализуемую на основе механизма Linix API epoll. Механизмы синхронизации данных имеются также и в последних версиях ZFS, подробнее в уже отмеченном нашем переводе "ZFS для профессионалов" и реализации Proxmox 5.
Мы готовы оказывать консультационные услуги вплоть до полной реализации необходимых вам систем.
Организация обработки больших данных по месту их хранения
Допустим, вы решили проблемы предыдущего раздела и реализовали обработку больших объёмов данных в оперативной памяти в реальном масштабе времени. Порой, сами масштабы хранимых данных начинают влиять на характер такого рода обработки в силу необходимости перемещения оченьнь больших объёмов данных между различными сисемами в вашем центре (центрах) обработки данных.
Если мы имеем необходимость синхроннихации данных, хранимых в различных географических местоположениях, то на помощь нам приходят, как уже отмечалось, Удалённая репликация и Федерализация данных. Даже Microsoft Windows в своих последних версих поддерживает Распределённую файловую систему и её репликации, причём стоит отметить разнесение задач синхронизации пространства имён и собственно данных.
Однако, порой и этого недостаточно. Допустим, вы храните в одном ЦОД гигантские объёмы данных, поступающие в реальном режиме времени. Например, наблюдения с телескопа электронного микроскопа, или из CERN. Эти данные хранятся в различных узлах вашего ЦОД. Их перемещение на специально предназначенные для обработки вычислительные узлы может само по себе требовать очень существенных временных затрат, которые создают проблемы для обработки в реальном масштабе времени или просто чрезмерно большие нагрузки на имеющуюся сеть интерконнекта, даже несмотря на присутствующие в наши дни каналы связи с пропускной способностью в сотни Гигабит в секунду. В этом случае может оказаться полезной предварительная обработка данных в самих узлах хранения.
Мы готовы оказывать содействие в реализации систем подобной разработки как средствами и инструментарием самих систем хранения (например: Распределённые вычисления при помощи классов RADOS Ceph), так и с помощью уже упомянутой выше технологии системы асинхронного обмена сообщениями, реализуемой на основе Linix API epoll.
API epoll позволяет выполнять обработку очень больших количеств файлов (измеряемых сотнями тысяч и более) с временными затратами, находящимися в линейной зависимости только от количества файлов, удовлетворяющих необходимым параметрам, позволяя не нести накладные расходы для файлов, не удовлетворяющих выбранным критериям и/ или не готовых к обработке файлов.
Авторизация пользователей и устройств и списки управления доступом
Для описания структуры любой организации испокон веков используется некая система иерархий. Как правило, такая система имеет древовидную структуру, произрастающую из общего корня с последующим ветвлением. В ИТ индустрии данная структура именуется каталогом и имеется стандарт X.500, описывающий протокол доступа к каталогу (Directory Access Protocol, DAP). По мере широкого распространения протокола TCP/IP и занятия им доминирующей роли в сетевой среде, был принят упрощённый стандарт DAP, LDAP (Lightweight Directory Access Protocol). Примерами его реализации могут служить Microsoft’s Active Directory (AD), Red Hat’s Directory Services, Oracle Directory Server Enterprise Edition, а также OpenLDAP. С подробностями организации и реализации данного протокола можно ознакомиться, например, в Главе 16, Службы каталога нашего перевода 2го издания книги Денниса Мэйтоутека, Джеймса Тарнбула и Питера Лайевердинка "Администрирование Linux систем для профессионалов". Для осуществления авторизации имеющихся в организации пользователей и устройств мы придерживаемся применения именно LDAP систем.
Следующим существенным соглашением является тот факт, что все объектам в системе приводятся в соответствие их списки управления доступом (ACL, Access Control List), регламентирующие полномочия. С деталями организации ACL также можно ознакомиться в указанной выше главе.
Различия в реализации служб LDAP начинаются с организации взаимодействия компонентов каталогов. Microsoft AD, к примеру, имеет четыре ключевых компоненты: Подразделения (OU), Домены, Деревья доменов и Леса. Для установления доверительных отношений между различными субъектами в среде имеется служба федерации (AD FS). Хорошей новостью является тот факт, что Windows Server 2016 является совместимым с каталогами сторонних разработчиков LDAP, начиная с v3. В качестве обратной совместимости из сред Linux в сторону Microsoft можем рекомендовать, например, FreeIPA. Желающим иметь свой контроллер AD с открытым исходным кодом можем порекомендовать Zential (Книга 4 в нашем переводе альбома Ли Р. Сюрбера).
В качестве практического примера приведём мысленный эксперимент из материалов по подготовке к экзамену 70-743: Вы являетесь системным администратором в Wingtip Toys, организации с 16ю офисами по всему миру, а также дополнительно с 45 магазинами, которые специализируются на высокопроизводительных квадрокоптерах и дронах. Ваша команда является относительно новой организацией, наследующей некий единственный домен с 72 Контроллерами домена. Отдельный физически записываемый Контроллер домена представлен в каждом розничном магазине, причём в каждом из офисов имеется смесь из 1 - 2 контроллеров. Все контроллеры работают под управлением Windows Server 2008 R2, причём ему соответствует установленный уровень функционирования домена. Всё имеющееся в этих Контроллерах домена оборудования вырабатывает свой поддерживаемый ресурс в последующие шесть месяцев. Ваша команда корпоративных приложений также заинтересована в интеграции AD DS с их развёрнутым в общедоступную сторону веб порталом розничных продаж. Ваш менеджер добавил некое обновление контроллера домена в общий годовой бюджет. При подготовке к этой работе он запросил ответы на следующие вопросы:
1. Имеются вопросы по ограничению физической безопасности в каждом магазине розничной торговли. Что вы рекомендуете для расширения логической безопасности Контроллеров домена в этих подразделениях?
Ответ: Реализация RODC в магазинах розничной торговли поможет ограничить потенциал злонамеренной активности в случае компрометации имеющегося локального Контроллера домена.
2. Системное сопровождение для всех розничных магазинов может осуществляться только по прошествии часов, причём критически важно чтобы все системы находились в рабочем состоянии перед открытием магазинов. Какие у вас имеются рекомендации по развёртыванию таких новых контроллеров в столь ограниченных временных рамках?
Ответ: Использование IFM для развёртывания таких новых контроллеров позволит вашей команде быстро развёртывать новые серверы, а также существенно снижает перегруженность репликациями во множестве соединений WAN.
3. Не все основные офисы работают с состоятельным общим числом Контроллеров домена в каждом из местоположений. Что вы посоветуете для улучшения такой топологии?
Ответ: Для улучшения надёжности и резервирования каждый офис должен применять два Контроллера домена. В тех офисах, которые содержат только один сервер, следует развернуть новые серверы.
4. Какой тип установки вы рекомендуете для развёрнутого в общедоступную сторону веб портала розничной торговли?
Ответ: Для имеющегося веб портала установка Сервера ядра для размещения его Контроллера домена улучшит безопасность и ограничит время простоя при накатывании исправления благодаря уменьшению общего числа исправлений, вызванных безопасностью.
Организация аутентификации очень большого числа абонентов
Для начала рекомендуется поработать с установленными по умолчанию значениями настроек AD или другой применяемой вами системы управления LDAP. Например, так для контроллера AD Windows Server 2016.
Далее есть варианты представления (Proxy) данных контроллера домена в оперативной памяти и настройки множества хозяев (Master) контроллера домена и политик их синхронизации.
В случае существенно распределённых географически контроллеров каталогов и ограниченной пропускной способности каналов между ними (или их большой численности), во избежание создание ситуаций сетевого шторма рекомендуются специализированные протоколы репликации данных между контроллерами.