Могут ли сервер базы данных и веб-сервер находиться на одном компьютере

Обновлено: 21.11.2024

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

Небольшие приложения обычно начинаются с одного сервера, на котором есть и MySQL, и веб-сервер. В этом случае это обычно не вопрос, но как только приложение разрастется и вам понадобится несколько серверов, вы можете решить, что эфир будет расширять систему в парах MySQL+Apache или разделить MySQL и веб-сервер и поместить их в разные блоки.

Как правило, рекомендуется использовать отдельные блоки для MySQL и веб-серверов.

Это более безопасно: компрометация вашего веб-сервера не дает прямого доступа к вашей базе данных, даже несмотря на то, что большинство приложений имеют достаточно разрешений на доступ к базе данных, чтобы позволить злоумышленнику удалить или сбросить данные.

Легче анализировать. Устранение узких мест в общих ящиках сложнее по сравнению с системами, работающими только с MySQL или только с веб-сервером. В этом случае вы уже знаете, кто создает проблемы, просто взглянув на общесистемную статистику.

Легче обслуживать. То же самое, если на коробке работает несколько вещей, которые сложнее обслуживать. Хотя я бы не назвал разницу существенной в данном случае.

Легче сбалансировать. Допустим, у вас есть веб-приложение, и вы только что добавили какую-то новую функцию, например, приложение для чата, которое увеличивает нагрузку на ваш веб-сервер, но на самом деле не влияет на часть нагрузки на базу данных. Если вы можете управлять фермой баз данных и фермой веб-серверов отдельно, вы можете просто увеличить количество веб-серверов.

Это менее затратно. Как правило, вы хотите, чтобы блоки базы данных были безопасными, используя хорошее оборудование с памятью ECC, чтобы избежать повреждения базы данных, использовать RAID, чтобы избежать потери базы данных из-за потери жесткого диска и т. д. Блоки базы данных также обычно требуют большего мониторинга и обслуживания. таких как резервные копии, так что вы в конечном итоге используете серьезное оборудование для этих ящиков, чтобы
управлять их числом. С веб-боксами все по-другому — вы вполне можете использовать дрянное оборудование для них, поскольку все, что вам нужно, это мощность процессора. Если коробка начинает работать неправильно, ее легко отключить, не влияя на работу сайта. Кроме того, у вас редко будет повреждение данных из-за сбоя памяти веб-боксов, более вероятно, что у вас будут сбои веб-сервера и тому подобное. Вы можете просто клонировать веб-серверы с жесткого диска шаблона или даже сделать так, чтобы они загружались без диска с помощью NFS.

Так что, если использование выделенных ящиков так здорово, зачем вообще думать о совместном использовании MySQL и веб-сервера? Ну в основном это для дешевых парней.
Во многих приложениях вы обнаружите, что серверы баз данных привязаны к операциям ввода-вывода, поэтому процессоры практически ничего не делают, а вы тратите ресурсы впустую. Это причина того, что в некоторых дешевых средах веб-серверы также находятся в блоках баз данных, которые могут обрабатывать только частичную нагрузку и т. д.

Однако я бы использовал его только в крайнем случае — размещение некоторых скриптов обработки данных на сервере базы данных часто лучше использует их свободное процессорное время.

Вторая вещь, которая может вас расстроить, — это память веб-серверов. Получение определенного объема памяти довольно дешево, т.е. 4 ГБ памяти на коробку стоят очень близко к 2 ГБ, а переход с 16 ГБ на 32 ГБ может быть намного дороже (даже в цене на ГБ).
Таким образом, вы можете получить веб-боксы с относительно большим объемом памяти дешево, но если вы не используете 500 дочерних элементов Apache с mod_P (php,perl,python) на каждый блок (что в любом случае, вероятно, плохая идея).

Хорошим применением такой дополнительной памяти, вероятно, является кэширование. Кэширование веб-страницы, если у вас нет для нее отдельного уровня, локальная память или тип кэширования кэширования (в зависимости от потребностей вашего приложения) очень хорошая идея.

Еще одним преимуществом локального доступа к MySQL является задержка. Это было проблемой много лет назад с 10-мегабитной сетью, но с 1-гигабитными сетями, которые в наши дни стали обычным явлением, вам не следует слишком беспокоиться об этом, если только у вас нет каждой страницы, сгенерированной более чем 1000 запросов, что уже является плохой идеей.

Одним случаем, который я должен упомянуть, когда совместное использование MySQL и веб-сервера имеет смысл, является архитектура веб-сервисов, когда у вас могут быть определенные блоки, предоставляющие вам несколько простых «служб» — они могут быть достаточно малы, чтобы быть одним общим блоком (или парой общих коробки для ГК). В таких случаях я бы подумал, что веб-сервер в основном является поставщиком другого протокола для доступа к вашим данным — обычно он прост и не требует много ресурсов ЦП и других ресурсов.

Кажется, что в жизни было бы просто запустить сервер базы данных на том же компьютере, что и веб-сервер, но сильно ли мы рискуем, делая это?

Средой будет сервер Windows 2008, Postgresql (последняя версия, возможно, 9.0, когда она выйдет) и Apache 2.

5 ответов 5

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

(Предполагая разумные меры безопасности, такие как mysqld, не принимающий вход root без пароля с локального хоста.)

При этом вы все же можете запустить отдельный сервер базы данных. Причина этого связана с производительностью, масштабируемостью и т. д.

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

Я не согласен с плакатами, утверждающими, что это не проблема безопасности, и вот почему:

  • Ваш фронтальный сервис должен иметь наименьшую возможную поверхность атаки. Это основная причина использования обратных прокси-серверов и брандмауэров, а также хранения ненужных служб и программ вдали от серверов, которые не требуют их работы. Вот почему веб-серверы чаще всего становятся объектами для усиления безопасности.
  • Ваш веб-сервер не должен иметь прав доступа к вашей системе баз данных. Таким образом, компрометация веб-сервера не компрометирует и сервер базы данных. Во-первых, учетная запись, которую веб-сервер использует для доступа к базе данных, не должна иметь прав локального администратора на поле SQL, ее права должны ограничиваться исключительно разрешениями базы данных. Во-вторых, в рамках этих разрешений SQL он должен работать по принципу наименьших привилегий. Например, ваш веб-бокс не должен создавать экземпляры новых баз данных в экземпляре. В идеале ваш веб-бокс не будет иметь возможности удалять таблицы или удалять строки из любых таблиц, если в этом нет абсолютной необходимости. Таким образом, в случае компрометации в правильно настроенной двухуровневой конфигурации влияние злоумышленника, использующего учетные данные SQL, ограничено.

Я не думаю, что кто-то говорит, что двухкомпонентное решение небезопаснее. Однако вопрос заключался в том, был ли этот риск, выражаясь словами, "большим". Ответ, очевидно, будет зависеть от обстоятельств — например, я бы не стал запускать банковский сайт с выходом в Интернет на одной машине. Но должным образом заблокированный веб-сервер, однажды скомпрометированный, не должен иметь больше или меньше доступа к своему серверу базы данных, чем он имел до взлома, и этот принцип не зависит от того, находится ли решение на двух машинах или на одной. Если это не так, пришло время изменить архитектуру системы.

Я не понимаю вашей логики. Если вы скомпрометируете веб-сервер и получите root права на эту машину, у вас будет все, что на ней есть. Если это включает всю вашу базу данных со всеми ее данными, то все скомпрометировано. Но если у вас есть 2 отдельных сервера, то полная компрометация веб-сервера в любой степени даст вам доступ на уровне данных только к тем данным, которые были доступны самому веб-серверу.

На самом деле это будет зависеть от модели безопасности ваших веб-серверов и серверов БД (то есть программного обеспечения), а также от степени защиты брандмауэра/контроля доступа/IDP, которую вы бы применяли на двух серверах, если бы они находились на разных серверах.

При прочих равных условиях вероятно лучше разделить их. Однако на практике, по крайней мере, в среде LAMP, если вы используете privsep Apache (если вы не уверены, не волнуйтесь, это так) и не используете root-логин в MySQL в своем веб-приложении, и у вас нет tcp/3306, доступного для внешнего мира, вы на самом деле не получаете много безопасности, перенося один или другой на другой кусок кремния. Тем не менее, вы получаете преимущества производительности и возможности отладки.

Ваш вопрос в том стиле, который, кажется, требует абсолютного ответа, но без дополнительной информации (как минимум, о каких ОС и разновидностях веб-сервера/БД мы говорим) трудно даже дать информативный ответ.< /p>

Мы будем использовать: Windows Server 2008 и Postgresql 8.4 (или 9.0, когда он выйдет), Apache 2

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

Тем не менее, их разделение является хорошей практикой. Каждый сервер проще в управлении и настройке, и вы можете легче справляться со сбоями, проблемами, перестройками, проблемами с производительностью и т. д., продвигаясь вперед. Таким образом, вы можете рассмотреть два виртуальных сервера на одном оборудовании, которые затем можно разделить, если этого требуют производительность или емкость.

Я бы не стал, но это я.

Это зависит от того, что находится перед вашим устройством (например, брандмауэры, балансировщики нагрузки и т. д.) и насколько они «герметичны», каковы фактические данные (т. е. общедоступные данные о текущем влиянии на одном конце, другой), влияет ли их сочетание на производительность, надежность сети между ними обоими (т. е. межуровневые брандмауэры) и качество защиты ОС/приложений, которое будет применяться.

Если вы не ожидаете, что эта система будет иметь дело со слишком большой нагрузкой, вы можете подумать о том, чтобы виртуализировать систему на две отдельные виртуальные машины; по одному на функцию - возможно, даже с третьей виртуальной машиной брандмауэра только для программного обеспечения между ними. Это будет означать, что даже если кто-то взломает ваш веб-сервер, ему придется взломать сервер базы данных и, если он есть, промежуточную виртуальную машину брандмауэра. Конечно, это снизит общую производительность системы, но будет, по крайней мере, в некоторой степени более безопасным, а также может помочь, если ваша нагрузка когда-либо возрастет до требуемой конструкции с двумя серверами, поскольку вы можете просто переместить одну виртуальную машину на вторую машину. Бесплатный продукт VMWare ESXi может сделать все это довольно легко, и уже есть бесплатные виртуальные машины брандмауэра, предварительно упакованные и готовые к внедрению, если вы хотите.

Прослушивая интервью Скотта Хансельмана с командой Stack Overflow (части 1 и 2), он был непреклонен в том, что сервер SQL и сервер приложений должны находиться на разных компьютерах. Это просто для того, чтобы убедиться, что если один сервер скомпрометирован, обе системы будут недоступны? Перевешивают ли проблемы безопасности сложность двух серверов (дополнительные расходы, выделенное сетевое соединение между ними, дополнительное обслуживание и т. д.), особенно для небольшого приложения, где ни одна из частей не использует слишком много ресурсов ЦП или памяти? Даже с двумя серверами, один из которых скомпрометирован, злоумышленник все равно может нанести серьезный ущерб, либо удалив базу данных, либо вмешавшись в код приложения.

Почему это так важно, если производительность не является проблемой?

Я считаю, что есть одна проблема, которая полностью опущена во всей этой ветке, и вопрос, который в значительной степени отменяет эту рекомендацию. Что, если вы получите доступ к учетным данным базы данных, но не к серверу. Если база данных и приложение размещены на одном компьютере, вы можете запретить любой внешний доступ к базе данных, и поэтому только наличие учетных данных базы данных не дает вам никакого доступа, для этого вам потребуется доступ к серверу. И это на одну проблему безопасности меньше, если вы спросите меня.

19 ответов 19

  1. Безопасность. Ваш веб-сервер находится в демилитаризованной зоне, доступной для общедоступного Интернета и принимающей ненадежные данные от анонимных пользователей. Если ваш веб-сервер скомпрометирован, и вы следовали правилам наименьших привилегий при подключении к базе данных, максимальное воздействие — это то, что ваше приложение может делать через API базы данных. Если у вас есть промежуточный бизнес-уровень, у вас есть еще один шаг между вашим злоумышленником и вашими данными. С другой стороны, если ваша база данных находится на том же сервере, злоумышленник теперь имеет root-доступ к вашим данным и серверу.
  2. Масштабируемость. Сохранение состояния вашего веб-сервера позволяет вам без особых усилий масштабировать ваши веб-серверы по горизонтали. Горизонтально масштабировать сервер базы данных очень сложно.
  3. Производительность. 2 блока = в 2 раза больше ЦП, в 2 раза больше ОЗУ и в 2 раза больше шпинделей для доступа к диску.

Все это говорит о том, что я вижу разумные случаи, когда ни один из этих пунктов не имеет значения.

Ссылка. пункт 1. Если веб-уровень находится в собственности, то что еще вам нужно или нужно, кроме интерфейса API приложения/базы данных? В любом случае, игра окончена? Затем все становится очень интересно с точки зрения сервисов, необходимых для поддержки инфраструктуры DMZ, например, каких-либо сервисов AD или Microsoft?

@kirgy — поскольку две машины работают параллельно и каждая из них является единой точкой отказа, общая надежность меньше; технически это не двойное (на самом деле это 1 - (r1 * r2)), но достаточно близкое для большой надежности и небольших узлов. В случае 0,01% это будет 0,0199%. Но для 100 узлов это будет 36,6 % вместо 100 %, подразумеваемых оператором удвоения.

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

Это именно то, что сделал StackOverflow: начиная с одной машины с IIS/SQL Server, затем, когда она начала сильно загружаться, был куплен второй сервер, и сервер SQL был перенесен на него.

Если производительность не является проблемой, не тратьте деньги на покупку/обслуживание двух серверов.

Согласен, это можно сделать и при низкой нагрузке. по мере увеличения нагрузки их легко разделить на 2 или более машин.

Я зашел и собирался прокомментировать то же самое. Переключить сервер БД так же просто, как изменить строку подключения (в большинстве случаев).

Это правильный ответ. Начните с одного сервера и перемещайте базу данных только тогда, когда ваш сервер больше не может справляться с нагрузкой.

С другой стороны, ссылаясь на другого блоггера Скотта (Watermasyck, Telligent), они обнаружили, что большинство пользователей могут ускорить работу веб-сайтов (используя сервер сообщества Telligent), разместив базу данных на том же компьютере, что и веб-сайт. . Однако в случае их клиента обычно db и веб-сервер являются единственными приложениями на этой машине, и веб-сайт не так сильно нагружает машину.Кроме того, отсутствие необходимости отправлять данные по сети компенсировало повышенную нагрузку.

<р>. до тех пор, пока одновременное использование не увеличится, и серверу БД потребуется больше памяти для эффективного использования буферов и кешей. Когда веб-серверам/серверам приложений и базам данных требуется больше памяти, чем они могут использовать в одном устройстве, объем операций подкачки и дискового ввода-вывода увеличивается, а производительность снижается.

@MattK, но что, если у вас огромный объем памяти? У нас есть приложение, в котором у каждого клиента есть собственная база данных, поэтому и база данных, и веб-серверы могут очень легко масштабироваться по горизонтали. Учитывая, что у нас больше памяти, чем используемого диска (64 ГБ против ~ 40 ГБ), не будет ли лучше для производительности хранить все это на одном компьютере?

Если ваш рабочий набор умещается в памяти, вы можете не заметить проблем с производительностью, о которых я упоминал. Чаще серверы имеют больше дискового пространства, чем ОЗУ, но похоже, что в вашем случае у вас есть базы данных, которые полностью помещаются в ОЗУ — до тех пор, пока приложения на общем сервере не потребляют слишком много ее.

Том прав. Некоторые другие причины заключаются в том, что это неэффективно с точки зрения затрат и что существуют дополнительные риски для безопасности.

Веб-серверы имеют другие требования к оборудованию, чем серверы баз данных. Серверы баз данных работают лучше с большим объемом памяти и действительно быстрым дисковым массивом, в то время как веб-серверам требуется достаточно памяти только для кэширования файлов и частых запросов к БД (в зависимости от вашей настройки). Что касается экономической эффективности, два сервера не обязательно будут дешевле, однако соотношение производительность/стоимость должно быть выше, поскольку вам не нужно, чтобы разные приложения конкурировали за ресурсы. По этой причине вам, вероятно, придется потратить гораздо больше на один сервер, который обслуживает оба и предлагает производительность, эквивалентную двум специализированным.

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

Кроме того, существуют некоторые преимущества масштабируемости, поскольку вам может потребоваться поддерживать только несколько серверов баз данных, которые используются множеством различных веб-приложений. Таким образом, у вас будет меньше работы по установке обновлений или исправлений и настройке производительности. Я считаю, что существуют инструменты управления сервером, которые упрощают эти задачи (в случае с одной машиной).

MCSE 70-293: Планирование ролей сервера и безопасности сервера

Мартин Грасдал, . Д-р Томас В. Шиндер, технический редактор, учебное пособие MCSE (экзамен 70–293), 2003 г.

Серверы баз данных

Серверы баз данных используются для хранения баз данных, хранящихся на сервере, и управления ими, а также для предоставления доступа к данным авторизованным пользователям. Этот тип сервера хранит данные в центральном расположении, для которого можно регулярно создавать резервные копии. Это также позволяет пользователям и приложениям централизованно получать доступ к данным по сети. Большое количество баз данных, используемых в вашей организации, может храниться на одном сервере или группе серверов, специально настроенных для защиты данных и обслуживания запросов клиентов.

Мастер настройки сервера не включает настраиваемую роль для серверов баз данных. Сервер базы данных — это любой сервер, на котором выполняется сетевое приложение базы данных и поддерживаются файлы базы данных, такие как Microsoft SQL Server или Oracle. SQL Server — это высокопроизводительная система управления базами данных. Он используется для хранения и анализа данных и предоставляет пользователям возможность быстрого доступа к огромным объемам данных по сети. Поскольку SQL Server обеспечивает дополнительные меры безопасности, которые в противном случае были бы недоступны (как описано в разделе «Защита серверов баз данных» далее в этой главе), а обработка выполняется на сервере, транзакции могут выполняться безопасно и быстро.

Доступ к данным, хранящимся в системах управления базами данных, обычно осуществляется через пользовательские интерфейсы, разработанные организацией или третьими сторонами. Например, компания может создавать собственные приложения на Visual Basic (или другом языке программирования) или использовать ASP на веб-сервере для отображения информации, хранящейся в базе данных. Пока пользователь взаимодействует с данными через пользовательский интерфейс, данные фактически хранятся в базе данных SQL Server или Oracle, расположенной на сервере баз данных.

Классификация серверов

III.B.1. Описание

Серверы баз данных — это сетевые компьютеры в сети, предназначенные для хранения базы данных и извлечения данных из базы данных. Сервер базы данных является ключевым компонентом вычислительной среды клиент/сервер. Он содержит систему управления базами данных (СУБД) и базы данных. В контексте базы данных клиент управляет пользовательским интерфейсом и логикой приложения, действуя как сложная рабочая станция, на которой выполняются приложения базы данных. Клиент принимает запрос пользователя, проверяет синтаксис и генерирует запросы к базе данных на языке SQL или другом языке базы данных.Затем он передает сообщение на сервер, ждет ответа и форматирует ответ для конечного пользователя. Сервер принимает и обрабатывает запросы к базе данных, а затем передает результаты обратно клиенту. Этот процесс включает в себя проверку авторизации, обеспечение целостности системного каталога и выполнение запроса и процесса обновления.

Миграция на Sybase с точки зрения системного интегратора и пример из практики

Том Лашевски, Пракаш Наудури, Миграция в облако, 2012 г.

Сервер базы данных

Серверы баз данных Sybase состоят из сервера данных и сервера резервного копирования. Существует два процесса сервера базы данных Sybase, тогда как экземпляр Oracle имеет пять обязательных процессов: SMON (системный монитор), PMON (монитор процесса), LGWR (программа записи журнала), DBWR (программа записи базы данных) и CKPT (контрольная точка). Необязательный процесс архивирования ARCH записывает заполненные журналы повторного выполнения в расположение(я) архивного журнала. В Oracle Real Application Cluster (RAC) можно использовать различные процессы ARCH, чтобы обеспечить доступность копий архивных журналов повторного выполнения для каждого экземпляра для других экземпляров в настройке RAC, если они потребуются для восстановления. Дополнительные фоновые процессы Oracle включают процессор очереди заданий CJQ, контроллер очереди заданий CQJ0, библиотеки сопоставления FMON, диспетчер блокировки LMON и сборщик MMON для AWR (автоматического репозитория рабочей нагрузки). Полезно понимать различия серверной архитектуры между этими двумя базами данных; однако эти различия не окажут отрицательного влияния на ваш проект миграции и оценки.

Ключевое отличие состоит в том, что ядро ​​данных Sybase может иметь несколько баз данных в рамках одного ядра. Oracle, с другой стороны, имеет одну базу данных для всего механизма обработки данных. Это может привести к тому, что клиенты поверят, что им необходимо создать сервер базы данных Oracle для каждой базы данных Sybase. Это не так, поскольку в Oracle есть концепция схем (т. е. пользователя базы данных). Поэтому база данных Sybase сопоставляется со схемой Oracle.

Дизайн физического хранилища данных

8.4.3 Параметры памяти

Сервер базы данных использует физическую память для кэширования страниц с диска. В то время как операционные системы баз данных часто имеют дело с небольшими транзакциями, системы хранилищ данных имеют дело с большими запросами (имея в виду объем данных, затронутых запросом). Кроме того, запрос часто требует нескольких проходов для работы с большими таблицами; наличие таблицы, уже находящейся в памяти, может значительно улучшить производительность [23]. Если SQL Server не имеет достаточно памяти для выполнения операции, он использует хранилище на жестком диске, например, используя файлы подкачки, базу данных tempdb или повторно считывая страницы базы данных с диска. Следовательно, чем больше оперативной памяти система хранилища данных предоставляет Microsoft SQL Server, тем лучше.

Защита на уровне платформы

Отозвать ПУБЛИЧНЫЕ разрешения

Каждая платформа сервера базы данных имеет роль по умолчанию, которой принадлежит каждый вход в систему, обычно называемую общедоступной ролью, которая имеет набор разрешений по умолчанию, включая доступ к системным объектам. Злоумышленники могут использовать этот доступ по умолчанию для запроса метаданных базы данных, чтобы отобразить схему базы данных и нацелиться на самые важные таблицы для последующего запроса, например те, которые хранят учетные данные для входа в приложение. Общедоступной роли также обычно назначаются разрешения на выполнение встроенных системных хранимых процедур, пакетов и функций, используемых в административных целях.

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

Ссылки

Выполнение системной команды

Для серверов баз данных PostgreSQL до Версии 8.2 можно использовать следующий SQL для импорта системной функции из стандартной библиотеки UNIX libc:

СОЗДАТЬ ИЛИ ЗАМЕНИТЬ ФУНКЦИЮ system(cstring) ВОЗВРАЩАЕТ int AS '/lib/libc.so.6',

'system' LANGUAGE 'C' STRICT;

Затем системную функцию можно вызвать, выполнив следующий SQL-запрос:

Текущие версии Postgres требуют, чтобы внешние библиотеки были скомпилированы с макросом PostgreSQL PG_MODULE_MAGIC. Чтобы выполнить код с помощью этого метода, вам потребуется загрузить собственный общий файл .so или .dll с включенным соответствующим макросом PG_MODULE_MAGIC. Дополнительную информацию см. в следующем ресурсе:

Установка GFI EventsManager

Настройка серверной базы данных

Первым шагом в процессе первоначальной настройки является настройка серверной базы данных SQL Server. Как я упоминал ранее, я буду настраивать GFI EventsManager для использования базы данных SQL Server 2005 Developers Edition, а не базы данных SQL 2005 Express Edition. Имейте в виду, что другие версии SQL Server также поддерживаются и что база данных SQL Server не обязательно должна находиться локально.

Чтобы настроить базу данных SQL Server, выполните следующие действия:

Нажмите ссылку "Нажмите здесь, чтобы настроить" в разделе "Настройка серверной части базы данных SQL Server".

Теперь Windows отобразит страницу свойств базы данных, в которой вам будет предложено ввести имя сервера и базы данных, которые вы хотите использовать. Введите либо имя, либо IP-адрес вашего сервера базы данных, затем обратную косую черту, а затем имя экземпляра базы данных. Например, у меня есть экземпляр SQL Server с именем GFI, установленный на моем локальном сервере. Поэтому я использую GFI\GFI в качестве имени сервера. Если ваша база данных не установлена ​​локально, просто замените [local] именем NetBIOS или IP-адресом вашего сервера базы данных.

Введите EventsManager в поле базы данных.

Выберите вариант проверки подлинности Windows, как показано на рис. 13.4.

Нажмите "ОК".

GFI EventsManager теперь создаст необходимую базу данных. Когда процесс завершится, нажмите OK.

Рисунок 13.4. Введите имя сервера и имя экземпляра SQL Server для сервера базы данных, который вы хотите использовать

Это скорее концептуальный вопрос о том, когда лучше всего выбросить сервер базы данных в его собственный дроплет.

Итак, допустим, у вас есть решение типа LAMP, работающее на дроплете 2vcpu/4GB, и вы считаете, что пришло время увеличить емкость. Удвоить размер капли легко, но правильно ли это? Создание отдельного сервера базы данных — это еще один вариант с некоторыми преимуществами и некоторыми недостатками.

  • Изолированная база данных не может быть остановлена ​​перегруженными процессами на веб-сервере/сервере приложений.
  • База данных дополнительно изолирована с точки зрения безопасности.
  • Диагностика проблем и мониторинг производительности упрощаются, поскольку веб-загрузка и загрузка базы данных разделены.
  • Упрощенное обслуживание и обновление, поскольку веб-приложение может быть направлено на новый или замещающий сервер базы данных, который уже протестирован и работает.
  • задержка в сети для запросов к серверу базы данных (тот же центр обработки данных)
  • меньше общей емкости для резкого увеличения потребности в ресурсах процессов веб-приложений или базы данных.

Я разделился пополам в отношении преимуществ и недостатков и подумал, что могу найти интересные и информативные мнения в сообществе DO.

Вы можете ввести !ref в этой текстовой области, чтобы быстро найти наш полный набор руководств, документации и предложений на рынке и вставить ссылку!

Эти ответы предоставлены нашим сообществом. Если вы найдете их полезными, проявите свою любовь, нажав на сердце. Если у вас возникнут проблемы, оставьте комментарий или добавьте свой ответ, чтобы помочь другим.

В дополнение к преимуществам, которые вы упомянули, еще одно, о чем я могу подумать, это то, что с отдельным сервером базы данных становится намного проще создавать другие приложения (или несколько экземпляров одного и того же веб-приложения, если оно не имеет состояния), конечные точки API , внутренние утилиты и т.д., которым нужно просматривать одни и те же данные. Если бы база данных находилась на том же сервере, что и веб-сервер, то весь этот другой трафик без необходимости конфликтовал бы с основным вариантом использования сервера — обслуживанием веб-трафика.

"Когда вы переместите свою базу данных на отдельный сервер?"

Ответ: "Вы узнаете".

А если серьезно, вы описали все преимущества и недостатки развертывания на собственной капле. Те же соображения могут быть сделаны при использовании размещенных решений DO, включая задержку и степень контроля над самой системой.

У нас была ситуация, когда мы размещали два балансировщика нагрузки перед 6 серверами nginx/PHP с поддержкой gluster поверх 2 серверов баз данных, сконфигурированных в активной/пассивной конфигурации. Он отлично справлялся с обработкой больших объемов трафика, а когда возникала проблема с одним из них, кластер не подвергался риску.

Я большой сторонник развертывания серверов для удовлетворения потребностей. Как сказал rsharma, это дает вам возможность добавлять экземпляры и получать доступ к этим данным из других источников. Хотя это все еще возможно с экземпляром на сервере, выигрыш ЦП/ресурсов на веб-сервере, на мой взгляд, того стоит.

Наконец, роскошь частных сетей, которые предлагает DO, облегчает мой разум, поскольку мне не нужно выставлять серверы на всеобщее обозрение, а задержка не вызывает беспокойства.Хотя вы не получите полного времени отклика базы данных на том же сервере, работа в частной сети в центре обработки данных сводит задержку к минимуму.

Читайте также: