forked from v.moiseev/distributed-computing
Compare commits
1 Commits
zinoveva-a
...
zinoveva-a
| Author | SHA1 | Date | |
|---|---|---|---|
| 344ae488f6 |
@@ -1,57 +0,0 @@
|
||||
# Отчет по лабораторной работе №7
|
||||
|
||||
Выполнила студентка гр. ИСЭбд-41 Зиновьева А. Д.
|
||||
|
||||
## Какие алгоритмы и методы используются для балансировки нагрузки?
|
||||
|
||||
Балансировка нагрузки - это процесс распределения рабочих задач между серверами или ресурсами, чтобы оптимизировать производительность и обеспечить стабильную работу системы. Алгоритмы и методы, которые используются для балансировки нагрузки:
|
||||
|
||||
1. Round-Robin DNS (Round Robin): Клиент отправляет DNS-запрос для определенного домена, DNS-сервер отвечает клиенту, возвращает список IP-адресов серверов, связанных с этим доменом, обеспечивая равномерное распределение нагрузки.
|
||||
|
||||
2. Весовая балансировка (Weighted Round Robin): У каждого сервера устанавливается вес. Список серверов и их весов сохраняется в балансировщике нагрузки. DNS возвращает IP-адреса в зависимости от их веса, который может быть связан с производительностью сервера, нагрузка получается гибко распределенной.
|
||||
|
||||
3. Распределенная хэш-функция (Distributed Hash Tables, DHT): Каждый сервер отвечает за свою часть IP-пространства, что позволяет быстро и эффективно распределять нагрузку.
|
||||
|
||||
4. Балансировка на основе IP: Когда клиент отправляет запрос на сервер, пакет данных включает IP-адрес, запрос клиента попадает на балансировщик нагрузки, который анализирует IP для определения, на какой сервер направить запрос. Трафик получается равномерным.
|
||||
|
||||
5. Балансировка на основе порта: Сервер балансировки определяет, на какой порт отправить запрос, исходя из информации о портах, полученных от клиента.
|
||||
|
||||
6. Балансировка с использованием состояния (Stateful Load Balancing): Сервер балансировки учитывает состояние каждого сервера, чтобы определить, какой из них наиболее подходит для обработки запроса.
|
||||
|
||||
Оптимальный выбор алгоритма или метода для балансировки нагрузки будет зависеть от конкретных требований и характеристик системы.
|
||||
|
||||
## Какие открытые технологии существуют для балансировки нагрузки?
|
||||
|
||||
1. NGINX: популярный веб-сервер и обратный прокси, который может выполнять функции балансировки нагрузки. Он распределяет трафик между несколькими серверами, поддерживает разные алгоритмов балансировки нагрузки и имеет гибко настраивается.
|
||||
|
||||
2. HAProxy: работает на уровне TCP/HTTP. Программа предоставляет возможность балансировки нагрузки между серверами приложений. Она обеспечивает высокую производительность, поддерживает много различных протоколов. (также поддерживает SSL)
|
||||
|
||||
3. Apache HTTP Server: этот веб-сервер с функциями балансировки нагрузки. У него есть модуль mod_proxy_balancer, он позволяет распределить трафик между несколькими серверами.
|
||||
|
||||
4. IPVS (IP Virtual Server): модуль ядра Linux, который обеспечивает балансировку нагрузки на уровне IP. Он позволяет распределять трафик между несколькими серверами на основе разных алгоритмов.
|
||||
|
||||
Каждая из них имеет свои плюсы и минусы.
|
||||
|
||||
## Как осуществляется балансировка нагрузки на базах данных?
|
||||
|
||||
Балансировка нагрузки на базах данных может быть сложной задачей, так как базы данных являются критическими компонентами веб-приложений. Однако, есть несколько подходов и методов, которые помогают решить эту задачу:
|
||||
|
||||
1. Репликация данных - процесс создания копий базы данных на нескольких серверах. Один сервер назначается сервером мастер, который принимает записи, а остальные серверы являются серверами слейвами, которые получают обновления из мастер-сервера. Запросы на чтение могут быть перенаправлены на любой из серверов слейвов, распределяя нагрузку между ними.
|
||||
|
||||
2. Шардинг - разбиения базы данных на несколько независимых фрагментов (шарды) и их распределение по разным серверам/узлам. Каждый шард содержит только часть данных, и клиенты направляют запросы к соответствующему шарду. Это позволяет распределить нагрузку между серверами.
|
||||
|
||||
3. Подходы на основе запросов - эти методы используются для маршрутизации запросов БД на основе типа запроса или определенных правил. Например, можно настроить прокси-сервер или брокер сообщений для маршрутизации запросов к соответствующим серверам БД.
|
||||
|
||||
## Реверс-прокси как один из элементов балансировки нагрузки.
|
||||
|
||||
Реверс-прокси - это сервер, расположенный между клиентом и серверами БД, и его главная задача заключается в перенаправлении запросов от клиента к соответствующим серверам БД.
|
||||
|
||||
Реверс-прокси выполняет функции:
|
||||
1. Балансировка нагрузки;
|
||||
2. Кеширование;
|
||||
3. Шифрование и безопасность (SSL);
|
||||
4. Обработка статических файлов;
|
||||
5. Фильтрация запросов;
|
||||
6. Обратная маршрутизация.
|
||||
|
||||
Использование реверс-прокси позволяет более эффективно распределить нагрузку, улучшить производительность и обеспечить безопасность.
|
||||
62
tasks/zinoveva-ad/lab_8/README.md
Normal file
62
tasks/zinoveva-ad/lab_8/README.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Отчет по лабораторной работе №8
|
||||
|
||||
Выполнила студентка гр. ИСЭбд-41 Зиновьева А. Д.
|
||||
|
||||
## Зачем сложные системы (например, социальная сеть ВКонтакте) пишутся в "распределенном" стиле, где каждое отдельное приложение (или сервис) функционально выполняет только ограниченный спектр задач?
|
||||
|
||||
Существует несколько причин, почему сложные системы, такие как социальные сети, пишутся в распределенном стиле с разделением функциональности:
|
||||
|
||||
1. Распределение нагрузки: Распределенный подход позволяет равномерно распределять нагрузку между разными серверами или сервисами. Это позволяет обеспечить масштабируемость системы и обрабатывать большое количество запросов от пользователей.
|
||||
|
||||
2. Изоляция сбоев: Когда функциональность разделена на отдельные сервисы, сбой в одном сервисе не влияет на работу других. Это повышает отказоустойчивость системы в случае возникновения проблем.
|
||||
|
||||
4. Гибкость и масштабируемость: Распределенный стиль позволяет добавлять или изменять сервисы независимо друг от друга. Это делает систему гибкой и позволяет ей масштабироваться в соответствии с развитием бизнеса и потребностями пользователей.
|
||||
|
||||
## Для чего были созданы системы оркестрации приложений? Каким образом они упрощают / усложняют разработку и сопровождение распределенных систем?
|
||||
|
||||
Системы оркестрации приложений - это инструменты, которые упрощают разработку, развертывание и управление распределенными приложениями и сервисами. Они помогают автоматизировать масштабирование, управление конфигурацией, мониторинг, масштабирование и отказоустойчивость системы. Однако, они также могут быть сложными и требовать дополнительных знаний и усилий для изучения и понимания их работы.
|
||||
|
||||
Сложности:
|
||||
1. Понимание и использование систем оркестрации требует времени и усилий для изучения и освоения.
|
||||
2. Системы оркестрации могут иметь свои ограничения и требования к структуре и формату приложений. Она требует совместимости и настройки между различными компонентами системы.
|
||||
|
||||
## Для чего нужны очереди обработки сообщений и что может подразумеваться под сообщениями?
|
||||
|
||||
Очереди обработки сообщений используются для организации и управления потоком информации между разными компонентами или сервисами в распределенной системе. Они позволяют организовать эффективную обработку сообщений, упорядочивая их и обеспечивая их последовательную обработку.
|
||||
|
||||
"Сообщение" может иметь различные значения.
|
||||
|
||||
Это могут быть:
|
||||
1. Запросы на выполнение определенных операций;
|
||||
2. Данные для обработки;
|
||||
3. Уведомления о событиях.
|
||||
|
||||
Очереди обработки сообщений позволяют приложениям эффективно обрабатывать и передавать сообщения, гарантируя их сохранность, упорядоченность и последовательную обработку.
|
||||
|
||||
## Какие преимущества и недостатки распределенных приложений существуют на Ваш взгляд?
|
||||
|
||||
Преимущества:
|
||||
1. Масштабируемость: Распределенные приложения могут легко масштабироваться горизонтально путем добавления новых узлов.
|
||||
2. Отказоустойчивость: Если один узел выходит из строя, остальные узлы продолжают работать, что обеспечивает высокую доступность системы.
|
||||
2. Надежность: Распределенные приложения могут быть устойчивыми к отказу одного или нескольких узлов.
|
||||
4. Улучшенная производительность: Распределенные приложения могут распределять нагрузку между узлами системы, что позволяет эффективно использовать ресурсы и достигать более высокой производительности.
|
||||
|
||||
Недостатки:
|
||||
1. Сложность разработки: из-за необходимости управления, синхронизации и т.д.
|
||||
2. Задержки: могут быть адержки связи из-за необходимости передачи данных по сети.
|
||||
|
||||
## Целесообразно ли в сложную распределенную систему внедрять параллельные вычисления? Приведите примеры, когда это действительно нужно, а когда нет.
|
||||
|
||||
Внедрение параллельных вычислений в распределенную систему может быть целесообразно в определенных случаях.
|
||||
|
||||
Примеры, когда внедрение параллельных вычислений действительно нужно:
|
||||
|
||||
1. Когда нужна обработка больших объемов данных, сложные вычисления.
|
||||
2. Когда требуется повысить производительность и отзывчивость.
|
||||
3. Когда требуется обслуживать большое количество одновременных запросов пользователей
|
||||
|
||||
Примеры, когда внедрение параллельных вычислений не обязательно:
|
||||
|
||||
1. Когда не требуется вычислительная мощность;
|
||||
2. Когда задачи сильно зависят друг от друга и не могут быть эффективно разделены на подзадачи;
|
||||
3. Когда внедрение может добавить сложности в разработке.
|
||||
Reference in New Issue
Block a user