1с и виртуализация

 

Есть вещи, которые не меняются.

Позабавило в очередной раз, углядел тут.

 

Чисто поулыбаться, 1С ники млин ...
Мне:
Ниже описаны некоторые требования, которые мы считаем целесообразным предъявить к конфигурации новых серверов и ПО на них:
1. SQL сервер должен стоять на железке, т.е. мы хотим, что бы он крутился на реальном сервере, а не на виртуальном.
2. Предпочтительная версия сиквела - SQL 2008.
3. SQL должен использовать максимально возможное количество оперативки на своем сервере.
4. На том диске, где будут храниться сиквельные базы, параметры форматирования диска должны быть следующими: размер сектора = 32 Кб
5. Файлы баз и файлы логов транзакций должны находится на персональных массивах (т.е. кроме лога транзакций на его массив ничего не должно писаться, аналогично с массивом файлов базы)
6. Сервер приложений 1С и SQL сервер должны стоять на разных физических серверах
7. Операционки и под сервер приложений 1С и под сиквел должны быть 64-битными
8. Не менее 500 гигов дискового пространства необходимо выделить под базы 1С 8 на том сервере, где будет SQL.
9. Отдельно 500 гигов под бэкапы.

 

Я:
Все понятно, но для обеспечения отказоустойчивости машины должны быть виртуальными.
Количество оперативной памяти и процессоров под задачу будут выделены вполне адекватные.
Так, сервер SQL получит 60 Гигабайт оперативной памяти и 16 ядер, сервера 1С тоже.
Физически машины под сервера 1С и SQL будут разными.
Терять производительность дисковой подсистемы, мне кажется не целесообразным, для каждой
виртуальной машины будет выделен свой LUN с единомоментным быстродействием 10 15K SAS дисков в RAID 10, суммарным
объемом кэш памяти 2ГБ и мощностью двух современных внешних RAID контроллеров.
При необходимости система расширяется до 64-х дисков.
Те рекомендации о построении дисковой подсистемы под SQL, которые Вы мне приводите рассчитаны
либо на очень большие базы (не 1С прошу заметить) либо единственный сервер с внутренним дисковым массивом.
Эти рекомендации не учитывают использование больших отказоустойчивых систем, и сетей SAN поскольку,
для них нельзя или очень трудно составить общие рекомендации. В общем случае разбиение внешней дисковой подсистемы на отдельные
множественные RAID, сильно снижают общую пиковую производительность, такие вещи используют, если во внешней системе не хватает быстродействия
и тогда ставят вторую или превышено максимальное количество дисков в RAID группе, чего в данной компании и на данных задачах мы еще долго не достигнем.
Накладные расходы на виртуализацию составляют в современных системах всего несколько процентов от производительности и ими вполне можно пренебречь.
Общая производительность системы рассчитана мною с запасом на 3 года, поэтому сейчас мы не сможем создать в рабочей обстановке сколько
нибудь заметной нагрузки на данную систему.
[немного пропущено]
А уж хранить резервные копии на тех же серверах и массивах это вообще вне моего разумения, для этого есть Symantec Backup EXEC с его
агентами, стриммер и внешняя дисковая подсистема.
Писал я это глядя на 2 16"ядерных" сервера с 64ГБ оперативки и внешней SAS to Fiber СХД в кластере под Win 2008 Ent.
В общем угораю я с 1С ников ... дальше еще скажут клиента 8-ки ставить локально на 200+ пользователей ибо терминалы грех ... абзац ...