Как работает LeftHand SAN в производственной среде?
Ранее я задавал этот вопрос ServerFault: кто-нибудь имеет опыт работы с левой рукой VSA SAN
Общий консенсус выглядит так, как будто он недостаточно эффективен для рабочего сервера SQL даже при небольшой нагрузке.
Итак, новый вопрос: как SAN LeftHand работает на выделенных аппаратных блоках HP или Dell?
Мы рассматриваем Starter SAN с 2 узлами HP в двухсторонней репликации, 2 серверами ESX, на которых размещены 2 сервера Active Directory, 1 сервер MS SQL, 1 файловый сервер и 1 сервер общего назначения для таких вещей, как сканирование на вирусы (Все Microsoft Server 2005 или 2008).
Причина, по которой я смотрю на LeftHand, заключается в полном программном пакете. Я планирую создать сайт аварийного восстановления, и мне нравится, как SAN может выполнять асинхронную репликацию в удаленном расположении, не возвращаясь к поставщику для получения дополнительных лицензий.
Мне также нравится избыточность, встроенная в архитектуру сетевого рейда.
Я посмотрел на другие SANS и обнаружил с ними разные недостатки.
Например, Dell EqualLogic: обнаружил, что, хотя отдельные блоки очень избыточны в аппаратном обеспечении, данные, однажды распределенные по нескольким блокам, не являются избыточными, если узел выходит из строя, вы потеряли единственную копию данных, хранящихся на этом оборудовании (одно Конечно, все оборудование выходит из строя... Когда? это единственный вопрос.).
Я также использовал XioTech SAN... Кстати, стоит денег, но я думаю, что это излишне для размера офиса, на который я нацеливаюсь. Стоимость аппаратного резервирования в XioTech делает его немного недосягаемым для бюджета, в котором я работаю.
Спасибо,
Кит
3 ответа
Около года назад я получил несколько из них на оборудовании HP для тестирования производительности, и некоторые из тех вещей, которые я сказал в вопросе LeftHand VSA SAN, применимы и здесь.
В то время многолучевое распространение iSCSI от LeftHand не было действительно активным / активным. Скажем, у вас есть:
- Четыре сервера LeftHand с 2 сетевыми картами по 1 ГБ каждый
- Один том в SAN для ваших файлов данных SQL Server
- Один том в сети SAN для файлов журналов SQL Server
- Один SQL Server с четырьмя сетевыми картами 1 Гб, выделенными для iSCSI
Когда вы выполняете запрос на SQL Server, который обращается к файлам данных, вы получите только 1 ГБ пропускной способности чтения, несмотря на то, что вы используете четыре сетевые карты. Устройства LeftHand (и действительно, все устройства iSCSI SAN, которые я видел) будут отправлять данные из SAN только на один конкретный MAC-адрес на SQL Server.
Вы можете обойти это путем:
- Использование нескольких томов данных и томов журнала, а также ручное управление тем, какой путь является "основным" путем для каждого возврата к серверу. Даже тогда вы все равно будете получать 1 ГБ пропускной способности для каждого файла данных, что ограничивает производительность резервного копирования, производительность DBCC и т. Д.
- Использование 10 ГБ Ethernet.
- Использование программного обеспечения для сетевой работы, которое действительно работает. Я пытался использовать пару поставщиков, и я еще не видел, чтобы они преодолели эту проблему.
Если вам нужна пропускная способность более 1 ГБ, тогда, пока вы не услышите от кого-то, кто на самом деле снял его, и может показать вам (не просто сказать: "О, да, он отлично работает на моем L337 b0xx0r"), то не вкладывайте свои деньги.
Fibre channel не обязательно отличается: просто вы можете легко получить оптоволоконные соединения 4 ГБ вместо 1 ГБ Ethernet. У вас все еще есть те же сложные задачи. На следующей неделе я делаю презентацию на IndyPASS, по совпадению - если вы находитесь в этом районе, проходите мимо.
Что ж, если дело в том, что репликация отстает, когда выполняется на уровне блоков SAN, нельзя просто предположить, что доставка журналов также не будет отставать. Обе технологии репликации будут выполняться через определенный промежуток времени, верно? Беспокоит ли тогда потерянные данные против поврежденных данных? Я не думаю, что репликация SAN будет признана пригодной для использования, если не будет получено полное дифференциальное обновление. Так данные повреждены или просто потеряны? Если SQL виртуализирован, вы отправляете не только дб или только логи транс; Я просто не уверен, как данные будут повреждены?
Может быть, мы сможем получить больше информации от Брента, но я не думаю, что асинхронная репликация SAN будет работать с файлами данных SQL Server, вам нужно будет что-то вроде зеркального отображения базы данных / доставки журналов. Или, по крайней мере, это то, о чем я всегда думал, и у меня еще не было возможности проверить это самому.
Кто-нибудь может подтвердить или опровергнуть?