Очень хочется ликбезу и пообщаться на умные темы..
Модераторы: Trinity admin`s, Free-lance moderator`s
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
DAS - Direct Attached Storage, т.е. массив, напрямую подключенный к одному серверу. Это может быть массив с собственным контроллером, либо JBOD (т.е. просто корзина с винтами), подключенный к RAID-контроллеру в сервере. Понятно, что в случае проблем с кабелем между JBOD и сервером - привет такому массиву :D
SAN - Storage Area Network, т.е. сеть хранения данных.
Вообще говоря, даже сеть из 2 серверов и одного массива уже, по сути, SAN. Да, дальше можно ставить свичи, подключать доп. массивы и сервера - суть уже не меняется.
Т.е. оба этих термина непосредственно к массивам не относятся, а относятся - к способам их использования.
Другое дело, что маркетинговыми методами к DAS относят, как правило, массивы и JBOD с SCSI/SAS интерфейсами к хостам (серверам), к СХД для SAN - с FC
Но, вообще-то, задачи не решаются путем применений к ним модных сокращений :D А - совершенно по-другому.
"Решил собрать кластер" - а есть нужда в таком решении ? Т.е. простой в час-несколько в рабочее время действительно критичен для бизнеса, в котором Вы обеспечиваете ИТ-составляющую ?
Решение строится исходя из потребностей в :
- производительности
- отказоустойчивости.
Первое для достаточно типовых задач вроде 1С, определяется по опыту, второе берется исходя из допустимого простоя.
Насчет "мне никто не ответит" - я тут просветительской работой занимаюсь постольку поскольку. Будете требовать ответа - придется подождать тех, кто согласится этим заниматься.
SAN - Storage Area Network, т.е. сеть хранения данных.
Вообще говоря, даже сеть из 2 серверов и одного массива уже, по сути, SAN. Да, дальше можно ставить свичи, подключать доп. массивы и сервера - суть уже не меняется.
Т.е. оба этих термина непосредственно к массивам не относятся, а относятся - к способам их использования.
Другое дело, что маркетинговыми методами к DAS относят, как правило, массивы и JBOD с SCSI/SAS интерфейсами к хостам (серверам), к СХД для SAN - с FC
Но, вообще-то, задачи не решаются путем применений к ним модных сокращений :D А - совершенно по-другому.
"Решил собрать кластер" - а есть нужда в таком решении ? Т.е. простой в час-несколько в рабочее время действительно критичен для бизнеса, в котором Вы обеспечиваете ИТ-составляющую ?
Решение строится исходя из потребностей в :
- производительности
- отказоустойчивости.
Первое для достаточно типовых задач вроде 1С, определяется по опыту, второе берется исходя из допустимого простоя.
Насчет "мне никто не ответит" - я тут просветительской работой занимаюсь постольку поскольку. Будете требовать ответа - придется подождать тех, кто согласится этим заниматься.
Я ни к воем случае не хотел от Вас что-либо требовать, Александр :) Просто у нас с Вами вроде завязалась беседа, и Вы куда-то пропали. Вот я и заволновался...
А что касается DAS и SAN - меня действительно интересовало, одно и то же железо используется, или нет? То-есть, если я у себя ставлю внешку с контроллером как DAS, что мне стоит из него потом сделать SAN? Только поставить оптический свитч? Или есть разница в протоколах, интерфейсах?
Я думаю, что мою дотошность следует рассматривать более как положительную черту, по крайней мее я давно не верю просто "компетентным" советам, а люблю докопаться до всего своей головой. Вам же потом будет приятно со мной беседовать на одном языке :D
А что касается кластера... Тут хочется убить двух зайцев сразу. Но более, конечно, стоит вопрос в отказоустойчивости. Мне более по нраву подъм сервера за считанные секунды, пусть с меньшей производительностью, чем простой час-два, но восстановление в полной силе. Все-таки у нас тут постоянная работа идет, и из опыта аварий, простой от 10 минут и более вызывает очень негативные реакции руководства и сотрудников...
А что касается DAS и SAN - меня действительно интересовало, одно и то же железо используется, или нет? То-есть, если я у себя ставлю внешку с контроллером как DAS, что мне стоит из него потом сделать SAN? Только поставить оптический свитч? Или есть разница в протоколах, интерфейсах?
Я думаю, что мою дотошность следует рассматривать более как положительную черту, по крайней мее я давно не верю просто "компетентным" советам, а люблю докопаться до всего своей головой. Вам же потом будет приятно со мной беседовать на одном языке :D
А что касается кластера... Тут хочется убить двух зайцев сразу. Но более, конечно, стоит вопрос в отказоустойчивости. Мне более по нраву подъм сервера за считанные секунды, пусть с меньшей производительностью, чем простой час-два, но восстановление в полной силе. Все-таки у нас тут постоянная работа идет, и из опыта аварий, простой от 10 минут и более вызывает очень негативные реакции руководства и сотрудников...
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
shattle
Не Александр - но неважно :D
А может и так, к примеру, оказаться, что решение-то нужно (и нужно обоснованно) не просто отказоустойчивое - а катастрофоустойчивое, т.е. с потребностью в нескольких географически разнесенных датацентрах с актуальными данными в каждом из них, и возможностью продолжить работу даже при отказе площадки.
Поэтому я Вам и намекаю - опишите, пожалуйста, задачу поподробнее
Не Александр - но неважно :D
Выше ж написал. DAS - 1 хост с 1 хранилищем. SAN - более одного того и/или другого. Разница - именно в назначении, в общем. А протокол один везде - SCSI, разве что работает где-то поверх IP, где-то поверх FC, а где и "просто" (SAS).А что касается DAS и SAN - меня действительно интересовало, одно и то же железо используется, или нет? То-есть, если я у себя ставлю внешку с контроллером как DAS, что мне стоит из него потом сделать SAN? Только поставить оптический свитч? Или есть разница в протоколах, интерфейсах?
Понимаете, вопрос применения в решении кластера - еще раз, это не вопрос нравов или негативных реакций, а вопрос а)реальной потребности и б)бюджета на решение. В принципе, достаточно и б) - что называется, любой каприз за Ваши деньги :DА что касается кластера... Тут хочется убить двух зайцев сразу. Но более, конечно, стоит вопрос в отказоустойчивости. Мне более по нраву подъм сервера за считанные секунды, пусть с меньшей производительностью, чем простой час-два, но восстановление в полной силе. Все-таки у нас тут постоянная работа идет, и из опыта аварий, простой от 10 минут и более вызывает очень негативные реакции руководства и сотрудников...
А может и так, к примеру, оказаться, что решение-то нужно (и нужно обоснованно) не просто отказоустойчивое - а катастрофоустойчивое, т.е. с потребностью в нескольких географически разнесенных датацентрах с актуальными данными в каждом из них, и возможностью продолжить работу даже при отказе площадки.
Поэтому я Вам и намекаю - опишите, пожалуйста, задачу поподробнее
За Александра - извините, просто мне что-то так показалось :D
А по поводу задачи - как я писал ранее, есть несколько уже не моодых серверов. Полностью парк заменять накладно и хлопотно. Задачи стоят не сильно сложные, но требуется откаоустойчивость. По крайней мере, один сервер будем точно покупать, за недостаточностью. Была мысль разделить сервера по функциям, чтобы, во-первых, упростить задачу поднятия сервера в случае его падения, а во-вторых, облегчить работу устаревшего железа. То-есть терминальник - на одной машине, 1С - на другой, MsSQL - на третьей. Вот для MsSQL и думаю купить сервер. И к нему - внешку для упрощения резервирования базы и отказоустойчивости системы. Проще будет поднять другой сервер SQL вместо упавшего, если база в другом месте. И к тому же была идея унести базу территориально, от любопытствующих. Ну, примерно так...
А за объяснения - отдельное спасибо! Появляется понимание процесса в целом...
А по поводу задачи - как я писал ранее, есть несколько уже не моодых серверов. Полностью парк заменять накладно и хлопотно. Задачи стоят не сильно сложные, но требуется откаоустойчивость. По крайней мере, один сервер будем точно покупать, за недостаточностью. Была мысль разделить сервера по функциям, чтобы, во-первых, упростить задачу поднятия сервера в случае его падения, а во-вторых, облегчить работу устаревшего железа. То-есть терминальник - на одной машине, 1С - на другой, MsSQL - на третьей. Вот для MsSQL и думаю купить сервер. И к нему - внешку для упрощения резервирования базы и отказоустойчивости системы. Проще будет поднять другой сервер SQL вместо упавшего, если база в другом месте. И к тому же была идея унести базу территориально, от любопытствующих. Ну, примерно так...
А за объяснения - отдельное спасибо! Появляется понимание процесса в целом...
Было дело, писал однажды)))
"Имеется контора, которая в своем хозяйстве пользует штук 6 серверов немного Б/у - 3-5лет давности. В основном машинки по 2 - 4 ядра Интел Ксеон 2600 - 3600, с памятью от гига до 4-х. Есть райды Мегарайд от 75 ГБт до 135. Крутится на этом всем около 20 разных баз размером под 500 Мб. Одна или две под гиг. Там же КД, терминалка Цитрикс, терминальный оффис, 1С 7.7, MsSQL. Периодически притормаживает 1С, в связи с чем и возник вопрос об апгрейде или поднастройках. Поковырялся я в машинках и понял, что торможение происходит на операциях чтения-записи на диски, да и шинка грузится неслабо. Пользователей всего ок. 200, активных ок. 20. Некоторые открывают по 10 окон, отчеты периодически, бессистемно. "
"Имеется контора, которая в своем хозяйстве пользует штук 6 серверов немного Б/у - 3-5лет давности. В основном машинки по 2 - 4 ядра Интел Ксеон 2600 - 3600, с памятью от гига до 4-х. Есть райды Мегарайд от 75 ГБт до 135. Крутится на этом всем около 20 разных баз размером под 500 Мб. Одна или две под гиг. Там же КД, терминалка Цитрикс, терминальный оффис, 1С 7.7, MsSQL. Периодически притормаживает 1С, в связи с чем и возник вопрос об апгрейде или поднастройках. Поковырялся я в машинках и понял, что торможение происходит на операциях чтения-записи на диски, да и шинка грузится неслабо. Пользователей всего ок. 200, активных ок. 20. Некоторые открывают по 10 окон, отчеты периодически, бессистемно. "
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Тогда решение примерно такое:
пара серверов с процессорами гденить 2xXeon 5440, ОЗУ эдак 16 ГБ с возможностью наращивания хотя бы до 32, пара винтов в зеркало под ОС, FC HBA 2-портовые
плюс
массив среднего уровня (например, IBM DS4700), винтов эдак 32, из которых 30 под базы, логи и прочее, 2 hot-spare.
Это все в MSCS и под MSSQL.
Для начала можно обойтись без свичей, два сервера да в MSCS подключить к массиву проблем нет.
Ваши серверы старые - все дружно в терминальную ферму. В идеале - Citrix. Хотя - сразу предупреждаю: если все Ваши 200 пользователей по какой-то суровой нужде разом полезут в 1С - эти Ваши старенькие сервера будет тошнить. По памяти и процессорам.
Плюс - с сетью между серверами хотя бы должно быть все ОЧЕНЬ хорошо.
пара серверов с процессорами гденить 2xXeon 5440, ОЗУ эдак 16 ГБ с возможностью наращивания хотя бы до 32, пара винтов в зеркало под ОС, FC HBA 2-портовые
плюс
массив среднего уровня (например, IBM DS4700), винтов эдак 32, из которых 30 под базы, логи и прочее, 2 hot-spare.
Это все в MSCS и под MSSQL.
Для начала можно обойтись без свичей, два сервера да в MSCS подключить к массиву проблем нет.
Ваши серверы старые - все дружно в терминальную ферму. В идеале - Citrix. Хотя - сразу предупреждаю: если все Ваши 200 пользователей по какой-то суровой нужде разом полезут в 1С - эти Ваши старенькие сервера будет тошнить. По памяти и процессорам.
Плюс - с сетью между серверами хотя бы должно быть все ОЧЕНЬ хорошо.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 10 гостей