Недавно меня спросили: «Знаете ли вы, когда следует выбирать между увеличением оперативной памяти и увеличением числа серверов?» (в контексте масштабирования приложений для интеллектуального анализа данных).
Я понятия не имел, так какие есть способы решить? У меня очень мало знаний об архитектуре и масштабировании (мое понимание компьютерной памяти и того, что делает сервер, ограничено высокоуровневыми основами), поэтому советы по изучению этих вещей в целом также очень приветствуются.
решение1
«Знаете ли вы, когда следует выбирать между увеличением оперативной памяти и увеличением числа серверов?» (в контексте масштабирования приложений для интеллектуального анализа данных).
Ответ: как только вы дадите мне метрики для рассматриваемого сервера, я скажу вам, какие (или стоит ли вообще добавлять что-либо). Этот тип настройки — не вуду (если только вы не используете приложения без инструментария и серверные ОС без инструментария — тогда да, это вуду), это наука. Измерьте приложение и сервер. В двух словах, используя метрики мониторинга, выясните, где узкое место производительности, и добавьте его.
решение2
В улучшении производительности серверов/приложений обычно присутствует немало магии (или, по крайней мере, метода проб и ошибок).
Общее правило для конкретного заданного вопроса — сначала увеличивать память до тех пор, пока ее уже невозможно будет увеличить.ИЛИпока больше памяти не перестанет повышать производительность. При относительно дешевой памяти может быть проще просто максимизировать память. Кроме того, если приложение загружает диск, обновление до высокоскоростных дисков или высокопроизводительных контроллеров может иметь значение.
Однако, очень общая природа вопроса заставляет меня думать, что других попыток улучшить производительность не было. Я согласен, что оборудование дешево, поэтому даже добавление большего количества серверов для решения проблемы достаточно легко. Но я бы также убедился, что были выполнены другие пути, в частности настройка ОС и базы данных. Иногда небольшие изменения в базе данных, ОС или даже конфигурации приложения могут привести к огромному повышению производительности.
Поищите на этом сайте информацию о вашей конкретной ОС, базе данных и приложении, и, возможно, вы найдете золотую жилу.
решение3
Как архитектор предприятия я сталкиваюсь с этой проблемой почти ежедневно. Вертикальное или горизонтальное масштабирование?
Каковы ваши потребности?
Вам нужно поддерживать больше пользователей? Вам нужно повысить скорость обслуживания? Вам нужно и то, и другое? Вам нужна высокая доступность 99.9999 или ваши пользователи могут позволить себе простои?
Для начала вам нужно зафиксировать показатели производительности текущей системы. Количество активных пользователей, загрузка ОЗУ и ЦП, дисковый ввод-вывод — узнайте, где у вас узкие места.
Возможные решения на основе проблем: Начните с оптимизации текущих ресурсов. Если ваше приложение управляется базой данных, оптимизируйте базу данных с помощью кэшей запросов и потоков, индексов и т. д. Если вы используете сервер совместно с другими приложениями, рассмотрите возможность перехода на выделенный сервер. (Рассмотрите возможность виртуализации для менее активных/критических приложений, чтобы освободить выделенные ресурсы).
Текущие машины работают на полную мощность, ОЗУ и ЦП сильно загружены, большой объем дискового ввода-вывода — рассчитайте стоимость добавления ОЗУ, можно ли перейти на более быстрый дисковый ввод-вывод (RAID, SATA вместо ATA)?
Если вам нужна высокая доступность, то вам, вероятно, в любом случае придется добавить оборудование и балансировку нагрузки.
Что дешевле: добавить обновления оборудования или добавить новые серверы? Что соответствует долгосрочным целям и росту?
Когда вашему ИТ-отделу лучше всего тратить деньги? У вас есть средства сейчас или вы хотите перенести расходы на другой квартал/год? Если средства являются проблемой, оптимизируйте сейчас или рассмотрите возможность освобождения оборудования от других приложений, чтобы добавить временное решение для балансировки нагрузки.
Не бойтесь исследовать многочисленные решения. Поставщики могут захотеть, чтобы вы купили сбалансированное по нагрузке решение для хранения данных SAN, где новый сервер с iSCSI RAID 10 на борту будет работать за 10 процентов от стоимости.
Если ваш ЦП все еще сильно загружен после оптимизации, то вам нужно добавить/заменить оборудование. Если ваш дисковый ввод/вывод является узким местом и вы не можете обновить технологию хранения, то вам нужно заменить оборудование или добавить сетевое хранилище/присоединенные решения для хранения.
Захватите показатели производительности. Оптимизируйте, улучшите и снова захватите показатели. Продолжайте документировать увеличение/уменьшение производительности, чтобы вы могли предоставить отчет, в котором будет указано, сколько вы потратили и какой прирост производительности был получен. Это тот тип возможных историй успеха, которые превращают администраторов в архитекторов, архитекторов в менеджеров проектов, а менеджеров проектов в высшее руководство, если все сделано правильно.
решение4
ОЗУ стоит дёшево. Всегда следует сначала увеличивать его до точки, где у вас будет самое экономичное количество (например, 4 ГБ DIMM слишком дороги, поэтому я бы не стал с ними заморачиваться).
Затем изучите масштабирование вбок (больше серверов). Рассмотрите дешевое потребительское оборудование против дорогих серверных частей, но будьте готовы к отказам и включайте оценки отказоустойчивости в общую вычислительную мощность.
По сути,сделать Google.