Разгръщане на набор от реплики с висока наличност в MongoDB 3.4 с помощта на ключов файл за контрол на достъпа в Ubuntu 16.04

От създаването си през 2009 г. MongoDB е водеща в NoSQL индустрията. Една от основните концепции на MongoDB е наборът от реплики, така че преди да работите с него, първо нека прегледаме концепцията.

Относно комплекта реплики

Най-простият модел на комуникация, използван при репликация на бази данни, е архитектурата Master-Slave. Както подсказва името му, този модел има 2 роли, които са разпределени в уникален главен и много подчинени, ролята на главния е да обработва операциите за четене и запис, извършени от клиентите, а подчинените се третират като реплика на главния.

Най-важното предимство на този модел е, че производителността на главния не е компрометирана от операциите по архивиране, операциите по архивиране се извършват по асинхронен начин и това може да се превърне в сериозен проблем, когато главен възел се повреди. Подчинените възли се четат само и трябва да бъдат ръчно повишени до главния възел, така че в този момент има възможност за загуба на данни.

Една от възможностите за решаване на проблема с наличността е да имате повече от един главен елемент в архитектурата, но това може да доведе до друг проблем в съгласуваността на данните между тези екземпляри и допълнителната сложност на конфигурацията.

Сега при даден контекст можем да представим технологията Replica Set на MongoDB. Наборът реплики е името на архитектурата Master-Slave, която има автоматично превключване при отказ, така че в момента, в който главен (който сега е именуван primary) възел не успее да функционира правилно, electionще се задейства и нов първичен възел ще бъде избран от останалите подчинени ( наричан сега като secondaries).

Първичен възел

Основният възел е единственият, който изпълнява операции по запис, по подразбиране операциите за четене се обработват и от основния, но това поведение може да бъде променено по-късно.

Операциите се записват в oplog(дневника на операциите), след което вторичните възли актуализират съдържанието си асинхронно въз основа на съдържанието наoplog

Забележка: oplogе ограничена колекция, това означава, че колекцията има ограничение, като local.oplog.rsможете да проверите съдържанието на тази колекция в mongo shell във всеки член на набора.

Вторичен възел

Освен че е тези, които правят правилно архивиране на базата данни, вторичният възел има следните роли:

• Може да приеме операции за четене, ако е необходимо.
• Може да задейства избор, ако първичен възел не успее.
• Може да гласува на избори.
• Може да стане новият първичен, ако е необходимо.

Благодарение на тези характеристики можем да имаме различни видове вторични възли:

• Приоритет 0 : Тези възли не могат да станат primaryи не могат да задействат избори, все пак могат да гласуват на избори, да имат пълна реплика и могат да приемат операции за четене. Те могат да бъдат полезни при внедряване на множество центрове за данни.
• Скрит : Това са Priority 0членове, но освен това не могат да обработват операции за четене. Те могат да гласуват, ако е необходимо. Предпочитаните задачи за тези членове са отчитане и архивиране.
• Закъснение : Тези възли отговарят за "исторически данни", като се забавят с някаква единица във времето. Забавеният член трябва да бъде priority 0възел и се препоръчва и той да бъде hiddenчлен.

Предпоставки

• Наличността за стартиране на минимум 3 екземпляра на Ubuntu 16.04 x64 със същия размер на сървъра.

Проектирайте комплекта реплики

Преди разгръщането на инфраструктура е важно да я проектирате и има точки, които трябва да се вземат предвид при този дизайн.

Избор на броя на членовете

Имайте предвид, че минималният брой елементи за изграждане на набор от реплики е 3. Можете да смесвате трите типа възли с минимум един първичен и един вторичен възел.

В това ръководство разполагаме с 3 члена, един основен и два стандартни вторични.

Забележка: Препоръчително е да имате максимален брой от 7 членове с право на глас с комбинация от арбитри и второстепенни членове.

Изберете име

Името е само за справка, но го използвате в конфигурацията на комплекта. Имайте предвид, че можете да имате повече от един комплект реплики във вашата производствена среда, така че не пренебрегвайте името на вашия комплект.

Този урок насърчава потребителя да избере името на набора.

Разпределение на членовете в различни центрове за данни

Този урок предлага внедряване в същия център за данни, за да избегнете проблеми с комуникацията.

Забележка: В случай на внедряване в различни центрове за данни се препоръчва да обвиете вашите възли с VPN

Инструкции за внедряване

Стъпка 1: Разгръщане на минималните възли за вашата инфраструктура

Стартирайте 3 възела на Ubuntu 16.04 x64; в същия регион от вашия клиентски портал, ако е възможно. Не забравяйте да ги наименувате според типа проект, с който се занимавате, и се уверете, че имате същия размер на сървъра във всички тези възли.

След като сте разположили своите 3 възела, ще трябва да сте сигурни, че всеки възел може да говори с останалите. Трябва да прехвърлите ssh в два възела и да достигнете до останалите с помощта на ping -c 4 EXAMPLE_IP. Променете EXAMPLE_IPкъм действителните IP адреси на вашите възли.

Тук можете да видите пример за успешна комуникация между два възела.

root@foo_node:~# ping -c 4 EXAMPLE_IP
PING EXAMPLE_IP (EXAMPLE_IP) 56(84) bytes of data.
64 bytes from EXAMPLE_IP: icmp_seq=1 ttl=59 time=0.594 ms
64 bytes from EXAMPLE_IP: icmp_seq=2 ttl=59 time=0.640 ms
64 bytes from EXAMPLE_IP: icmp_seq=3 ttl=59 time=0.477 ms
64 bytes from EXAMPLE_IP: icmp_seq=4 ttl=59 time=0.551 ms

--- EXAMPLE_IP ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3021ms
rtt min/avg/max/mdev = 0.477/0.565/0.640/0.064 ms

Стъпка 2: Инсталирайте MongoDB във всеки възел на вашата инфраструктура

По принцип можете да използвате пакета MongoDB на Ubuntu, но е по-добре да използвате официалното репозиторие на общността, защото винаги е актуално. Това репо съдържа тези пакети:

• mongodb-org , груповият пакет, който обхваща четирите компонента.
• mongodb-org-server , това съдържа mongodдемона (основен процес, който обработва заявки за данни).
• mongodb-org-mongos , това съдържа mongosдемона (услуга за маршрутизиране за споделени разгръщания).
• mongodb-org-shell , това е mongo shellинтерфейсът на JavaScript.
• mongodb-org-tools , някои инструменти за административни дейности.

Продължете с инсталирането на пакетите.

Импортирайте публичния ключ в системата за управление на пакети.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6

Създайте списъчния файл за MongoDB '/etc/apt/sources.list.d/mongodb-org-3.4.list'.

echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

Актуализирайте базата данни на пакетите.

sudo apt-get update

Инсталирайте метапакета MongoDB.

sudo apt-get install -y mongodb-org

Стартирайте услугата MongoDB.

sudo service mongod start

Сега можете да отворите mongo shellвъв всяка bash сесия. За да направите това, трябва да използвате mongoкомандата. Ще бъдете посрещнати от нещо подобно.

MongoDB shell version v3.4.7
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.7
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
Server has startup warnings:
*Some extra logs are cut by the way*
>

Не забравяйте да изключите услугата с sudo service mongod stop, защото по-късно ще започнем mongodотново с някои параметри. Повторете този процес във всичките 3 възела на набора.

Стъпка 3: Конфигурирайте ключовия файл за достъп

Използването на ключов файл налага две концепции в администрирането на Replica Set. Първият е Internal Authentication. По подразбиране можете да стартирате mongo shellсесия, без да използвате потребител и тази сесия ще има пълен контрол над базата данни, но когато използвате ключов файл за удостоверяване, вашата mongo shellсесия достига състояние, наречено localhost exception. Това състояние ви позволява само да създадете администраторския потребител и набора реплики. Второто понятие е Role-Based Access Control, или с други думи оторизация. Това се прилага, за да управлява административните нива на набора реплики.

Създайте своя ключов файл

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

Съдържанието трябва да е с дължина между 6 и 1064 знака. Също така трябва да зададете read onlyразрешението за ключовия файл.

chmod 400 PATH_OF_YOUR_KEYFILE

Поставете ключовия файл във всеки член на набора

Сега копирайте вашия ключов файл към всеки член на набора, моля, използвайте последователна папка за бъдещи справки и не я съхранявайте в сменяем носител.

Също така използвайте папка за файла, mongodдо който има достъп.

Принудително използване на ключовия файл в набора реплики

В тази стъпка трябва да стартираме mongod daemon члена във всеки набор . Има два начина за стартиране на mongodпроцеса: с помощта на конфигурационен файл или чрез командния ред. И двата са доста лесни метода, но само за простота, този урок използва версията на командния ред.

Конфигурация на командния ред

Използвайте името, което сте избрали по-рано в тази команда.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

По подразбиране mongodне работи като демон. Ще трябва да използвате --forkпараметъра или да го използвате, за upstartда го стартирате напълно като демон. В този урок не насърчаваме да mongodработите като демон, за да можете да виждате логовете директно във вашия терминал.

Забележка: Въведете внимателно името на набора реплики, защото веднъж създаден, не можете да го промените.

Стъпка 4: Свържете се с интерфейса на локалния хост от един от членовете на набора

Забележка: Ако стартирате mongodкато процес, който не е демон, тогава ще трябва да отворите друга ssh връзка, за да продължите да работите.

Трябва да използвате mongoкоманда, за да отворите mongo shell. Това може да се направи във всеки член от комплекта.

В този момент се намираме в състояние, наречено localhost exception. Когато ключов файл се използва за настройка на mongodпроцеса, вие сте задължени да създадете администратор на база данни, преди да можете да приложите операции четене-запис, но ние ще разгледаме това по-късно.

Стъпка 5: Иницииране на набора реплики

Това е деликатна част, ние сме с помощта на командата rs.initiate()вътрешността на mongo shellот Стъпка 4. Преди да използвате това мнение тази команда нека да.

rs.initiate(
  {
    _id : <replicaSetName>,
    members: [
      { _id : 0, host : "example1.net:27017" },
      { _id : 1, host : "example2.net:27017" },
      { _id : 2, host : "example3.net:27017" }
    ]
  }
)

Първото _idполе е низ и трябва да съответства на --replSetтова, което е било предадено преди на mongod. Също така, всяка стойност на hostтрябва да бъде или ip, или името на домейна на всеки член от набора реплики. Не забравяйте да добавите порта, който mongo екземпляр използва във всеки член.

Сега е време да изпълните командата с вашите данни върху нея, това ще задейства election, след което първичният ще бъде избран автоматично.

Тук трябва да отбележите, че курсорът на вашата обвивка се е променил на YOUR_SET_NAME:PRIMARY>или YOUR_SET_NAME:SECONDARY. Това означава, че създаването на комплект е било успешно.

За да продължите да работите, трябва да намерите primary, ако не сте на него, разбира се. Използвайте rs.status()командата, за да покажете информацията за набора реплики и да намерите primary. Вие търсите имота "stateStr" : "PRIMARY".

Стъпка 6: Създаване на администратор

След като намерите primary, въведете mongo shellи изпълнете следващата команда, използвайки вашите данни.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOU_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

В admin = db.getSiblingDB("admin")част ни позволява да пиша в adminот друга база данни. Това създава псевдоним, наречен admin, така че вместо това можем да изпълняваме команди с него.

Ако операцията е успешна, ще получите известие, че потребителят е добавен.

Successfully added user: {
    "user" : "YOUR_USER",
    "roles" : [
        {
            "role" : "userAdminAnyDatabase",
            "db" : "admin"
        }
    ]
}

В този момент имаме само администратор за всички сървъри, но наличието на набор реплики ни принуждава да имаме потребител с clusterAdminролята. Ще създадем друг потребител само с тази роля, за да разделим проблемите.

Стъпка 7: Удостоверяване като администратор

Достигнахме лимита на localhost exception, поради което трябва да променим удостоверяването на потребителя, създаден една стъпка преди това.

Можете да промените потребителите вътре mongo shellсъс следното.

db.getSiblingDB("admin").auth("YOUR_ADMIN", "YOUR_PASSWORD" )

Ако все още не сте се свързали с mongo shellтази команда, вместо това използвайте тази команда.

mongo -u "YOUR_ADMIN" -p "YOUR_PASSWORD" --authenticationDatabase "admin"

Ще бъдете уведомени за смяната на потребител и можете да преминете към следващата стъпка.

Стъпка 8: Създаване на главния клъстер

В clusterAdminролята дава на потребителя пълен контрол на снимачната площадка реплика. Създаването му е толкова лесно, колкото и създаването на администраторски потребител.

db.getSiblingDB("admin").createUser(
  {
    "user" : "YOUR_USER",
    "pwd" : "YOUR_PASSWORD",
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
  }
)

Имайте предвид, че този път ролята се променя наclusterAdmin .

Стъпка 9: Вмъкване на данни в набора реплики

В този момент имаме 2 администраторски потребители: единият, който има пълен контрол над сървъра, а друг има достъп до административни задачи на ниво реплика. Все пак ни липсва потребител, който да има достъп до „използване“ на база данни, така че ще създадем този потребител сега.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOUR_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "cars" } ]
  }
)

Забележете, че този път променяме dbчастта, там поставяме базата данни достъпна за потребителя, в този случай използваме база данни с име cars.

Базата данни все още не е създадена. За да направите това, ще трябва да въведете някои команди, за да го създадете имплицитно. Превключете към carsбазата данни.

use cars

Ще получите известие: switched to db cars.

Базата данни все още не е създадена, за да направите това, трябва да напишете нещо в нея. Ние използваме следния пример.

db.models.insert({ make: "Dodge", model: "Viper", year: 2010 })

Този път ще бъдете уведомени с WriteResult({ "nInserted" : 1 }).

Ако искате, можете да извлечете всички обекти в базата данни с find()метода:

db.models.find()
{ "_id" : ObjectId("59acd8b55334882863541ff4"), "make" : "Dodge", "model" : "Viper", "year" : 2010 }

Имайте предвид, че _idще бъде различно във вашия изход, но другите данни трябва да са същите. При достатъчно време тези данни ще бъдат репликирани на другите членове.

Заключение

Създаването на набор от реплики в началото може да бъде предизвикателство, защото има много информация за разбиране, но след като разберете идеята зад него, можете да го разгърнете с лек бриз, така че не се отказвайте, ако не можете да го схванете за първи път. Имайте предвид, че наборът от реплики е важен в администрирането на MongoDB, защото отваря възможността за добавяне на разширени функции като балансиране на натоварването.