What the eyes see and the ears hear, the mind believes
Только ZFS, только хардкор (соответственно либо FreeBSD, либо solaris-ы).
Производительный, но холодный процессор. Минимум i5 2ххх, желательно i7 3xxx.
32 гига RAM (а лучше 64). Кэши - наше всё.
Двухпортовый NIC на контроллере intel (менее желателен broadcom).
SAS HBA. От четырех портов, обязательно SAS2/SATA3. И в целях совместимости - LSI. Желательно 1GB кэша (при этом обязательно battery-backed).
5 х WD RED 3TB под пул raidz (подключаются к чипсетным портам).
SSD накопитель под ZFS Intent Log (фактически кэш записи). Очень быстрый на запись (на чтение вообще пофиг), емкость желательно 256GB+ (фактически не для емкости, а для производительности). Можно поставить 2 штуки в RAID0, будет веселее. Эти SSD должны уметь сливать свой кэш в NAND-чипы при потере питания (supercapacitor или прочие прибамбасы).
SSD накопитель под L2ARC (кэш чтения). Желательна быстрая запись (чтение у них у всех за глаза), важен большой размер. Так же можно собрать RAID0, если не хватит производительности.
Итого такая СХД гарантированно сможет выдавать wire-speed (практически уверен, что и 2G агрегированного линка тоже). Плюс пробить кэши до дисков крайне затруднительно ибо:
Запись физически идет в RAM, синхронные операции завершаются после того, как данные подтвердятся в ZIL. Запись в ZIL сначала подтверждается из RAM контроллера (значит есть гиг синхронной записи на скорости интерфейса контроллера), если пробивается гиг кэша, запись пойдет в SSD, если кончится SSD или память (что вероятнее), запись пойдет уже непосредственно на диски. Так же надо отметить, что асинхронные запросы на запись "подтверждаются" уже в оперативке, т.е. с ними еще меньше проблем по части производительности.
При чтении данные сначала ищутся в RAM (при чем тут у ZFS все не как у классических контроллеров: кэш один и тот же и на чтение и на запись... размер кэша не половина доступного места, а всё). Если там их нет, то просматривается L2ARC. При отсутствии данных и там (т.е. на SSD), обращение идет на диски. При каждом чтении данные оседают во всех вышестоящих кэшах (т.е. при чтении из L2ARC данные попадают в память, при чтении со шпинделей попадают и в память и на SSD). Значит, чтобы вынудить ZFS читать с дисков, нужно чтобы между записью (или последним чтением) этих данных и их запросом было прочитано или записано других данных больше, чем размер нашего массива SSD. В подавляющем же большинстве юз-кейсов данные будут читаться максимум из L2ARC, т.е. из SSD, на соответствующих скоростях.
Самое забавное, что это фактически "забисплатно" функционал enterprise-овых СХД: всякие flex-cache, easy tier и т.п. делают то же самое (переносят горячие данные на быстрые носители), только за безумные деньги.
Производительный, но холодный процессор. Минимум i5 2ххх, желательно i7 3xxx.
32 гига RAM (а лучше 64). Кэши - наше всё.
Двухпортовый NIC на контроллере intel (менее желателен broadcom).
SAS HBA. От четырех портов, обязательно SAS2/SATA3. И в целях совместимости - LSI. Желательно 1GB кэша (при этом обязательно battery-backed).
5 х WD RED 3TB под пул raidz (подключаются к чипсетным портам).
SSD накопитель под ZFS Intent Log (фактически кэш записи). Очень быстрый на запись (на чтение вообще пофиг), емкость желательно 256GB+ (фактически не для емкости, а для производительности). Можно поставить 2 штуки в RAID0, будет веселее. Эти SSD должны уметь сливать свой кэш в NAND-чипы при потере питания (supercapacitor или прочие прибамбасы).
SSD накопитель под L2ARC (кэш чтения). Желательна быстрая запись (чтение у них у всех за глаза), важен большой размер. Так же можно собрать RAID0, если не хватит производительности.
Итого такая СХД гарантированно сможет выдавать wire-speed (практически уверен, что и 2G агрегированного линка тоже). Плюс пробить кэши до дисков крайне затруднительно ибо:
Запись физически идет в RAM, синхронные операции завершаются после того, как данные подтвердятся в ZIL. Запись в ZIL сначала подтверждается из RAM контроллера (значит есть гиг синхронной записи на скорости интерфейса контроллера), если пробивается гиг кэша, запись пойдет в SSD, если кончится SSD или память (что вероятнее), запись пойдет уже непосредственно на диски. Так же надо отметить, что асинхронные запросы на запись "подтверждаются" уже в оперативке, т.е. с ними еще меньше проблем по части производительности.
При чтении данные сначала ищутся в RAM (при чем тут у ZFS все не как у классических контроллеров: кэш один и тот же и на чтение и на запись... размер кэша не половина доступного места, а всё). Если там их нет, то просматривается L2ARC. При отсутствии данных и там (т.е. на SSD), обращение идет на диски. При каждом чтении данные оседают во всех вышестоящих кэшах (т.е. при чтении из L2ARC данные попадают в память, при чтении со шпинделей попадают и в память и на SSD). Значит, чтобы вынудить ZFS читать с дисков, нужно чтобы между записью (или последним чтением) этих данных и их запросом было прочитано или записано других данных больше, чем размер нашего массива SSD. В подавляющем же большинстве юз-кейсов данные будут читаться максимум из L2ARC, т.е. из SSD, на соответствующих скоростях.
Самое забавное, что это фактически "забисплатно" функционал enterprise-овых СХД: всякие flex-cache, easy tier и т.п. делают то же самое (переносят горячие данные на быстрые носители), только за безумные деньги.
-
-
23.01.2013 в 09:28-
-
23.01.2013 в 09:30-
-
23.01.2013 в 09:33Вопрос "А НАФИГА ??!" я не задаю ), потому как любые данные критично-важные и требуют почти моментального доступа )
-
-
23.01.2013 в 12:13-
-
23.01.2013 в 12:20Век живи, век учись.