Я не так хорошо знаком с хранилищем. У меня есть вопросы по запуску физических и виртуальных машин с SAN для хранения.
Можно ли загрузить ОС из хранилища SAN, подключенного к физическому серверу? Если да, то есть ли у него обратная сторона? Скажем, есть несколько дисков, один для ОС, и на этом сервере установлен SQL Server, а есть другие диски для данных, журналов и временных баз данных, все из SAN. Будет ли работать лучше, если ОС загружается с локального жесткого диска, чем сохранение ее в SAN с файлами данных SQL? Высокий IOPS? Задержка?
Я пытаюсь сравнить приведенные ниже 3 и дать количественную оценку.
Физическая машина - загрузка ОС с локального диска и других из SAN
Физическая машина - загрузка ОС и других дисков из SAN
Виртуальная машина - виртуальный диск на локальном диске хоста Hyper-V, данные SQL / журнал / темп на vSAN
Виртуальная машина - виртуальный диск, данные SQL / журнал / темп - все в vSAN
Будет ли последний работать плохо по сравнению с другими?
Спасибо
В наши дни загрузка из SAN довольно редка. Гипервизоры, которые я обычно вижу, загружаются с SD-карт. Затем вы можете использовать 100% локального хранилища для виртуальных машин или использовать SAN исключительно для виртуальных машин. Также можно просто загрузить гипервизор PXE, если загрузка с SD-карты не подходит.
Чтобы ответить на ваши конкретные вопросы:
Можно ли загрузить ОС из хранилища SAN, подключенного к физическому серверу?
Да, это так. Многие сетевые карты центров обработки данных / предприятий имеют встроенные необходимые протоколы iSCSI для облегчения этого.
Если да, то есть ли у него обратная сторона?
Ага, много. Сложность и хрупкость самые большие. И, по правде говоря, успехов не так уж и много.
Скажем, есть несколько дисков, один для ОС, и на этом сервере установлен SQL Server, а есть другие диски для данных, журнала и временной базы данных, все из SAN.
Будет ли работать лучше, если ОС загружается с локального жесткого диска, чем сохранение ее в SAN с файлами данных SQL?
Было бы лучше иметь все файлы данных в вашем локальном хранилище. Для серверов баз данных я считаю SAN умирающим носителем. Локальное хранилище сейчас так много быстрее, чем хранилище SAN (даже при подключении 40 Гбит / с). Один диск NVMe на оборудовании класса 2019 может ограничивать скорость чуть менее 4 ГБ / сек, что составляет более 30 Гбит / с. На одном диске. За не такие уж большие деньги. В будущем, когда PCI-e 4.0 начнет поставляться на серверах следующего поколения, эта потенциальная скорость будет увеличиваться вдвое. Серверы AMD Epyc имеют более 128 линий PCIe 4.0, что дает вам потенциал более 250 ГБ / с (2 ТБ / с). на розетку. Извините, но я считаю SAN мертвой средой в современном мире.
Кроме того, MSSQL больше не требует общего хранилища для кластерной системы. Благодаря AlwaysOn High Availability вы можете получить высокодоступные SQL-серверы без общего хранилища (хотя структура хранилища на всех серверах должна выглядеть одинаково на каждом узле).
Будет ли последний работать плохо по сравнению с другими?
Все они будут плохо работать по сравнению с локальным хранилищем. Однако я понимаю, что вы на самом деле задаете не этот вопрос, и я просто надеюсь, что вы не купили новый SAN в 2019 году и у вас все еще есть возможность пересмотреть свою оценку.
Давайте пройдемся по этим;
Физическая машина - загрузка ОС с локального диска и других из SAN
Есть много таких систем, работающих прямо сейчас повсюду, в частности, такие вещи, как невиртуализированные серверы баз данных, работают таким образом, это прекрасно и очень полезно, если вам нужны самые низкие задержки и получить доступ к каждой последней капле производительности - CGI-рендеринг-фермы обычно тоже так работают.
Физическая машина - загрузка ОС и других дисков из SAN
Я делал это один или два раза за эти годы, обычно это немного более «хрупко», чем мне бы хотелось, да, это работает, но может потребовать гораздо больше работы, чем вариант с локальным диском, и действительно все, что вам нужно » Это значит сэкономить немного больше на ваших серверах, не покупая загрузочную пару и дисковый контроллер - лично я не вижу, чтобы я использовал это в будущем.
Виртуальная машина - виртуальный диск на локальном диске хоста Hyper-V, данные SQL / журнал / темп на vSAN
Конечно, это работает нормально, так работает МНОГО ВМ - большинство виртуальных машин / инстансов AWS работают таким образом, это действительно очень популярно. Если выбранный вами гипервизор не позволяет вам переносить виртуальные машины с одного локального диска на другой хост и диск этого хоста, то иногда вы можете упустить одно из преимуществ виртуализации, а именно возможность перенести все виртуальные машины с хоста, чтобы разрешить он должен быть исправлен / обновлен / исправлен без воздействия на пользователя. Вы упоминаете здесь vSAN, о каком продукте вы говорите, если вы говорите о продукте VMware vSAN, который меняет вещи, поскольку вы можете запускать диски локально, иметь защиту от сбоев и иметь возможность мигрировать с хоста на хост - может быть, придет вернуться, чтобы прояснить это?
Виртуальная машина - виртуальный диск, данные SQL / журнал / темп - все в vSAN
В корпоративных средах это, вероятно, наиболее часто используемый и надежный метод прямо сейчас (хотя это может измениться, поскольку распределенные файловые системы, такие как vSAN, действительно набирают обороты).
Что касается производительности последнего варианта - она полностью зависит от централизованных дисковых массивов, которые вы используете, и методов связи, используемых для доступа к ним. Если вы используете Ethernet со скоростью 1 Гбит / с против медленного дискового массива, то это определенно будет медленнее, чем использование локальных дисков, производитель массивов, который я предпочитаю, в сочетании с FCoE 40 Гбит / с намного быстрее, чем все, что я могу напрямую подключить к дискам NVMe моей серверной панели. Так что это действительно зависит от того, что это за централизованное хранилище.
Я надеюсь, что это поможет прояснить ваши варианты.
Я не уверен, насколько «редка» эта практика, я видел ее много, но думаю, это зависит от окружающей среды.
Обычно я вижу загрузку из SAN, когда используются блейд-серверы. Поскольку типичный блейд-сервер имеет только два слота для дисков, это может быть довольно ограничивающим фактором для чего-то вроде сервера базы данных, где может потребоваться несколько терабайт пространства. Кроме того, быстро и легко заменить вышедшее из строя лезвие, просто заменив лезвие и не беспокоясь о том, что парень сделает это, чтобы переместить диски, а не вставить их в правильные гнезда. Это по-прежнему требует настройки HBA в новом блейд-сервере, как описано ниже.
Загрузка Windows или Linux из SAN проста, вам нужно будет поработать с администратором хранилища, предоставить им WWN с HBA (обычно два интерфейса HBA для резервных путей). После того, как специалисты службы хранилища подготовили загрузочный LUN, загрузите сервер и войдите в BIOS HBA во время процедуры POST. Просканируйте доступный LUN и скажите HBA использовать его для загрузки. Убедитесь, что HBA является первым устройством в порядке загрузки, и ваша установка Windows должна увидеть его и предложить установку на этот LUN. Возможно, проще всего сначала настроить только загрузочный LUN, а затем после установки ОС добавить любые дополнительные LUN для данных.