Архив рубрики: хранение данных

Платформа для создания мощного файл-сервера или хранилища для СУБД на продажу

Продаем бывший в употреблении сервер Supermicro 4U с шасси, в которое можно установить до 72х 2.5″ SATA/SAS дисков HDD или SSD. В платформу установлен Xeon E3-1230 c 16 GB RAM и контроллер Adaptec 6805 с суперконденсатором. В сервер установлено 10 SATA дисков размером 500GB.

Платформа включает 3 независимых SAS-бэкплейна, каждый из которых может быть подключен к отдельному контроллеру. В нашей комплектации платформа позволяет подключить дополнительную полку каскадом, например, если вам 72 диска не хватило, или хотите подключить еще диски размером 3.5.

Сервер трудился в облаке CS1 и был снят с эксплуатации в связи с окончанием работы данного сервиса.

Для чего можно использовать:

  • производительный файл-сервер на дисках SATA/SAS;
  • хранилище для СУБД на дисках SSD;
  • хранилище томов для виртуальных машин;
  • DAS-хранилище для серверов.

В нагрузку предлагаем на выбор:

  • карту 8Gb FibreChannel;
  • карту 2x1Gb Ethernet.

Стоимость этого сервера 130 тысяч рублей, при безналичном расчете 143 тысячи рублей. Стоимость такой новой платформы (без RAID-контроллера, материнской платы, процессора и памяти) — 299 тысяч рублей.

Гарантия от нас — 2 месяца.

Объектное хранилище по протоколу S3

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

Читать далее

Настройка безопасности стека ELK с помощью Nginx

Стек ELK (стек Elastic) — это набор открытых программ, разработанных Elastic, которые позволяют выполнять поиск, анализ и визуализацию записей журналов.

Стек ELK состоит из четырех основных компонентов:

  • Elasticsearch. Распределенная поисковая система, доступная по RESTful протоколу, которая хранит все собранные данные.
  • Logstash. Компонент, осуществляющий предобработку, дополнение, фильтрацию и маршрутизацию загружаемых в Elasticsearch данных.
  • Kibana. Аналитическая и визуализационная система с web-интерфейсом, позволяющая выполнять комплексные запросы к Elasticsearch и отображать их результаты в виде таблиц и диаграмм.
  • Beats. Семейство легких специализированных отправителей данных, тесно интегрированных с Logstash и Elasticsearch.

Если вы следите за новостями об Elasticsearch, то могли слышать о ряде случаев раскрытия конфиденциальных данных, хранящихся в кластерах Elasticsearch. Вот только некоторые ссылки на статьи: Equifax, CITI, AIESEC.

Поскольку Elasticsearch и Kibana поставляются без встроенного механизма аутентификации, данные могут легко подвергнуться атаке, если не предпринять простые меры по их защите.

В этой статье мы рассмотрим, как реализовать один из наиболее распространенных и простых методов защиты стека ELK — установку Nginx в качестве обратного прокси-сервера перед Elasticsearch и Kibana.

Читать далее

Развертывание отказоустойчивого кластера Elasticsearch в Linux

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

Читать далее

Предотвращение взаимных блокировок в Galera с помощью HAProxy

В данном руководстве рассматривается настройка балансировщика HAProxy для распределения операций записи на выделенный сервер и операций чтения между всеми узлами кластера Galera с целью предотвращения ситуацией блокировки (deadlock).

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

Читать далее

Механизмы кэширования ARC и L2ARC в ZFS

У ZFS есть две интересные функции, которые значительно повышают производительность операций чтения. Речь идет о механизмах кэширования ARC и L2ARC. В этой статье рассмотрим их подробнее.

Читать далее

Балансировка нагрузки на кластер MySQL с помощью HAProxy

Введение

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

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

  • драйвер JDBC для MySQL (MySQL Connector/J);
  • драйвер, используемый по умолчанию в PHP MySQL для master-slave (mysqlnd-ms).

Эти драйверы позволяют обеспечить прозрачность подключения клиентов к автономному серверу MySQL, решению MySQL Cluster (NDB) или топологии, использующим репликацию MySQL.

Однако при использовании этих драйверов с кластером Galera для MySQL или MariaDB есть ряд проблем, так как они не обладают расширенной информацией о состоянии Galera. Например, узел-донор Galera может находиться в режиме «только для чтения» , когда помогает другому узлу повторно синхронизироваться (если для передачи снимка состояния (SST) используется mysqldump или rsync), или в случае split brain он может быть в состоянии Non-Primary. То есть, существуют случаи, когда даже драйверы с поддержкой пуллинга и балансировки не предоставляют необходимый уровень поддержки кластера.

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

Читать далее

Принципы работы кластера Galera для MySQL и управление кластером с помощью ClusterControl

В данном руководстве предоставляется основная информация о высокодоступном кластере Galera для MySQL/MariaDB. Прочитав статью до конца, вы узнаете ответы на вопросы:

  • как работает Galera Cluster;
  • чем репликация Galera Cluster отличается от репликации MySQL;
  • какие настройки рекомендованы для кластера Galera;
  • какими преимуществами и недостатками обладает Galera Cluster;
  • какие преимущества есть в объединении обоих способов репликации в рамках одного развертывания;
  • какие существуют различия в реализациях Galera у различных поставщиков;
  • как управлять кластером Galera;
  • какие стратегии резервного копирования необходимо использовать при использовании Galera.

Также, в статье вы найдете практический раздел о том, как быстро развернуть и управлять кластером с помощью ClusterControl. Для выполнения практической части статьи вам понадобится 4 сервера под управлением Ubuntu Linux 16.04 и новее, или CentOS 7.

Читать далее

Защита сетевого трафика кластера MySQL Galera с помощью шифрования SSL

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

Кластер Galera поддерживает шифрование соединения с использованием протокола SSL. В статье мы рассмотрим, как зашифровать все соединения кластера с помощью SSL-шифрования.

Читать далее

Настройка отказоустойчивого кластера MySQL с синхронной мульти-master репликацией с помощью Galera в Ubuntu, Debian и CentOS Linux

Синхронная мульти-master репликация в MySQL появилась сравнительно недавно, однако была востребована довольно давно. До этого момента пользователям приходилось использовать либо репликацию в режиме Master-Slave и переключать операции записи на ведомый сервер при отказе главного сервера, либо использовать довольно сложный вариант с Master-Master репликацией на основании двунаправленной Master-Slave репликации.

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

С появлением Galera все стало намного проще. Для надежной работы вам необходимо эксплуатировать нечетное количество серверов, например 3 или 5 для защиты от партиционирования, так, чтобы при ситуации, когда кластер «рассыпался» Galera могла принять обоснованное решение о том, является ли наблюдаемый сегмент кластера целостным.

Читать далее