Ведущее устройство - установка MySQL Slave на Облаке VMware — это необходимо?
Базирующийся от быстрого поверхностного поиска, check_nrpe_1arg является ничем специальным по сравнению с check_nrpe, это имеет определенную предысторию также.
check_nrpe по умолчанию не принимает, что параметры командной строки отправляются, просто command_name для работы удаленного хоста сервера NRPE. Чтобы заставить NRPE принимать аргументы кроме того (если не изменяет память), необходимо включить определение времени компиляции, А ТАКЖЕ настроить его в check_nrpe, а также сервере NRPE nrpe.cfg файл.
check_nrpe_1arg, кажется, мнемосхема, которая настроена в базовый NAGIOS commands.cfg файл; а именно, говоря установщик, что эта команда примет только 1 аргумент (название команды для выполнения на удаленном хосте) и не будет соблюдать дополнительных аргументов.
Это - странный способ сделать это, учитывая поведение по умолчанию NAGIOS, но это нарастило обороты, тем не менее.
Самый быстрый ответ на это:
check_nrpe_1arg делает точно, в чем это настроено для выполнения commands.cfg на базовом сервере NAGIOS. В этом контексте это обеспечивает название команды для выполнения на удаленном сервере NRPE, и ничто дополнительное не будет принято.
[править]
Кроме того, это, кажется, произошло из конфигураций по умолчанию в "Untangle" (основанный на Linux пакет программного обеспечения брандмауэра/маршрутизации), это или Debian, трудно сказать, не переходя по горстке ссылок вокруг.
Самое важное, что нужно помнить о виртуальных машинах (по сути, это то, что вы получите от «облачного» провайдера) в том, что ничего волшебного не произошло только потому, что кто-то сказал «Виртуальный». Или «Облако».
Вам все равно нужно спланировать и протестировать высокую доступность, а не просто предполагать, что она будет работать. Вам все еще нужно беспокоиться о повреждении данных, записываемых в реплики и т. Д.
По сути, все, что вы получите от переноса в облако, - это меньшая видимость платформы - соблазнительно рассматривать это как меньшую ответственность, но если вашему бизнесу нужно облачные ресурсы, и они недоступны (например, представьте себе компанию в Нью-Йорке с локальным сервером и переключением облачного хранилища в центр обработки данных в Нью-Джерси несколько месяцев назад), а затем возможность указать на поставщика облачных услуг и сказать: «Это ваша вина» не поможет вашему веб-сайту возобновить прием заказов быстрее.
Компьютеры все еще ломаются, даже те, которые работают «в облаках».
Это не значит, что вы не должны этого делать. Есть преимущества наличия внешней реплики, готовой вмешаться, если у вас возникнут проблемы, и есть преимущества переноса всей инфраструктуры к облачному провайдеру, поэтому оба подхода допустимы. . Вам просто нужно четко понимать, что именно вы покупаете (вы не покупаете какое-то «облако», вы покупаете услугу, и вам нужно точно указать, какие услуги у вас будут и какое SLA они имеют.
It's important to clarify a couple points here:
Some cloud architectures can provide 'no downtime for scheduled maintenance' -- from the use of VMotion and similar.
Systems running with VMWare Fault Tolerance or similar can provide resistance to unexpected hardware failure, but there are significant limits to the setup (with VMWare FT, protected VMs can only have one CPU core).
Neither is automatic just because you bought something labeled 'Cloud'.
Thus, for scalability, you will probably want to go with master/slave replication; this works just as well in a cloud setup as in a dedicated-hardware setup.
As databases are particularly sensitive to disk performance, you'll want to make sure you understand your cloud provider's IO QoS options and over-subscription ratio.
Точка зрения RAID5
Хотя некоторые считают RAID5 решением для резервирования дисков для бедняков, для вашей собственной безопасности и здравомыслия, пожалуйста, избавьтесь от RAID5 как можно скорее. Почему ???
- В среде RAID5 с интенсивным чтением и низкой записью я бы просто оставил это
- Ваш бюджет
- Ваша толерантность
- Ваше кровяное давление
- В среде с интенсивной записью, низким уровнем чтения или интенсивной записью, интенсивным чтением RAID5 просто не может быть и речи . Это особенно верно для InnoDB.
Теперь давайте обсудим InnoDB и MyISAM
InnoDB
Если вы не используете innodb_file_per_table , OMG вся деятельность будет сосредоточена только вокруг одного файла, ibdata1. Что содержится в ibdata1 InnoDB?
- Страницы данных таблиц
- Страницы индексов таблиц
- Метаданные таблиц для управления идентификаторами табличных пространств
- Данные MVCC (для соответствия ACID и изоляции транзакций)
Даже читается в InnoDB имеет тенденцию покрывать строки защитой MVCC, чтобы обеспечить повторяемое чтение и разрешить транзакциям попадать в те же считываемые строки. Таким образом, чтение и запись производят дисковый ввод-вывод в ibdata1.
Использование innodb_file_per_table может уменьшить часть дискового ввода-вывода, разделив страницы данных таблицы и индекса из ibdata1 в файлы .ibd . Тем не менее, я бы ожидал некоторого заметного улучшения производительности только в течение ограниченного времени в среде RAID5. Взаимодействие с таблицами осталось прежним. Каждому доступу к файлу .ibd всегда предшествует проверка ссылок на ibdata1.
Хотя разделение может привести к значительным изменениям производительности, RAID5 был бы тем, что они называют в мире химии, ограничивающим реагентом. Любые выгоды, ожидаемые от изменений компоновки InnoDB, будут нейтрализованы внешними факторами, такими как RAID5. Наличие дополнительных файлов табличных пространств из-за innodb_file_per_table ничего не дает вам с течением времени, а только наличие дополнительных файлов табличных пространств.
MyISAM
Когда дело доходит до MyISAM, RAID5 подходит в среде с интенсивным чтением и низкой записью при условии, что вы отобразите все временные таблицы (с помощью tmpdir ) на другой диск, отдельно из RAID5 . (Звучит как поражение цели RAID5, а?)
Пожалуйста, помните, что страницы данных таблиц находятся в файлах .MYD , а соответствующие им индексные страницы находятся в файлах .MYI . Среда с большим объемом записи (INSERT, UPDATE, DELETE) заставит RAID5 замедлить работу. Учитывая поведение блокировки MyISAM (полная блокировка таблицы с каждым INSERT, UPDATE и DELETE) в среде с большим объемом записи, постоянный поток DML будет держать RAID5 довольно загруженным и заставит пользователей БД войти в краткую, но раздражающую временную деформацию в ожидании DML. для завершения.
Вывод по RAID5
Под капотом, RAID5 имеет следующие характеристики для записи с контролем четности
- Прочитать старый блок данных
- Прочитать старый блок четности
- Сравнить старый блок данных с запросом на запись. Для каждого перевернутого бита (измененного с 0 на 1 или с 1 на 0) в блоке данных переверните соответствующий бит в блоке четности
- Запишите новый блок данных
- Запишите новый блок четности
Если на любом из этих шагов наблюдается малейшая прерывистость, набор RAID5 переходит в кратковременную, но досадную деформацию времени. Умножьте это на огромное количество операций записи, и вы почувствуете это по производительности базы данных. Каждый из этих шагов может стать точкой отказа. Почему?
Согласно Википедии о RAID5
В случае сбоя системы при активной записи или от 1 до 0) в блоке данных, переверните соответствующий бит в блоке четности
Запишите новый блок данных Запишите новый блок четности Если на любом из этих шагов будет обнаружена малейшая прерывистость, RAID5 набор входит в краткую, но раздражающую деформацию времени. Умножьте это на огромное количество операций записи, и вы почувствуете это по производительности базы данных. Каждый из этих шагов может стать точкой отказа. Почему?
Согласно Википедии о RAID5
В случае сбоя системы при активной записи или от 1 до 0) в блоке данных, переверните соответствующий бит в блоке четности
Запишите новый блок данных Запишите новый блок четности Если на любом из этих шагов будет обнаружена малейшая прерывистость, RAID5 набор входит в краткую, но раздражающую деформацию времени. Умножьте это на огромное количество операций записи, и вы почувствуете это по производительности базы данных. Каждый из этих шагов может стать точкой отказа. Почему?
Согласно Википедии о RAID5
В случае сбоя системы при активной записи Каждый из этих шагов может стать точкой отказа. Почему?
Согласно Википедии о RAID5
В случае сбоя системы при активной записи Каждый из этих шагов может стать точкой отказа. Почему?
Согласно Википедии о RAID5
В случае сбоя системы при активной записи четность полосы может не соответствовать данным. Если это не обнаружены и не восстановлены до выхода из строя диска или блока, потеря данных может последуют, поскольку неправильная четность будет использоваться для восстановления отсутствующего блок в этой полосе. Эта потенциальная уязвимость иногда известна как отверстие для записи. Кэш с резервным питанием от батареи и аналогичные методы обычно используется, чтобы уменьшить окно возможности для этого.
РЕКОМЕНДАЦИЯ (RAID5)
RAID10 не только обеспечивает стабильность, но и дает некоторую свободу действий в обслуживании диска, не останавливая mysql в большинстве случаев. Когда данные зеркалируются, вы знаете, куда они направляются, и вы знаете, откуда они читаются.
Я бы сказал, используйте RAID10. Если вы не возражаете против длительных периодов простоя, вы не можете позволить себе обслуживание диска RAID5 вместо необходимой синхронизации диска. Фактически, чем меньше диски, которые вы разделяете в RAID10, тем быстрее будет время синхронизации после обслуживания диска RAID 10.
Другие моменты, которые следует учитывать
- Настройте свои запросы
- Удалите избыточные индексы
- Кэшируйте как
- Используйте покрывающие индексы с умом
VMWare Viewpoint
Относительно Master и Slave в VMWare, пожалуйста, убедитесь, что ведущий и ведомый находятся на разных физических дисках. Если диски в VMWare являются RAID5, подготовьте еще один кластер VMWare прямо сейчас, используя RAID10.
Если вам нужна надежность, выберите RAID 10, а не RAID 5, и настройку master / slave (RAID 10 обеспечивает производительность, а также надежность). Я сомневаюсь, что вы можете получить производительность ввода-вывода физического сервера (RAID 10) с любым облачным провайдером. Использование облака очень полезно, когда ваша нагрузка / трафик непостоянны или у вас есть всплески трафика 2-3 раза в день. В таких случаях вы создаете новый веб-сервер и экземпляры базы данных и отбрасываете их, когда трафик идет нормально.
Регулярно выполняйте резервное копирование данных, независимо от того, находитесь ли вы в облаке, на физическом сервере с RAID 10 / RAID 5 или репликации главный / подчиненный. И, что наиболее важно, почаще проверяйте состояние резервных копий.
Вся суть облака - это масштабируемость и «отсутствие простоев оборудования», следовательно, отсутствие потери данных из-за неисправного оборудования.
Вы понимаете, что «облако» - это просто обычные виртуализированные серверы. операционные системы. Это может и страдает больше (обычно намного больше) простоев и потерь данных, чем обычный выделенный сервер.
В настоящее время мы находимся на стадии исследования создания «главной» базы данных для нашего бизнеса электронной коммерции
. это предприятие исключительно для базы данных вашего магазина Magento - или для более широкой реализации ERP?
Если первое, то начните исследование снова. Magento не привязан к своей БД - вы столкнетесь с множеством других узких мест, прежде чем MySQL станет проблемой. То есть, если вы не размещаете свой сервер MySQL на удаленном «облачном» VPS, подключенном с высокой задержкой, плохо маршрутизируемое, сильно перегруженное, высококонкурентное и низкополосное WAN-соединение.
Я видел больше потерь данных и ненадежных хранилищ из-за попыток DIY для обеспечения высокой доступности - чем при использовании простого односерверного решения
. другой вопрос . Вы тратите 14 тысяч долларов в год на лицензию Magento EE, но пытаетесь управлять своим собственным сервером?
Существуют специализированные хостинг-провайдеры Magento - это веская причина, чтобы вы не тратили и не теряли небольшое состояние, делая неправильные решения пытаются сделать своими руками. Вам следует сосредоточиться на управлении своим магазином и делать то, что у вас хорошо получается, а не пытаться быть системным администратором.
Мы видели больше потерь данных и ненадежных хранилищ из-за попыток самостоятельной работы по обеспечению высокой доступности - чем при использовании простого односерверного решения.Глядя на ваш другой вопрос . Вы тратите 14 тысяч долларов в год на лицензию Magento EE, но пытаетесь управлять своим собственным сервером?
Существуют специализированные хостинг-провайдеры Magento - это веская причина, чтобы вы не тратили и не теряли небольшое состояние, делая неправильные решения пытаются сделать своими руками. Вам следует сосредоточиться на управлении своим магазином и делать то, что у вас хорошо получается, а не пытаться быть системным администратором.
Мы видели больше потерь данных и ненадежных хранилищ из-за попыток самостоятельной работы по обеспечению высокой доступности - чем при использовании простого односерверного решения.Глядя на ваш другой вопрос . Вы тратите 14 тысяч долларов в год на лицензию Magento EE, но пытаетесь управлять своим собственным сервером?
Существуют специализированные хостинг-провайдеры Magento - это веская причина, чтобы вы не тратили и не теряли небольшое состояние, делая неправильные решения пытаются сделать своими руками. Вам следует сосредоточиться на управлении своим магазином и делать то, что у вас хорошо получается, а не пытаться быть системным администратором.
Вы тратите 14 тысяч долларов в год на лицензию Magento EE, но пытаетесь управлять своим собственным сервером?Существуют специализированные хостинг-провайдеры Magento - это веская причина, чтобы вы не тратили и не теряли небольшое состояние, делая неправильные решения пытаются сделать своими руками. Вам следует сосредоточиться на управлении своим магазином и делать то, что у вас хорошо получается, а не пытаться быть системным администратором.
Вы тратите 14 тысяч долларов в год на лицензию Magento EE, но пытаетесь управлять своим собственным сервером?Существуют специализированные хостинг-провайдеры Magento - это веская причина, чтобы вы не тратили и не теряли небольшое состояние, делая неправильные решения пытаются сделать своими руками. Вам следует сосредоточиться на управлении своим магазином и делать то, что у вас хорошо получается, а не пытаться быть системным администратором.