информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsSpanning Tree Protocol: недокументированное применениеВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
По опыту настройки подобных связок. 11.11.08 05:02  Число просмотров: 2674
Автор: ВНЬ Статус: Незарегистрированный пользователь
Отредактировано 11.11.08 05:13  Количество правок: 2
<"чистая" ссылка>
По опыту установки такого типа связок.

Конструкция:
LAN-100Mb-Switch-1Gb-TermServer-1Gb-SQLServer

На терминалке -- 1 винт, с которого ночером делается snap-backup.
Ессно, какая-то винда с возможностями терминалки. Чаще всего -- 2003.
Оперативки МНОГО, виндовый свап в самом начале винта, маленький.

На SQLServer -- Unix-like операционка, под которой крутится либо
а) сам SQL если 1С-ка отвязана от мелкомягких
б) какой-то имитатор виндов, с поднятым MS SQL
Винтов от 2 до 5 в RAID. Там -- как пожелается.
SWAP - тоже в начало винта, но не в самое, а после рутового раздела. Под базу -- тоже отдельный раздел. Копирование -- ежедневное инкрементное за 7 дней. За более ранние периоды -- воскресные ночные полные копии с остановленным SQL на отдельно примонтированный раздел (для такого случая :-), эти по 4 штуки на месяц. Ну, и ежемесячные, на год -- 12 штук. Всё утаптывается в архив.
Иногда к SQLServer подключается либо отдельный винт, либо какой-нть netstorage, по отдельному каналу, питание которого включается только тогда, когда делается бекап, либо для восстановления.

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

Если же не RAID, то на одном винте винда с отдельным разделом в начале под свап, SQL-база на другом, который побыстрее, и на нём же свап для SQL, т.к. он, в реальных задачах, свапится намного чаще, и тоже в отдельном разделе. Свапы однозначно желательно разнести по разным винтам. Как, собственно, и ОС, на которой крутится SQL с собственно файлами базы. А лучше -- поставить третий винт под свапы, небольшой, но шустрый. Держать систему на одном разделе со свапом -- не есть гуд. Свап всегда зачистил -- и вуаля. И раздел с системой меньше юзается, меньше шансов на слёт системы.
<operating systems>
[NT] Поспорил тут с 1Сниками. 02.05.08 17:14   [Den]
Автор: Lurga Статус: Elderman
<"чистая" ссылка>
Есть, значит, Цитрикс-сервер на Вынь2К3, к одной из сетевух которого по гигабитке цепляется второй сервак с SQL. Никаких других функций на него не возлагается, просто обрабатывает SQL-запросы от первого сервера. Во втором серваке есть два винта -- самсунговская 120-ка и сигейтовская восьмидесятка.

Собственно, возник вопрос, куда рассовать свлопники Винды и SQL для повышения быстродействия? Я склоняюсь к тому, чтобы на системном винте (80гигов) жёстко выделить Винде гигов пять под свой своп, а остальное отдать под свопник SQL. 1Сники кричат, что нужно восьмидесятку разрубить пополам, на системном разделе дать место под своп Винды, а на втором -- под своп SQL.

Подскажите что-нибудь. :)
на самом деле для полноты картины не хватает данных 22.10.08 17:18  
Автор: Mopok Статус: Незарегистрированный пользователь
<"чистая" ссылка>
на самом деле для полноты картины не хватает данных
1) какой объем базы 1С?
2) сколько памяти на серверах?
3) какая версия SQL-сервера? и какая версия винды на которой установлен этот SQL?

идеальный вариант - когда памяти достаточно для того чтобы свопы вобще отключить
кстати, заставить использовать SQL сервер более 4-х гигабайт памяти сам по себе вопрос не такой тривиальный
А виндовый своп сильно используется? 05.05.08 10:40  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 05.05.08 10:41  Количество правок: 1
<"чистая" ссылка>
А виндовый своп сильно используется?
(Обратить внимание на объем и среднюю скорость прокачки при высокой деловой активности).

Если сильно - видать памяти мало. Может оперативки добавить и забыть про виндовый своп. В крайнем случае завести еще терминалку и определенную группу сотрудников на нее коннектить.

Если нет возможности добавить памяти и приходися мириться со свопом, то интересным решением будет поставить еще один винт. Получится один винт - своп системы, второй - своп сервера, третий - хранилище базы. Если нагрузка на своп системы велика, то поставить пару винтов под это в РАИД0 (нулевого уровня достаточно) можно программаный РАИД, можно просто (если винда позволит) завести два свопа на разных винтах - винда рюхнет и будет стараться их параллельно/равномерно загружать.

Если нужно совсем без дополнительных вложений, то самый худший выриант - разбить винт пополам, каждая половина для своей задачи. А именно, предположим, что в процессе работы большая нагрузка на оба свопа и они разведены на каждый из двух равных разделов одного диска. В результате головка этого диска будет летать из одного конца в другой и даже при маленькой прокачке получим очень маленкую пропускную способность и высокую нагрузку. Если же нагрузка на базу (хранилище) велика, то самым плохим решением будет на том же диске с базой, на другом разделе заводить еще какой-либо из свопов, на который велика нагрузка.
Рекомендация: На каждом диске по одному разделу. Самый нагруженый своп расположить на одном винте с самым не нагруженым. Если сама база является не сильно нагруженой или наоборот сильно нагруженой, то ее объединить соответственно с сильно нагруженным или не нагруженным свопом.
ИМХО, Самсунг фтопку! 04.05.08 20:52  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 08.05.08 14:08  Количество правок: 2
<"чистая" ссылка>
ИМХО, Самсунг фтопку!
Или в какую-нибудь рабочую станцию.
80-ку можно оставить для pagefile.sys и tempdb.
Для системы и БД (в разных разделах) надо иметь хотябы два хороших винта в хардовом зеркале - тут тебе и прибавка в скорости и б'ольшая надежность.
Самой системе много не надо - 24Гб за глаза и за уши, все сотальное пространство - БД, резервные копии и т.п.
Разве у SQL Server есть свой своп? Или ты про tempdb? 03.05.08 15:07  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
а 120-ник вообще сбоку и никак не используется? 02.05.08 21:31  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Если речь о делении одного физического винта, то с точки зрения быстродействия тут как-то может влиять разве что фрагментация диска. Так что если что и разносить, то не фиксированный своп винды и sql, а систему и свопы. Хотя разница все равно будет копеечная, если вообще заметная.
На 120-нике у него наверное базы лежат 03.05.08 18:32  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
По умолчанию размер tempdb не ограничен и легко может сожрать все свободное место.
Фрагментация тоже хоть и незначительная, но будет - tempdb по умолчанию создается маленького размера и увеличивается по мере необходимости на 10%.
При размещении temdb на системном диске надо об этом помнить и соответственно настраивать ее параметры: чтобы она не расширялась слишком часто, чтобы не заполнила весь диск.
А просто разместив tempdb на отдельном разделе, можно оставить настройки по умолчанию и забыть - других аргументов "за" я не вижу.
Пардон, вчера спьяну не въехал. 02.05.08 22:24  
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 03.05.08 10:30  Количество правок: 1
<"чистая" ссылка>
Выигрыш будет не копеечный. Своп SQL нужно выносить на отдельный от системы винт. Виндовский нужно оставить на системном.
на разных винтах - да 03.05.08 12:54  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Но тут речь была о делении одного физического диска.
Конечно на разных. Деление одного физического на два логических вообще выигрыша не дает. 03.05.08 16:39  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
> Но тут речь была о делении одного физического диска.
Я ж и говорю, что вчера на пьяную голову не сообразил сразу о чем речь.
Если делить 1 диск то я делаю так: 20.10.08 16:53  
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Но тут речь была о делении одного физического диска.
> Я ж и говорю, что вчера на пьяную голову не сообразил сразу
> о чем речь.
Если делить 1 диск то я делаю так:
сделать 1 раздел под свап(обычно это С диск)
засунуть раздел и файл в максимально в физическое начало диска.
З.Ы. а вообще конечно лучше скинуть систему на отдельный винт. А свап сделать на каком нить винте типа раптора либо еще лучше -2 раптора в страйпе. (Это если конечно памяти уже некуда совать а делать что то надо)
Страйп - это РАИД-0? То есть отказоустойчивость системы в... 20.10.08 18:35  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> З.Ы. а вообще конечно лучше скинуть систему на отдельный
> винт. А свап сделать на каком нить винте типа раптора либо
> еще лучше -2 раптора в страйпе. (Это если конечно памяти
> уже некуда совать а делать что то надо)

Страйп - это РАИД-0? То есть отказоустойчивость системы в процессе работы должна сильно упасть?
Упадет минимум в два раза, по сравнению с stand-alone диском. 20.10.08 19:24  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 20.10.08 19:29  Количество правок: 2
<"чистая" ссылка>
Вообще отказоустйчивость снижается пропорционально количеству дисков в RAID 0.

А stripe, на сколько я помню, это заданного размера блок данных, записываемый на каждый диск в массиве.
Отказоустойчивость свопа? 20.10.08 18:50  
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 20.10.08 19:00  Количество правок: 1
<"чистая" ссылка>
Именно системы. Если падает диск со свопом, то системе начинает сниться @#$%ец. Особенно если это системный своп. 20.10.08 20:26  
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 20.10.08 20:29  Количество правок: 1
<"чистая" ссылка>
Причем имеется в виду всей вычислительной системы, а не операционной системы. 21.10.08 11:26  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Именно так. 21.10.08 22:03  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Гм. он точно так же снится как и на одном диске и не важно... 21.10.08 17:08  
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Гм. он точно так же снится как и на одном диске и не важно чей он - ОСи или чего то другого. Это актуально только в контексте того что фактор риска умножается на 2 в случае со страйпом, а отказоустойчивость - тут неподходящее выражение, т.к. данные имеют смысл только в рантайме (точно так же = какая отказоустойчивость у 1 диска).
Вообще это конечно может привести к труднопредсказуемым последствиям. Как минимум из худших вариантов это БСОД.
И потом насколько я понял - разговор изначально шел именно о быстродействии.
Ну хорошо, пусть будет "вероятность отказа" вместо... 21.10.08 17:20  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Гм. он точно так же снится как и на одном диске и не важно
> чей он - ОСи или чего то другого. Это актуально только в
> контексте того что фактор риска умножается на 2 в случае со
> страйпом, а отказоустойчивость - тут неподходящее
> выражение, т.к. данные имеют смысл только в рантайме (точно
> так же = какая отказоустойчивость у 1 диска).

Ну хорошо, пусть будет "вероятность отказа" вместо "отказоустойчивости". В любом случае она растет пропорционально количеству дисков в РАИД-0. Почему бы не добавить еще один для ЕСС и получить РАИД-5? Быстро и даже надежнее, чем с одним диском. Тогда бы и дисков добавить. Сделать массив дисков штук так на 10 - 15, во внешней корзине, разумеется. Контроллер за штуку баксов купить, а лучше два - вдруг сгорит, чтоб сразу заменить и минимальное время простоя. Много чего хорошо, но это все не сделано, наверняка не от того, что не знают как, а от того, что дорого.
В общем хорошо быть богатым и здоровым, чем бедным и больным.

> Вообще это конечно может привести к труднопредсказуемым
> последствиям. Как минимум из худших вариантов это БСОД.
> И потом насколько я понял - разговор изначально шел именно
> о быстродействии.

Да, но без капвложений и не в ущерб надежности. Это хоть и не оговаривалось, но однозначно подразумевалось.
По опыту настройки подобных связок. 11.11.08 05:02  
Автор: ВНЬ Статус: Незарегистрированный пользователь
Отредактировано 11.11.08 05:13  Количество правок: 2
<"чистая" ссылка>
По опыту установки такого типа связок.

Конструкция:
LAN-100Mb-Switch-1Gb-TermServer-1Gb-SQLServer

На терминалке -- 1 винт, с которого ночером делается snap-backup.
Ессно, какая-то винда с возможностями терминалки. Чаще всего -- 2003.
Оперативки МНОГО, виндовый свап в самом начале винта, маленький.

На SQLServer -- Unix-like операционка, под которой крутится либо
а) сам SQL если 1С-ка отвязана от мелкомягких
б) какой-то имитатор виндов, с поднятым MS SQL
Винтов от 2 до 5 в RAID. Там -- как пожелается.
SWAP - тоже в начало винта, но не в самое, а после рутового раздела. Под базу -- тоже отдельный раздел. Копирование -- ежедневное инкрементное за 7 дней. За более ранние периоды -- воскресные ночные полные копии с остановленным SQL на отдельно примонтированный раздел (для такого случая :-), эти по 4 штуки на месяц. Ну, и ежемесячные, на год -- 12 штук. Всё утаптывается в архив.
Иногда к SQLServer подключается либо отдельный винт, либо какой-нть netstorage, по отдельному каналу, питание которого включается только тогда, когда делается бекап, либо для восстановления.

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

Если же не RAID, то на одном винте винда с отдельным разделом в начале под свап, SQL-база на другом, который побыстрее, и на нём же свап для SQL, т.к. он, в реальных задачах, свапится намного чаще, и тоже в отдельном разделе. Свапы однозначно желательно разнести по разным винтам. Как, собственно, и ОС, на которой крутится SQL с собственно файлами базы. А лучше -- поставить третий винт под свапы, небольшой, но шустрый. Держать систему на одном разделе со свапом -- не есть гуд. Свап всегда зачистил -- и вуаля. И раздел с системой меньше юзается, меньше шансов на слёт системы.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach