Я устанавливаю сервер хранения на 16 ТБ (который в конечном итоге удвоится по емкости) для хранения мультимедиа. Этот сервер должен быть прочитан двумя клиентами Windows Server 2008, на которых размещены приложения нашей компании. Я слышал об iSCSI, но из того, что я читал, кажется, что iScsi обрабатывает целевой сервер, как если бы он был напрямую подключен к жесткому диску, что очень затрудняет обмен данными с двумя клиентами, поскольку они будут случайным образом записывать и читать данные, которые могут испортить вещи вверх.
Итак, какую комбинацию программного и аппаратного обеспечения я могу использовать для получения высокой скорости чтения на стороне Windows? Прямо сейчас я рассматриваю 2 двойных гигабитных сетевых адаптера с TOE и NFS, но я не хочу покупать сетевые адаптеры, пока не буду уверен, что они будут достаточно быстрыми.
Спасибо
Начало: Определите цену за данные. Стоимость потери данных или потери доступа в день.
Использование: определите, сколько отдельных обращений для чтения и записи вы получите в часы пик. Также определите скорости передачи данных для чтения и записи.
Сеть: с таким объемом данных вам следует обратиться к 10Gb Ethernet. Посчитайте, сколько времени потребуется, чтобы скопировать туда данные.
Рейд: в рейдах такого размера автоматическая перестройка не является разумной идеей. Восстановление занимает так много времени, а шансы найти дефект на дополнительном диске достаточно велики, что лучше избегать автоматики. Выберите рейд 10 или хотя бы рейд 6.
Совместное использование: если вам действительно нужна резервная копия для вещи, вероятно, лучше всего отразить хранилище. Посмотрите что-нибудь с репликацией в реальном времени. NAS или SAN, вероятно, лучший вариант. Или вы изучаете кластеризацию своих серверов MS.
Опыт: построить макет. Вы планируете сложную установку. Попробуй его сломать. Вы будете поражены, насколько легко вывести это из строя, если не спланировать должным образом.
Хорошо, позвольте мне уточнить это. У вас есть хранилище с прямым подключением на сервере, но вы хотите поделиться файлами на нем с двумя другими серверами Windows 2008? Почему бы не использовать Samba и покончить с этим? Samba в основном превращает ваш сервер Solaris в файловый сервер, входящий в домен. Просто установите Samba, настройте общие файловые ресурсы и позвольте серверам Windows 2008 получать доступ к файлам оттуда.
Если вы хотите создать какое-то решение для общего кластера, вам необходимо использовать файловую систему кластеризации. Да, iSCSI предназначен для обеспечения совместного использования на уровне блоков. Однако с файловой системой кластеризации вы должны использовать что-то вроде iSCSI в качестве нижнего уровня для совместного использования физического дискового пространства.
Думаю, проблема в том, что вам нужно уточнить, для чего серверы 2008 года будут использовать установку Solaris. По крайней мере, это дало бы представление о том, что Добрый обмена участвует.
Это немалый объем памяти. Вы говорите как минимум о 10 дисках (2 ТБ, RAID 5 + 1 горячий резерв) и, вероятно, о 20, а может и больше. И вы говорите, что он удвоится за срок службы коробки. Я не буду говорить, что вы не можете найти сервер для хранения всех этих дисков, но у вас будет очень мало вариантов и, вероятно, в любом случае вы получите пару лотков для внешних дисков. Развертывание собственного решения с одним сервером для этого, безусловно, возможно, но вы должны спросить себя, будете ли вы довольны, когда все эти данные будут зависеть от чего-то с ограниченной избыточностью и минимальной поддержкой.
Вам следует взглянуть на цены на системы хранения iSCSI SAN \ NAS начального уровня, чтобы понять, сколько они будут стоить, и посмотреть, могут ли они предоставить то, что вам нужно. По крайней мере, вы получите приблизительную сумму стоимости коммерческого решения в термоусадочной упаковке.
Вы правы, что iSCSI не позволит вам делиться между двумя серверами Windows в смысле Active \ Active, но вы можете использовать iSCSI для представления хранилища на один из серверов и сделать так, чтобы этот сервер разделял том (ы), чтобы второй сервер мог доступ к ним с помощью SMB. Вы также можете просто поделиться напрямую с помощью SMB - почти все устройства NAS также будут делать это - и просто соединить оба сервера таким образом.
Что касается вашего удобного выбора, я бы ответил, что если важна доступность данных, в любом случае вам следует рассмотреть как минимум два на сервере хранения, а может и больше с таким объемом хранилища. И как минимум два на каждый целевой сервер с резервными коммутаторами в сочетании, чтобы гарантировать отсутствие единых точек отказа независимо от требований к производительности.
Если вы обнаружите, что вам нужна более высокая производительность, чем может обеспечить одиночный канал GigE (например, пропускная способность более 80-100 МБ / с или случайные IOPS (блоки 4K)> ~ 8000), обязательно проверьте, что любое выбранное вами решение действительно поддерживает какой-либо механизм. для использования нескольких сетевых адаптеров на одно соединение (многопутевое соединение / связывание каналов / агрегация каналов и т. д.), которые также поддерживает Windows 2008 и ваше выбранное сетевое оборудование.
Только одна маленькая вещь: если вы стремитесь к скорости и доступности, забудьте о RAID 5. Используйте зеркалирование, 16 ТБ не так уж и дороги.
Вы получите чтение с разбросом (до удвоенной пропускной способности), а когда диск выходит из строя, нужно перестроить только его часть с помощью наименее затратной операции (не нужно рассчитывать специальные контрольные суммы).
Кроме того, в худшем случае ™ может выйти из строя до половины дисков.
В остальном я экспериментировал дома с примерно 360 ГБ зеркального SATA, Solaris на Intel и клиентом OS X и Gbit ethernet. Все нормальное железо, без серверных компонентов; установил jumbo-кадры и получил 58 МБ / с с SMB, очень близко к встроенному диску iMac.
NFS должен быть еще быстрее, но не на каждой платформе, на OSX не очень хорошо, не знаю для Windows.
Кроме того, для настройки вы должны знать, какую нагрузку вы будете делать, чтобы выбрать правильные диски (небольшое количество большего или большее количество маленьких дисков), буферы, размеры пакетов, ...