Новый сервер 1С SQL(60users)

[a_shats]

разве что ставить 2САС винта на лог. Но опять же нужно брать контройлер.
Зачем ? Предлагается внешний дисковый массив. И базу и лог на него - и все дела.
не сомневаюсь. но постоянно бэкапещейся лог транзакций не имеет такую ценность в принципе. а тем более для нас.
То есть у Вас бэкап идет на ленту, а электричество отключается избирательно, и даже в принципе не может отключиться в момент бэкапа ? И еще вопрос. Вы пробовали накатывать на базу лог, сбэкапленный на ходу ? И как ощущения ?  :D
остановит на 3-5 минут пока сотрудник ИТ не кликнет несколько раз мышью в ЕМ. но повторюсь. вероятность крайне мала.
цель не оправдывает средства !!!!
Ага. Копирование лога в десятки гигабайт пройдет одномоментно, и Вы на 200% уверены, что бэкап лога, сделанный на ходу, целостен. А если и нет - у Вас есть два бэкапа. Верно ?  :D
48 Гб какими модулями ? )
4 GB модулями, не вопрос - деньги Ваши
ЗЫ Посему я сразу и спрашивал насчёт цен по зап. частям  Дабы не создавать вам проблем и не отнимать время
Это не проблема. Проблема будет, если мы Вам продадим того ежика, которого Вы сейчас хотите - а потом наш сервис будет рассказывать мне про меня много нового, а Вы, соответственно - им  :D
Да, и на цену контроллера скидку дам, т.е. 1К у.е. со всей суммы, включая скидку на винты  :D

[Dave251]

gs

В четырехпроцессорнике 24 слота памяти. В двухсокетниках - максимум 16, чаше 8. Ну вот и считайте.

2х процовые платформы я не рассматриваю вообще.

А насчет скидки - Вы подумайте. Мы ведь наверно неспроста готовы пожертвовать жадностью . Просто нам так спокойнее спать будет...

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

Модуль 4ГБ стоит навскидку под тонну.

а поточнее? и насчёт цена на 2гб модули

Зачем ? Предлагается внешний дисковый массив. И базу и лог на него - и все дела.

Да? ну значит я не так понял. я думал LSI Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int как раз для винды и логов.
А выкинуть лог за массив с БД будет не лучше ?

То есть у Вас бэкап идет на ленту, а электричество отключается избирательно, и даже в принципе не может отключиться в момент бэкапа ?

Бэкап идёт на сервер в соседнем здании. электричество - ИБП и генератор на всё здание.

И еще вопрос. Вы пробовали накатывать на базу лог, сбэкапленный на ходу ? И как ощущения ?

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

Ага. Копирование лога в десятки гигабайт пройдет одномоментно, и Вы на 200% уверены, что бэкап лога, сделанный на ходу, целостен. А если и нет - у Вас есть два бэкапа. Верно ?

в какие десятки ? раз в сутки шринк. да и не буду я вообще трогать лог. запущу БД так, как есть, создав новый файл лога
Повреждение БД и одновременно повреждение лога - это фантастика. Вернее вероятность такая же, как с сервером и массивом предложенными вами.
Для нашей фирмы:
Потеря данных за: 1-2 часа-нормально.
Простой: 1-2 часа - нормально, 2-5 часов терпимо, более уже конечно критично.

Ага. Копирование лога в десятки гигабайт пройдет одномоментно, и Вы на 200% уверены, что бэкап лога, сделанный на ходу, целостен. А если и нет - у Вас есть два бэкапа. Верно ?

зачем вообще трогать лог ? не пойму. Разве что, если вы рассматриваете случай повреждения самой БД, то с сервером, предложенным вами, будет та же ситуация.

Проблема будет, если мы Вам продадим того ежика, которого Вы сейчас хотите - а потом наш сервис будет рассказывать мне про меня много нового, а Вы, соответственно - им

пока в том, что это ёжик, вы меня не убедили  :roll:

[Dave251]

Для прояснения, хочу задать вопрос, по схеме подключения, предлженного сервера:
Контройлер "Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int" работает в PCI-E к нему подключается 2 SAS винта. На данном массиве крутится ОС.


Далее на PCI-X работает "QLA2462/CK, Qlogic, PCI-X/266MHz, dual 4Gbit/s, Full Duplex, Fibre, dual LC" котоый в свою очередь соеденяется с "RS-1220-F4-5412E-2048] Xyratex 12-Bay 4G FC to SAS/SATA Dual RAID Controller, 2GB, BBU, 4port" в котором находится 12 SAS HDD и расширяется "RS-1220-XPN-74662] 12 Bay SAS to SAS/SATA 2U RAID Expansion, 2x disk IO module, 2xPSU" с ещё 12 SAS HDD.
Итого, мы имеем дисковый массив с резервным контройлером.
На данном массиве крутится БД и логи БД.

Я правильно понимаю?

[a_shats]

Да? ну значит я не так понял. я думал LSI Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int как раз для винды и логов.
А выкинуть лог за массив с БД будет не лучше ?

Чем лучше ? На массиве дублированы контроллеры, блоки питания, FC и SAS порты. На внутренней дисковой не дублировано вообще ничего.
на тестовых базах много раз. отлично ! на боевой не разу, но теория подтверждается людьми, столкнувшимися с подобными случаями.
У вас есть другая информация ? поделитесь плиз.
Хорошо, спрошу по-другому. Чем гарантирована целостность снятого на ходу лога ?
Повреждение БД и одновременно повреждение лога - это фантастика.
Чувствуется, что пока сами не попадете на такое - не поверите.
Потеря данных за: 1-2 часа-нормально.
Простой: 1-2 часа - нормально, 2-5 часов терпимо, более уже конечно критично.
За один-два часа вы восстановите работоспособность сервера, проверите ее, восстановите работоспособность ОС, проверите ее, накатите как бы целостный лог 5 ГБ на БД, проверите ее ?

Контройлер "Logic SAS HBA SAS3041E-R, PCI-E, 3Gb/s, SAS, 4-port int" работает в PCI-E к нему подключается 2 SAS винта. На данном массиве крутится ОС.
Да.
Далее на PCI-X работает "QLA2462/CK, Qlogic, PCI-X/266MHz, dual 4Gbit/s, Full Duplex, Fibre, dual LC" котоый в свою очередь соеденяется с "RS-1220-F4-5412E-2048] Xyratex 12-Bay 4G FC to SAS/SATA Dual RAID Controller, 2GB, BBU, 4port" в котором находится 12 SAS HDD и расширяется "RS-1220-XPN-74662] 12 Bay SAS to SAS/SATA 2U RAID Expansion, 2x disk IO module, 2xPSU" с ещё 12 SAS HDD.
Итого, мы имеем дисковый массив с резервным контройлером.
На данном массиве крутится БД и логи БД.
Почти да. Контроллер там нельзя назвать 100% резервным - вполне можно использовать его производительность. При отказе любого (!) из контроллеров - да, массив продолжит работу на втором.

[Dave251]

a_shats

Чем лучше ?

А лучше на мой взгляд тем, что лог и БД на совершенно разных массивах, и в случае потери массива с БД(что наименее вероятно, как вы утверждаете, хотя постоянно приводите в пример )  лог останется жив и актуален, а бэкапы лога скорее всего не понадобятся. хотя для нас это не шибко важно, но в теории это так.
А если наоборот, то вообще не критично. Если массив с БД жив, то потеря лога транзакций вообще никак не отразится на данных. и понадобится всего 5-10 минут на создание нового лога транзакций. Я знаю кучу примеров, где админы лог выносят вообще на, так не любимый вами RAID0, потому как при целой БД лог совершенно не важен.
Лог транзакци(с опцией "Recoveru Model-Full") нужен только при повреждении самой БД ! А вы предлагаете их на один массив

На массиве дублированы контроллеры, блоки питания, FC и SAS порты. На внутренней дисковой не дублировано вообще ничего.

Ну БП на сервере тоже просто обязан дублироваться. ну а FC и SAS порты.....хорошо, но скажите, что будет, если умрёт "Fibre Channel adapter" ? что нам делать в таком случае ? И сколько это времени займёт ?
а вот САТА счеталок у меня завалялась парочка, впрочем как и дисков

Хорошо, спрошу по-другому. Чем гарантирована целостность снятого на ходу лога ?

тем же, чем гарантируют MS сохранность БД в обычном, рабочем режиме.

Чувствуется, что пока сами не попадете на такое - не поверите.

Знаете, не обязательно самому попадать. Я руководствуюсь не только своим опытом, но и опытом других людей.
Кстати шансов, что рухнет ваш массив(с логами и БД) больше, чем вероятность, что одновременно рухнет ваш массив с БД и мой массив на САТА с логом.

За один-два часа вы восстановите работоспособность сервера, проверите ее, восстановите работоспособность ОС, проверите ее, накатите как бы целостный лог 5 ГБ на БД, проверите ее ?

Ну почему вы опять рассматриваете вариант падения массива с БД ? Ведь БД то будет стоять на предложенном вами, суперотказоустойчивом массиве ! А критикуете вы мой массив на САТА, куда я хочу лог перенести. Дак давайте обсуждать потерю лога, а не БД
А об этом я выше писал. потеря лога но с целой БД никак не отразится на работе. Потеря же БД, но с целым логом- большая вероятность восстановления всех данных до збоя. конечно для нас, не сильно отличается от потери одновременно БД и лога (как в вашем варианте), но в нашем случае, возможна потеря данных за час !

Почти да. Контроллер там нельзя назвать 100% резервным - вполне можно использовать его производительность. При отказе любого (!) из контроллеров - да, массив продолжит работу на втором.

А в случае сбоя контройлера, переключение на другой автоматически ? И на сколько я понял, там 2а контройлера?

Кстати нашёл цену на SAS3041E-R и понял, что разница действительно не существенна. Но тут уже вопрос о конфигурации сервера под наши, конкретные задачи !

[Dave251]

Кстати ещё несколько вопросов !
Как вы относитесь к наращиванию памяти в серверах, модулями памяти разной ёмкости и от разных производителей ?

Есть ли полки с большим кол-вом места под диски и насколько отличается по цене ?

Возможно ли приобретение массива отдельно и как это скажется на гарантии ?

[a_shats]

А лучше на мой взгляд тем, что лог и БД на совершенно разных массивах, и в случае потери массива с БД(что наименее вероятно, как вы утверждаете, хотя постоянно приводите в пример )  лог останется жив и актуален, а бэкапы лога скорее всего не понадобятся. хотя для нас это не шибко важно, но в теории это так.
А если наоборот, то вообще не критично. Если массив с БД жив, то потеря лога транзакций вообще никак не отразится на данных. и понадобится всего 5-10 минут на создание нового лога транзакций. Я знаю кучу примеров, где админы лог выносят вообще на, так не любимый вами RAID0, потому как при целой БД лог совершенно не важен.

Еще раз.
При отказе массива под логом БД встанет или нет ?

Лог транзакци(с опцией "Recoveru Model-Full") нужен только при повреждении самой БД ! А вы предлагаете их на один массив

Именно. На один отказоустойчивый массив, с единым управлением и мониторингом, не зависящий никак от капризов ОС на сервере в том числе.

Ну БП на сервере тоже просто обязан дублироваться. ну а FC и SAS порты.....хорошо, но скажите, что будет, если умрёт "Fibre Channel adapter" ? что нам делать в таком случае ? И сколько это времени займёт ?

Есть мнение, что если у Вас помрет FC HBA - вам придется выбрасывать и сам сервер. Ибо статистика их отказов у нас стремится к нулю (если быть точным - 2 отказавших контроллера за 4-5 лет).

Знаете, не обязательно самому попадать. Я руководствуюсь не только своим опытом, но и опытом других людей.
Кстати шансов, что рухнет ваш массив(с логами и БД) больше, чем вероятность, что одновременно рухнет ваш массив с БД и мой массив на САТА с логом.

C чего  бы ? А вот то, что база при падении внутреннего массива встанет однозначно - это да. И восстановление ее в любом случае займет не 5 и не 10 минут - если Вам важен результат, конечно.

Ну почему вы опять рассматриваете вариант падения массива с БД ? Ведь БД то будет стоять на предложенном вами, суперотказоустойчивом массиве ! А критикуете вы мой массив на САТА, куда я хочу лог перенести. Дак давайте обсуждать потерю лога, а не БД
А об этом я выше писал. потеря лога но с целой БД никак не отразится на работе. Потеря же БД, но с целым логом- большая вероятность восстановления всех данных до збоя. конечно для нас, не сильно отличается от потери одновременно БД и лога (как в вашем варианте), но в нашем случае, возможна потеря данных за час !

При записи в файлы БД происходят следующие вещи:
- страницы SQL на запись кэшируются
- производится запись в лог без кэширования
- по заполнении кэша на запись либо по истечении заданного интервала производится запись в БД.
Напомнить, сколько Вы хотите иметь ОЗУ ? Вы готовы потерять несколько ГБайт информации в худшем случае (массив под логами падает во время перепроведения документов, к примеру) ?

А в случае сбоя контройлера, переключение на другой автоматически ? И на сколько я понял, там 2а контройлера?

Да.

Кстати нашёл цену на SAS3041E-R и понял, что разница действительно не существенна. Но тут уже вопрос о конфигурации сервера под наши, конкретные задачи !

Ваши задачи не являются уникальными и имеют совершенно известные и стандартные решения. Можете пошерстить этот форум на предмет - тут их много.
Вы ради копеечной экономии (на которую я уже Вам обещал дать скидку) пытаетесь городить ежа - плохо управляемую, сильно разнородную дисковую подсистему.
Еще раз прошу поверить на слово - такие ежи никакой радости админу не приносят. Только геморрой.

[a_shats]

Кстати ещё несколько вопросов !
Как вы относитесь к наращиванию памяти в серверах, модулями памяти разной ёмкости и от разных производителей ?

Крайне отрицательно. Обычно приводит к проблемам.

Есть ли полки с большим кол-вом места под диски и насколько отличается по цене ?

А смысл ? Диски надо считать не в полке - а в массиве.

Возможно ли приобретение массива отдельно и как это скажется на гарантии ?

Отдельно - от сервера ? На массив - своя гарантия, точно такая же.

[Dave251]

a_shats

Еще раз.
При отказе массива под логом БД встанет или нет ?

Да. так же как и при отказе массива с самой БД + лог. Хотя насколько я понял, по сказанному ниже, вероятность падения массива предложенного вами практически равна нулю ?

На один отказоустойчивый массив, с единым управлением и мониторингом, не зависящий никак от капризов ОС на сервере в том числе.

"не зависящий никак от капризов ОС на сервере" - соглашусь, достаточно веский аргумент в пользу вашей системы.

Есть мнение, что если у Вас помрет FC HBA - вам придется выбрасывать и сам сервер. Ибо статистика их отказов у нас стремится к нулю (если быть точным - 2 отказавших контроллера за 4-5 лет).

обнадёживающая статистика. Честно говоря не ожидал !
Но чесно говоря страшно представить, если таким "счастливчиком" окажусь я и жаль, что он весьма дорог.

C чего  бы ? А вот то, что база при падении внутреннего массива встанет однозначно - это да. И восстановление ее в любом случае займет не 5 и не 10 минут - если Вам важен результат, конечно.

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

При записи в файлы БД происходят следующие вещи:
- страницы SQL на запись кэшируются
- производится запись в лог без кэширования
- по заполнении кэша на запись либо по истечении заданного интервала производится запись в БД.
Напомнить, сколько Вы хотите иметь ОЗУ ? Вы готовы потерять несколько ГБайт информации в худшем случае  ?

Все изменения не хранятся вечно в кэше, а еще и пишутся непосредственно в базу при коммите транзакции, так что утверждение "- по заполнении кэша на запись либо по истечении заданного интервала производится запись в БД", если речь идет о кэше SQL - явное заблуждение.

массив под логами падает во время перепроведения документов, к примеру

а чем перепроведение в 1С отличается от проведения? одна перепроводка- один коммит.

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

я уже писал. данный спор я веду не для финансовой выгоды, а уже для просвещения
a_shats

Крайне отрицательно. Обычно приводит к проблемам.

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

А смысл ? Диски надо считать не в полке - а в массиве.

Ок. Задам вопрос по другому. Если я захочу добавить ещё диски в массив, мне придётся докупать полку ?

[a_shats]

Да. так же как и при отказе массива с самой БД + лог. Хотя насколько я понял, по сказанному ниже, вероятность падения массива предложенного вами практически равна нулю ?

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

обнадёживающая статистика. Честно говоря не ожидал !
Но чесно говоря страшно представить, если таким "счастливчиком" окажусь я и жаль, что он весьма дорог.

Никто не мешает установить 2х1-портовых контроллера вместо 1х2-портового, просто это еще дороже.

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

Повторюсь - внутренний массив в случае чего по-любому ляжет раньше, чем внешний. А сыпаться будет не в пример чаще.

Все изменения не хранятся вечно в кэше, а еще и пишутся непосредственно в базу при коммите транзакции, так что утверждение "- по заполнении кэша на запись либо по истечении заданного интервала производится запись в БД", если речь идет о кэше SQL - явное заблуждение.

Не заблуждение - а нормальный общепринятый алгоритм работы кэша записи. И не только SQL. Писать по commit просто слишком накладно, так писалось только во времена "плоских" таблиц (dbf и иже с ним). В логи - да, пишется сразу и мимо кэша. В базу - нет.

а чем перепроведение в 1С отличается от проведения? одна перепроводка- один коммит.

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

я уже писал. данный спор я веду не для финансовой выгоды, а уже для просвещения

Это правильно

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

Апгрейд ныне - вообще штука довольно сомнительная для этого класса (ниже 4 сокетов) серверов. Слишком быстро (примерно раз в 2 года) меняются платформы.

Ок. Задам вопрос по другому. Если я захочу добавить ещё диски в массив, мне придётся докупать полку ?

В массивы диски чаще всего докупаются именно полками. И ставятся - не купленные абы где и абы какие, а - только от вендора массива. Такой порядок - у всех "правильных" вендоров.

[Dave251]

Перечислите плиз, что именно дублируется.

Контроллеры, БП, FC-порты.

на сколько ?

Предложение отправлю

Тут в самом деле не помешала бы статистика. По ней можно было бы прикинуть
Подсчитать по 3м критериям. Статистика падений, скорость замены той или иной зап. Части и скорость восстановления БД.
1. Падение внешнего массива с логом и БД – замена зап.частей исключительно долгий процесс. Восстановление только с последнего бэкапа лога транзакций. Потеря данных максимальна.
2. Падение внешнего массива с БД, но массив с логом цел – Замена зап.частей исключительно долгий процесс. Восстановление с текущего лога транзакций. Потеря данных минимальна.
3. Падение внутреннего массива с логом, но внешний с БД цел – Замена  зап.частей быстрая. Восстановление не требуется. Затраты времени минимальны.

Это теория. Практика - чтобы внешний массив ТАК навернулся, нужно что-то очень суровое по электричеству либо охлаждению.
Внутренний массив в таких случаях обычно не выживает. Внешний имеет шансы.

commit
An operation that saves all changes to databases, cubes, or dimensions made since the start of a transaction. A commit guarantees that all of the transaction's modifications are made a permanent part of the database, cube or dimension. A commit also frees resources, such as locks, used by the transaction.

Вы знаете отличия физической структуры БД MSSQL от логической ?
И - еще раз процитируйте мне, пожалуйста, место из этого вот текста, где написано, что после коммита гарантированно выполняется запись данных на диск. Физическая. Запись в базу - да, согласен. Точнее - в кэш записи инстанса MSSQL. Я на скорую руку не нашел этой статьи в BOL, попозже, если найду - процитирую.

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

Именно, Ваш вариант приводит к бОльшему, а не к меньшему риску.

а я вот сомневаюсь, что в ближайшие год, полтора мне понадобится целая полка ! 2-4 винта возможно доставить понадобится.

А теперь расскажите, пожалуйста, что Вы собираетесь делать с этими 2-4 винтами после добавления.

[gs]

Две однопортовки дороже на несколько сотен баков. Но, как уже сказали, кулоджиковские HBA - исключительно дубовая вещь. Они если и сломаются, то последними

Насчет надежности внешних дисковых - конечно не бывает идеальных систем. А чубайс, например, может нагнуть что угодно. Но по сравнению с внутренними массивами это просто небо и земля. Скажем так - если Вам не хватает надежности внешнего массива, решением может быть только два внешних массива, в зеркале

[Dave251]

FC-порты.

подробнее можно ?

Предложение отправлю

спасибо !

Это теория. Практика - чтобы внешний массив ТАК навернулся, нужно что-то очень суровое по электричеству либо охлаждению.
Внутренний массив в таких случаях обычно не выживает. Внешний имеет шансы.

а как, на практике, внутренние САТА массивы (на хорошем железе) себя ведут ?

Вы знаете отличия физической структуры БД MSSQL от логической ?
И - еще раз процитируйте мне, пожалуйста, место из этого вот текста, где написано, что после коммита гарантированно выполняется запись данных на диск. Физическая. Запись в базу - да, согласен. Точнее - в кэш записи инстанса MSSQL. Я на скорую руку не нашел этой статьи в BOL, попозже, если найду - процитирую.

изучаю разные доки! начинаю склоняться, что вы правы по этому вопросу

Именно, Ваш вариант приводит к бОльшему, а не к меньшему риску.

БОльшему,но с меньшем временем восстановления. ну и ценником )

А теперь расскажите, пожалуйста, что Вы собираетесь делать с этими 2-4 винтами после добавления.

например реплицирую туда базу для чтения....и пусть там отчеты делают. можно же в отдельный массив собрать и посадить на другой контройлер?

Две однопортовки дороже на несколько сотен баков. Но, как уже сказали, кулоджиковские HBA - исключительно дубовая вещь. Они если и сломаются, то последними

а вот почему так? ведь железо оно и в Африке железо !

Насчет надежности внешних дисковых - конечно не бывает идеальных систем. А чубайс, например, может нагнуть что угодно.

Для этого у нас дизельный генератор...на всё здание

Но по сравнению с внутренними массивами это просто небо и земля. Скажем так - если Вам не хватает надежности внешнего массива, решением может быть только два внешних массива, в зеркале

о да ! моя мечта....  :roll: но руководство не разделяет нашу точку зрения

[a_shats]

FC-порты.

подробнее можно ?

Их по 2 на каждом контроллере. При наличии между хостом и массивом свича и/или подключенных 2 портах FC с сервера при отказе интерфейса массив будет отдавать через другой интерфейс, если это явно не запрещено в управлении им.

а как, на практике, внутренние САТА массивы (на хорошем железе) себя ведут ?

Нормально ведут, но в здравом уме под сколь-нибудь серьезные нагрузки типа БД их не используют.

изучаю разные доки! начинаю склоняться, что вы правы по этому вопросу

Это основы, и не только для SQL. Теоретически и в RAID-контроллерах отложенная запись работает так же (практически - зависит от фирмвареписателей).

БОльшему,но с меньшем временем восстановления. ну и ценником )

Неа

например реплицирую туда базу для чтения....и пусть там отчеты делают. можно же в отдельный массив собрать и посадить на другой контройлер?

Можно. А дальше что делать будете ? Еще 2-4 винта докупать ? И ждать по 6-8 недель прихода этих винтов ?

а вот почему так? ведь железо оно и в Африке железо !

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

о да ! моя мечта....  :roll: но руководство не разделяет нашу точку зрения

Это до первого же чубайсопришествия или еще какого ЧП масштаба площадки  :D

[Dave251]

Их по 2 на каждом контроллере. При наличии между хостом и массивом свича и/или подключенных 2 портах FC с сервера при отказе интерфейса массив будет отдавать через другой интерфейс, если это явно не запрещено в управлении им.

ясно ! спасибо.

Нормально ведут, но в здравом уме под сколь-нибудь серьезные нагрузки типа БД их не используют.

а по отказоустойчивости ?

Это основы, и не только для SQL. Теоретически и в RAID-контроллерах отложенная запись работает так же (практически - зависит от фирмвареписателей).

я уже понял

Можно. А дальше что делать будете ? Еще 2-4 винта докупать ?  И ждать по 6-8 недель прихода этих винтов ?

почему бы и нет ? мы всегда так делаем.

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

я думаю, что эта компания производит и сата железо, которое можно использовать для некоторых задачь

Это до первого же чубайсопришествия или еще какого ЧП масштаба площадки  

К сожалению, видимо да!!! (