Назад | Перейти на главную страницу

переезжаете на новый выделенный сервер и вам нужна консультация по новой настройке

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

Наша текущая установка представляла собой сервер W2008R2 объемом 8 ГБ, на котором была запущена виртуальная машина IIS W2008R2 с использованием VMWare.

Мы переходим на сервер с 2 процессорами 24 ГБ с W2012 R2 на Hyper-V.

На нашей виртуальной машине мы запускаем iis 7.5 и sql server. Sql Server, похоже, хочет съесть всю память, поэтому мне пришлось ограничить его до 2 ГБ, что кажется недостаточным.

Мой вопрос: когда я перемещаю виртуальную машину на новый сервер, должен ли я создавать 2 виртуальные машины, одну для сервера sql и одну для IIS? Или я должен оставить их обоих на одной виртуальной машине? Или даже поставить Sql Server на выделенный сервер и запустить IIS в виртуальной машине?

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

Спасибо!

Это зависит от вашего использования.

Какая загрузка процессора в вашей текущей системе?

Насколько это IIS? Насколько это SQL?

Какое использование памяти у вашей текущей системы?

Насколько это IIS? Насколько это SQL?

Вообще говоря, для небольших операций можно объединить серверы IIS и SQL в один. Однако, если вы начнете преодолевать отметку 75% от максимума операций ввода-вывода, пора будет разделить ваши серверы. (75% - это произвольное число, но оно идеально, потому что это означает, что вы на полпути от 50%, что означает, что ваша система должна работать, до 100% эффективности, что означает, что ваша система не может работать лучше, чем она есть; планирование на этом этапе будет менее напряженным, чем планирование со 100% эффективностью, потому что на 100% ваши системы уже склонны к проблемам и легче решать проблему упреждающе, чем реактивно).

Если совокупный процент использования IIS и SQL равен или превышает 75% или произвольный желаемый максимальный процент использования, то вам следует разделить их.

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

  1. Определите вашу текущую задержку

  2. Определите, какую задержку вы готовы принять, и измените ее на эмпирическое количественное числовое значение. Пример; Если вы хотите немного задержаться; Сколько? 100 мс? 250 мс? 500 мс? 1с?

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

  4. a) Если допустимая задержка является средней, рассчитайте средние значения использования ЦП и памяти за время.

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

  5. Определите текущие возможности обработки / объем памяти

  6. Определите процент вашего роста в год; если у вас нет исходных данных для сравнения, произвольно предположите рост на 10% каждый год или возьмите 1 / (Current_Latency / Желаемая_ задержка) Икс 100% / Years_System_Was_In_Service, в зависимости от того, что выше.

  7. Определите вычислительную мощность / объем памяти, необходимые для того, чтобы ваши системы использовались на уровне менее 75% (Desired_Max_Usage_Percentage) в течение следующих Y лет до следующего обновления. Resource_Needed знак равноCurrent_Usage_Percentage Икс Current_Capability) + (1 + (Y_Years Икс Growth_Percentage)) / Desired_Max_Usage_Percentage

  8. Определите скорректированное значение, необходимое для обеспечения желаемой задержки.

Пример (CPU) 1:

Current Latency = 1000
Desired Latency = 500
Latency Variable = 1 + (1 / (1000 / 500)) = 1.5
Current_CPU_Usage = 100%
Current_Capability = 2CPU x 3.0GHz = 6.0GHz
Y_Years (to next upgrade) = 3
Growth_Percentage = 10%
Desired_Max_Usage_Percentage = 75%

Minimum Resource = (1 x 6.0) + (1 x (3 x .1))/.75 = 7.73GHz
Adjustment For Latency = 7.73 x 1.5

Result: Upgrade to minimum 7.73GHz
Result to desired latency: 11.60GHz

Пример (CPU) 2:

Current Latency = 1000
Desired Latency = 500
Current_CPU_Usage = 70%
Current_Capability = 2CPU x 3.0GHz = 6.0GHz
Y_Years (to next upgrade) = 3
Growth_Percentage = 10%
Desired_Max_Usage_Percentage = 75%

Minimum Resource = (.7 x 6.0) + (1 x (3 x .1))/.75 = 5.93GHz
Adjustment For Latency = 5.93 x 1.5 = 8.90GHz

Result: No need to upgrade
Result to desired latency: 8.90GHz

Пример (Память) 1:

Current Latency = 1000
Desired Latency = 500
Latency Variable = 1 + (1 / (1000 / 500)) = 1.5
Current_Memory_Usage = 100%
Current_Capability = 4GB
Y_Years (to next upgrade) = 3
Growth_Percentage = 10%
Desired_Max_Usage_Percentage = 75%

Minimum Resource = (1 x 4.0) + (1 x (3 x .1))/.75 = 5.73GB
Adjustment For Latency = 5.73 x 1.5 = 8.6GB

Result: Upgrade to minimum 5.73GB
Result to desired latency: 8.6GHz

Пример (Память) 2:

Current Latency = 1000
Desired Latency = 500
Latency Variable = 1 + (1 / (1000 / 500)) = 1.5
Current_Memory_Usage = 50%
Current_Capability = 4GB
Y_Years (to next upgrade) = 3
Growth_Percentage = 10%
Desired_Max_Usage_Percentage = 75%

Minimum Resource = (.5 x 4.0) + (1 x (3 x .1))/.75 =3.73GB
Adjustment For Latency = 3.73 x 1.5 = 5.23GB

Result: No need to upgrade
Result to desired latency: 5.23GB

Примечание: пожалуйста, относитесь к моим примерам с недоверием.

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

TL: DR; Если использование ЦП или памяти достигает 100%, вам, вероятно, следует разделить службы IIS и SQL на их собственные ресурсы. Однако перед этим следует рассмотреть возможность настройки приложения / ресурсов, поскольку изменение оборудования может быть дорогостоящим и не устранит неэффективные приложения.