Назад | Перейти на главную страницу

Проблемы безопасности для высокопроизводительных кластеров

Это ОЧЕНЬ открытый вопрос, поскольку я впервые создаю кластер. Мне просто интересно, какие будут проблемы безопасности и как их предотвратить.

Исходная информация

Использование SGE (в настоящее время устанавливается и выясняется, какое расписание является лучшим) на внутреннем кластере.

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

Будет внешний узел, который подключается к кластеру, и этот узел будет отправлять задания, полученные из Интернета / сервера.

Все пользователи должны отправить свой запрос на выполнение задания через Интернет на сервер (пытаясь придумать способы не позволить им обойти это при локальном подключении).

Цели этого проекта:

В конечном итоге разрешите людям через Интернет из любого места отправлять задания для запуска, а затем получать уведомления, когда программа будет завершена. Кроме того, разрешите им просматривать данные, возможно, даже загружать данные для просмотра в автономном режиме.

Маловероятно, но возможно: возможно, даже разрешить пользователям загружать программы для точной настройки своих данных, когда нашей программы недостаточно.

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

Основная работа по обеспечению безопасности должна выполняться на узле входа / портала с должным образом задокументированными и определенными интерфейсами, чтобы люди могли делать то, что они собирались делать там. Есть такие вещи, как передача данных Globus Toolkit по протоколу grid-ftp по SSH или с полноценной PKI.

Или вы также можете подготовить веб-портал, который, в свою очередь, использует API DRMAA для отправки заданий из python, ruby, java и т. Д. И предлагает способы и средства для загрузки / скачивания программ или данных из системы.

Обычно безопасность не является большой проблемой для большинства установок HPC, и обычные принципы многопользовательской безопасности UNIX применяются полностью. Распределенное управление ресурсами даже помогает защитить вас от злоупотребления ресурсами и тому подобного.

Что касается части проблемы, связанной с просмотром данных: я обычно реализую пару узлов рабочего стола, которые зарезервированы для интерактивной работы, такой как разработка и отладка. В большинстве случаев они также содержат графические процессоры, и я настраиваю TruboVNC + VirtualGL, чтобы люди могли просматривать свои данные локально, прежде чем они начнут длительную передачу в другие хранилища и / или свои рабочие столы (они отправляют сеансы рабочего стола VNC в SGE). Помогает им оставаться локально в кластере, а VNC при правильной настройке обеспечивает очень высокую скорость работы с 3D-визуализацией с ускорением hw даже по каналам типа WAN. Вы также можете встроить (более медленную) программу просмотра VNC в свой веб-портал.

Мы сделали служебный сценарий, который запускается два раза в час и убивает все задания, о которых SGE не знает. Это хорошо работает и очищает процессы, которые по какой-то причине также остались запущенными на узлах.