Въведение в Percona Server за MongoDB 4.2

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

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

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

В този блог ще обсъдим версията на MongoDB на Percona и как тя разширява силата на MongoDB по различни начини.

Какво е Percona Server за MongoDB?

За да работи добре базата данни, трябва да има оптимално установен основен сървър за подобряване на транзакциите за четене и запис. Percona Server за MongoDB е безплатен заместник с отворен код за MongoDB Community Edition, но с допълнителна функционалност от корпоративен клас. Той е проектиран с някои големи подобрения на настройката на сървъра по подразбиране на MongoDB.

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

Percona сървър за характерни функции на MongoDB

MongoDB Community Edition е ядрото на сървъра на Percona, като се има предвид, че вече представлява важни характеристики като гъвкава схема, разпределени транзакции, познаване на JSON документите и висока наличност. Освен това, Percona Server за MongoDB интегрира следните характерни функции, които му позволяват да удовлетвори аспектите, които споменахме по-горе:

Горещи архиви
Криптиране на данни в покой
Регистриране на одит
Percona Memory Engine
Външно LDAP удостоверяване със SASL
Интеграция на HashiCorp Vault
Подобрено профилиране на заявки

Горещи архиви

Percona сървър за MongoDB създава резервно копие на физически данни на работещ сървър във фонов режим без забележимо влошаване на работата. Това е постижимо, като изпълните командата createBackup като администратор на администраторската база данни и посочите директорията за архивиране.

> use admin

switched to db admin

> db.runCommand({createBackup: 1, backupDir: "/my/backup/data/path"})

{ "ok" : 1 }

Когато получите { "ok" :1 }, тогава архивирането е било успешно. В противен случай, ако например посочите празен път на резервна директория, може да получите отговор за грешка, т.е.:

{ "ok" : 0, "errmsg" : "Destination path must be absolute" }

Възстановяването на архива изисква първо да спрете екземпляра mongod, да почистите директорията с данни, да копирате файловете от директорията и след това да рестартирате услугата mongod. Това може да стане, като изпълните командата по-долу

$ service mongod stop && rm -rf /var/lib/mongodb/* && cp --recursive /my/backup/data/path /var/lib/mongodb/ && service mongod start

Можете също да съхранявате архива в архивен формат, ако използвате Percona сървър за MongoDB 4.2.1-1

> use admin

> db.runCommand({createBackup: 1, archive: "path/to/archive.tar" })

Можете също да архивирате директно в AWS S3, като използвате настройките по подразбиране или с повече конфигурации. За резервно копие на пакет S3 по подразбиране:

> db.runCommand({createBackup:1, s3:{bucket:"backup", path:"newBackup"}})

Шифроване на данни в покой

MongoDB версия 3.2 въведе криптиране на данни в покой за механизма за съхранение на WiredTiger, за да се гарантира, че файловете с данни могат да бъдат декриптирани и прочетени от страни само с ключ за декриптиране. Криптирането на данни в покой в Percona Server за MongoDB беше въведено във версия 3.6, за да върви в ръка с интерфейса за криптиране на данни в покой в MongoDB. Най-новата версия обаче не включва поддръжка за услуги за управление на ключове на Amazon AWS и KIMP.

Криптирането може да се приложи и към връщане на файлове, когато данните в покой са активирани. Percona Server за MongoDB използва опция encryptionCipherMode с 2 селективни режима на шифроване:

AES256-CBC (режим на шифроване по подразбиране)
AES256-GCM

Можете да шифровате данни с командата по-долу

$ mongod ... --encryptionCipherMode or 

$ mongod ... --encryptionCipherMode AES256-GCM

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

$ mongod ... --enableEncryption --encryptionKeyFile <fileName>

Регистриране на одит

За всяка система за бази данни администраторите имат мандат да следят извършваните дейности. В Percona Server за MongoDB, когато одитът е активиран, сървърът генерира регистрационен файл за одит, който представлява информация за различни потребителски събития, като оторизация и удостоверяване. Въпреки това, стартирайки сървъра с активиран одит, регистрационните файлове няма да се показват динамично по време на изпълнение.

Регистрирането на одита в MongoDB Community Edition може да приеме два формата на данни, тоест JSON и BSON. Въпреки това, за Percona Server за MongoDB, регистрирането на одит е ограничено само до JSON файл. Сървърът също така регистрира само важни команди, за разлика от MongoDB, който регистрира всичко. Тъй като процедурата за филтриране в Percona е толкова неясна по отношение на синтаксиса на филтриране, разрешаването на дневника за одит без филтриране би предложило повече записи, от които човек може да се стесни до собствени спецификации.

Percona Memory Engine

Това е специална конфигурация на машината за съхранение на WiredTiger, която не съхранява потребителски данни на диск. Данните се намират изцяло и са лесно достъпни в главната памет, с изключение на диагностичните данни, които се записват на диска. Това прави обработката на данни много по-бърза, но като се има предвид, че трябва да се уверите, че има достатъчно памет за съхраняване на набора от данни и сървърът не трябва да се изключва. Можете да изберете машина за съхранение, която да се използва с командата --storageEngine. Данните, създадени за една машина за съхранение, не могат да бъдат съвместими с други машини за съхранение, тъй като всяка машина за съхранение има свой собствен модел на данни. Например да изберете механизма за съхранение в паметта. Първо спирате всеки работещ екземпляр на mongod и след това издавате командите:

$ service mongod stop

$ mongod --storageEngine inMemory --dbpath <newDataDir>

Ако вече имате някои данни с вашето издание на MongoDB Community по подразбиране и искате да мигрирате към Percona Memory Engine, просто използвайте помощните програми mongodumb и mongorestore, като издадете командата:

$ mongodump --out <dumpDir>

$ service mongod stop

$ rm -rf /var/lib/mongodb/*

$ sed -i '/engine: .*inMemory/s/#//g' /etc/mongod.conf

$ service mongod start

$ mongorestore <dumpDir>

Външно LDAP удостоверяване със SASL

Всеки път, когато клиентите направят заявка за четене или запис до екземпляр на MongoDB mongod, те трябва първо да се удостоверят в потребителската база данни на MongoDB сървър. Външното удостоверяване позволява на сървъра на MongoDB да проверява идентификационните данни на клиента (потребителско име и парола) срещу отделна услуга. Външната архитектура за удостоверяване включва:

LDAP сървър, който отдалечено съхранява всички потребителски идентификационни данни
SASL Daemon, който се използва като локален прокси сървър на MongoDB за отдалечената LDAP услуга.
SASL библиотека:създава необходимите данни за удостоверяване за MongoDB клиент и сървър.

Последователност на сесията за удостоверяване

Клиентът се свързва с работещ екземпляр на mongod и създава ОБЩА заявка за удостоверяване с помощта на библиотеката SASL.
Заявката за удостоверяване след това се изпраща до сървъра като специална команда Mongo, която след това се получава от сървъра mongod с неговия полезен товар.
Сървърът създава някои SASL сесии, извлечени с клиентски идентификационни данни, като използва собствена препратка към SASL библиотеката.
Сървърът mongod предава полезния товар за удостоверяване на SASL библиотеката, която го предава на демона saslauthd. Демонът го предава на LDAP и чака отговор ДА или НЕ при заявката за удостоверяване, като проверява дали потребителят съществува и изпратената парола е правилна.
Saslauthd предава този отговор на сървъра mongod през SASL библиотеката, която след това удостоверява или отхвърля съответно заявката.

Ето илюстрация за този процес:

За да добавите външен потребител към сървър mongod:

> db.getSiblingDB("$external").createUser( {user : username, roles: [ {role: "read", db: "test"} ]} );

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

Интеграция на HashiCorp Vault

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

Подобрено профилиране на заявка

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

Заключение

Percona Server за MongoDB е подобрена база данни с отворен код и силно мащабируема, която може да действа като съвместим заместник на MongoDB Community Edition, но с подобен синтаксис и конфигурация. Той подобрява обширната сигурност на данните, особено тези в покой, и подобрява производителността на базата данни чрез предоставяне на Percona Server двигател, ограничавайки скоростта на профилиране наред с други функции.

Percona Server за MongoDB се поддържа напълно от ClusterControl като опция за внедряване.