Суперкомпьютер от Apple

Серверы от Apple до 14 мая 2002 года справлялись с возложенными на них задачами, но никогда не становились заметным событием в индустрии. Превращение Apple и NeXT в одну компанию не могло не привести к чему-то вроде Xserve…

В 2002 положение Apple не было безнадёжным, но до возвращении в высшую лигу было ещё далеко. Терять проще, чем возвращать утраченное. Из выступлений от имени Apple исчезла мантра о том, что она – маленькая компания. Теперь она снова росла.

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

Направление бытовой электроники, во всяком случае пока, не могло стать направлением главного удара. iPod, хоть он и вызвал брожение в умах среди поклонников Apple, как и Newton MessagePad, продавался ненамного лучше последнего.

Повторить с FireWire то же самое, что в 1998 удалось сделать с USB, явно не получалось.

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

Впрочем, проект компьютера для стоек был подписан и запущен в работу ещё в 2000 году, даже раньше чем iPod. И это не был проект обычного «яблочного» сервера. Это был очень амбициозный проект, первый шаг на ещё одном направлении главного удара.

Традиционные серверы от Apple

Они не блистали, но у них была своя ниша, уютная и надежно защищённая от вторжения чужих. В 1985, благодаря революции в издательском деле, у Apple появилась ещё одна разновидность клиентов: небольшие издательства, рекламные агенства, студии дизайна и тому подобные компании, в которых, для их основной деятельности, применялись Mac’и.

Помимо основной деятельности, даже компаниям с численностью в 10-15 человек, никуда не деться от непрофильных задач. И если Mac’и неплохо справлялись с ролью офисного компьютера, их даже называли иногда «лучшими компьютерами для офисов», в чем была доля правды, то для организации и администрирования локальных сетей, файл-серверов, а со временем ещё и веб-серверов, обычные Mac’и подходили намного хуже.

На рынке было не протолкнуться от захватывающих серверных решений на базе Windows или Unix, но для небольшой чисто Mac’овской компании приобретение таких решений было сравнимо с приобретением небольшого самолета. Для управления этими решениями был нужен высококвалифицированный персонал и дорогая техническая поддержка. Кроме того, это в наши дни Mac’и запросто уживаются с Windows и Unix машинами, а тогда с этим были проблемы.

В похожем положении были школы, некоммерческие организации, дилеры Apple, и многие другие. Поэтому, по соображениям гуманности, а также для получения дополнительной прибыли, и были созданы специальные серверные Mac’и. На самом деле все было немного сложней, а в конце 90-х Apple выпускала серверы с Unix в качестве операционной системы, что уничтожало некоторые из описанных выше преимуществ – но компания была серьёзно больна, и многие её решения принимались как будто в бреду.

Переход Apple на Mac OS X, фактически, решил эти проблемы. Помимо обычной версии каждой из больших кошек, выходил и серверный вариант системы, например, Mac OS 10.1 “Puma” продавалась параллельно с Mac OS 10.1 Server. По своей сути, серверный вариант системы ничем не отличался от обычной (поэтому они выходили одновременно), просто в серверном варианте некоторые настройки были другими, и вместе с ним поставлялось огромное количество специального программного обеспечения.

Серверная Mac OS X требовала для установки большего дискового пространства, но её без проблем можно было установить на любой Mac, с которым была совместима основная система. Выпускались Mac’и с припиской “Server” в наименовании модели, для тех у кого были более серьёзные серверные нужды.

Это было продолжением старой доброй традиции. Серверный вариант выпускается для каждого релиза macOS и в наши дни.

Xserve

14 мая 2002 года компания-производитель iPod, неожиданно, объявила свой собственный стоечный сервер. Такие компьютеры не используются сами по себе, они встраиваются в специальные стойки. Году в 2004 где-то в паутине мне попадался увлекательный рассказ одного умельца, который использовал Xserve в качестве обычного настольного Mac’а, в статье были иллюстрации – ему пришлось приложить некоторые усилия, при этом у него был опыт работы с этими машинками. У дилетанта Xserve умер бы через неделю.

Тем не менее, этот сервер (?) совершенно не подходил на роль традиционного сервера от Apple. Это был модуль для стандартных стоек, форм-фактора 1U, с одним или двумя G4 с тактовой частотой в 1 ГГц, с более чем приличными для своего времени техническими характеристиками

Можно что угодно думать про Motorola и IBM, но их процессоры были одним из великих достижений нашей цивилизации, они во многом превосходили процессоры главного своего конкурента – и внутри стоечного модуля, с Unix-подобной операционной системой внутри они были очень привлекательны.

Была ещё одна история, о которой я помню очень смутно (возможны неточности), я даже не могу с уверенностью утверждать когда это произошло. Но, вроде бы, именно после этой истории Apple, во время первого обновления модельного ряда Xserve, к моделям с одним и двумя процессорами на борту за 2999 и 3999 долларов, добавила специальную модель для кластеров, без оптического дисковода и всего с одним посадочным местом для диска, и с двумя процессорами, по цене однопроцессорный модели.

А случилось вот что:

В одном из университетов США, для какого-то исследования, требовавшего значительных вычислительных мощностей, профессор и руководитель проекта (с индийской фамилией), поняв что средств на приобретение суперкомпьютера родной вуз ему выделить не сможет, решил построить суперкомпьютер сам. Университет, конечно, не гараж в Лос Гатосе, да и с квалифицированными кадрами у университетов получше, но суперкомпьютер на порядок порядков превосходит по сложности Apple I.

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

И тут он наткнулся на рекламу PowerMac, скорее всего, G4. До этого он никогда не имел дела с ересью от Apple, но в рекламе сообщались подходящие ему данные, а по цене они почти влезали в бюджет.

Купив за свои деньги PowerMac, и выяснив что это не обман, он связался с Apple, надеясь получить скидки и техническую помощь.

Он получил даже больше, чем просил. В создании кластера участвовали инженеры Apple, и не только они: сверхбыстрые переключатели и специальные соединения для этого проекта Apple приобрела по своим каналам, примерно за треть их цены.

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

Естественно, маркетинговые службы Apple использовали это событие по максимуму, а кластер, за счёт Apple, переоснастили только-только объявленными кластерными Xserve, в подобранных инженерами Apple самых лучших для этого стойках. Занимаемая кластером площадь уменьшилась раза в четыре, число его элементов выросло примерно в полтора раза, а производительность — в несколько раз.

Мощная рекламная кампания Apple привела к неожиданным последствиям: обновлённый и значительно более мощный кластер едва попал в первую сотню. Кампания разбудила конкурентов, которые очень быстро оттеснили Apple «на её место».

История Xserve продолжалась ещё около десяти лет, потом проект закрыли.

Организация сервера резервных копий Time Machine для клиентских систем macOS с централизованным хранилищем на системах macOS, Linux Debian 10 Buster или Windows Server 2012 R2

На предприятии с большим количеством компьютеров на базе ОС Apple macOS может возникнуть необходимость развёртывания централизованного сервера для хранения резервных копий на базе пакета Time Machine с интеграцией в механизмы доменной авторизации на базе каталога Active Directory (AD). В данной заметке мы рассмотрим три варианта организации сетевого ресурса (SMB) под задачу резервного копирования компьютеров macOS, а также поговорим о разных вариантах настройки клиентов macOS для подключения к такому ресурсу.

Сразу стоит отметить, что по причине появления Apple File System (APFS) протокол Apple Filling Protocol (AFP) стал считаться устаревшим, поэтому рассматривать AFP в контексте данной заметки мы не будем.

Организация сетевого ресурса для Time Machine на macOS

С тех пор, как Apple отказались развивать «серверные» продукты в пакете Server.app оставив только Profile manager, многие стали задаваться вопросом, а как же сейчас организовывать Time Machine Server?

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

Рассмотрим пример создания сетевого каталога для Time Machine на macOS Mojave.

1. Откроем настройки и перейдём в общий доступ;

2. Добавим каталог, который будет использоваться для Time Machine;

3. Вызываем контекстное меню на каталоге и откроем «дополнительные параметры…»

Разрешим использовать каталог для резервного копирования Time Machine.

Если macOS введён в домен, то на каталог можно применить необходимую группу безопасности AD для ограничения доступа к резервным копиям.

Общие ресурсы для Time Machine не поддерживаются на разделах APFS.

Организация сетевого ресурса для Time Machine на Linux Debian 10

Поддержка Apple Time Machine появилась в Samba 4.8, но в репозитории Debian 9 имеется только версия 4.5, поэтому необходимо либо собирать Samba в ручную, либо установить пред-релизную сборку Debian 10 Buster, в репозитория которого Samba 4.9.5.

В нашем примере на базе хоста виртуализации с Windows Server 2012 R2 разворачивается виртуальная машина Hyper-V Gen2 c гостевой ОС Debian 10 Buster. Описанная далее процедура базовой настройки Debian 10 не имеет прямого отношения к нашей задаче резервного копирования и добавлена для полноты описания. Поэтому знатоки Debian могут переместиться в конец этого раздела, где идёт речь о создании сетевого ресурса на базе Samba.

Итак, выполним вход под супер-пользователем и начнём настраивать систему.

Первым делом необходимо настроить сеть:

Если в сети не используется IPv6, то отключим его:

Если для доступа в Интернет используется прокси-сервер, настроим его, чтобы была возможность устанавливать и обновлять пакеты:

Настоим репозитории Debian 10:

Установим обновления пакетов:

Установим пакеты, необходимые в рамках нашей задачи:

Настроим sudo, разрешив всем пользователям повышающим привилегии, использовать ранее заданные переменные с настройками прокси:

Разрешим пользователю user1 выполнять повышение привилегий. Добавим пользователя user1 в группу sudo

Теперь можно завершить сеанс пользователя root и в дальнейшем пользоваться учётной записью user1.

Так как система будет добавлена в домен, необходимо, чтобы на нашем сервере с Debian 10 было правильное время. Настроим NTP-клиент на получение времени с контроллеров домена:

Добавляем в файл записи о NTP-серверах:

Настраиваем поддержку Kerberos под свой домен AD:

Настраиваем конфигурацию SSSD под свой домен AD:

Установим права на конфигурационный файл

Система ещё не в домене, поэтому работа службы sssd невозможна, отключим и остановим её, а так же выполним очистку кэша:

Отключаем и останавливаем nmbd:

Выполняем настройку Samba:

Проверяем корректность настроек

Система выдаст предупреждение о лимите открытых файлов который в Linux и Windows отличается

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

Выполним настройку автоматического создания каталога пользователя:

Разрешим выполнение скрипта:

Попробуем получить билет Kerberos пользователя, учётные данные которого будут использоваться для ввода сервера в домен:

Проверим билет Kerberos:

Присоединим сервер к домену, используя ранее полученный билет Kerberos :

Получим и проверим билет Kerberos для учётной записи сервера:

Если ввод в домен осуществлялся не с правами учётной записи администратора домена, то для учётной записи сервера необходимо отдельно зарегистрировать запись SPN, которая требуется для работы протокола Kerberos. Сделать это можно на любой Windows-системе, присоединённой к домену следующей командой:

Включаем и запускаем SSSD:

Теперь настроим Linux для работы с доменными пользователями, чтобы в дальнейшем использовать свои административные учётные записи Active Directory для администрирования сервера.

Автоматическое создание домашнего каталога для доменных пользователей:

Настройка PAM для ограниченного входа в систему группам пользователей:

Установим права на файл:

Опишем в PAM использование нашего файла с перечнем разрешённых логинов/групп:

Настройка sudo для группы доменных пользователей:

Настройка PAM для SSH-подключений:

Настроим конфигурацию SSH-сервера:

Изменим следующие строки:

Перезапустим службу SSH-сервера:

Напоследок подключим диск, на котором будут хранится резервные копии.

Посмотрим, какой диск виртуальной машины доступен

В нашем примере будет использоваться диск /dev/sdb . Выполним на этом диске разметку:

n — создаём новый раздел

p — проверяем результат

w — записываем изменения

Форматируем созданный раздел в файловую систему ext4:

Создаём точку монтирования:

Узнаём необходимый для монтированная идентификатор UUID диска:

Настраиваем авто-монтирование диска при каждой загрузке сервера:

Применяем изменения в fstab

Установим доменную группу на каталог резервных копий:

Перезапустим службу Samba:

Организация сетевого ресурса для Time Machine на Windows Server

По умолчанию, Time Machine не поддерживает SMB ресурсы организованные на Windows Server, так как Windows Server не имеет расширения F_FULLSYNC. Поэтому мы вручную создадим, так называемый (в терминологии локализованной версии macOS), «рассеянный» (sparsebundle) пакетный образ диска и разместим его на этом сетевом ресурсе.

Подключим сетевой ресурс и создадим на нём рассеянный пакетный образ диска с помощью Disk Utility.app

• Имя файла: имя хоста
• Имя раздела: Резервные копии Time Machine
• Размер устанавливаем в зависимости от потребностей
• Файловая система: Mac OS Extended (Чувствительный к регистру символов, журналируемый)
• Шифрование: устанавливаем если мы хотим иметь зашифрованную резервную копию
• Раздел: Одиночный раздел — Схема разделов GUID
• Формат: Рассеянный пакетный образ диска

Создать образ sparsebundle можно и с помощью Terminal.app:

Отдельное внимание можно уделить ключу » -imagekey sparse-band-size= «, который по умолчанию имеет значение 16384 . С помощью него можно регулировать размер части диска, с учётом 512 байт на сектор. То есть по умолчанию размер части равен 8 Мб, а в примере 512 Мб.

После создания образа дисковой утилитой, он автоматически подключится в систему. Теперь необходимо включить на этом образе параметр enableOwnership, для того, чтобы Time Machine мог управлять разрешениями.

Откроем Terminal.app и узнаем каким устройством подключен образ:

Включим управление владением

Проверить состояние параметра можно как в терминале, так и в дисковой утилите

В Disk Utility.app информация об этом параметре «Владельцы включены» обновится только после переподключения образа. Однако, необходимо иметь ввиду, что данный параметр хранится на той системе, где он был включен и находится в файле /var/db/volinfo.database . Это можно проверить, но сперва узнаем идентификатор тома:

Затем прочтём файл

Для того, чтобы метод работал, необходимо заранее монтировать образ в систему при входе пользователя, создадим приложение на Apple Script:

Экспортируем его как «Программа», затем добавляем в автозагрузку при входе пользователя.

Для подобного метода резервного копирования на sparsebundle-диск можно использовать и другие и другие сетевые ресурсы, например NFS.

Подключение сетевого ресурса к Time Machine

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

Если подключаемся к сетевому расположению, то пример команды будет выглядеть так:

Несмотря на то, что клиентская машина с macOS в домене и у нас имеется сквозная аутентификация, здесь необходимо будет явным образом указать имя пользователя и пароль.

Если подключаемся к смонтированному HOSTNAME.sparsebundle на сетевом ресурсе:

Посмотреть информацию о существующих расположениях Time Machine:

Если в компании много компьютеров на базе macOS, то настраивать каждый из них вручную будет не совсем интересно. В таком случае для массовой настройки можно воспользоваться Profile Manager.

В группе macOS, секции Login Items, настроим аутентификацию пользователя на сетевом ресурсе.

В секции Time Machine укажем путь до сетевого каталога и параметры резервного копирования.

Для вступления параметров в силу необходим релогин. После применения параметров, пользователь сможет управлять только исключениями каталогов из резервного копирования.

Проверка восстановления из резервной копии

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

Перейдём в каталог, в котором хотим выполнить восстановление, вызовем spotlight сочетанием клавиш ⌘+пробел и откроем Time Machine. Остаётся выбрать файлы или каталоги, которые необходимо восстановить.

Подобным образом можно восстанавливать удалённые письма в приложении Mail.app.

Для восстановления операционной системы после критических сбоев, замены HDD/SSD или переноса конфигурации на новый Mac, необходимо воспользоваться macOS Recovery. После загрузки macOS Recovery переходим в Time Machine, выполняем подключение к «Другой сервер», прописываем сетевой путь до каталога с резервными копиями:

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