Ustawienie MongoDB na lokalnym środowisku developerskim jest całkiem łatwe. Wystarczy ściągnąc MongoDB, zainstalować i skonfigurować mongod (proces bazy danych) jako usługę Windows. Wszystkie połączenia są domyślnie ustawione w Sitecore w pliku ConnectionStrings.config. Nie trudne. Dobra, ale jak ustawić MongoDB na środowisku produkcyjnym, gdzie trzeba zapewnić wymagany poziom świadczenia usług (SLA). Innymi słowami, musimy być pewni, że Sitecore wciąż będzie działał, mimo że komponent systemu, na którym znajduje się Mongo, przestanie działać.
Najprostszym sposobem na dostarczenie takiego rozwiązania jest użycie replikacji MongoDB. Jak to działa, w skrócie?
Zaczynamy od instalacji MongoDB na większej ilości maszym, przynajmniej na dwóch (a właściwie trzech, jeśli stworzymy Arbiter), po czym konfigurujemy “replica set”. W ramach “replica set” na każdej maszynie uruchamiany jest osobny proces mongod. Wszystkie procesy są połączone i mają różne role:
- Primary – główny węzeł odpowiedzialny za przechowanie danych umożliwiający zapis i odczyt danych. Jeśli dane w MongoDB zostały zmodyfikowane, automatycznie są replikowane z węzła Primary do węzłów Secondary.
- Secondary – dodatkowy węzeł odpowiedzialny za przechowywanie danych, umożliwiający tylko odczyt. W replica set może być więcej niż jeden węzeł Secondary. Jeśli węzeł Primary przestanie działać, jeden z węzłów Secondary zostanie mianowany na nowy węzeł Primary.
- Arbiter – jedyną rolą tego węzła jest mianowanie wezła Secondary na nowy węzeł Primary, w razie awarii węzła Primary. Arbiter nie przechowuje danych.
Sitecore komunikuje się z węzłami Primary i Secondary. Dodatkowo w ramach replica set wszystkie węzły komunikują się między sobą.
Konfiguracja replica set
Wymagania wstępne
Musimy zainstalować i uruchomić MongoDB na wszystkich maszynach oraz zapewnić komunikacje między nimi. Do sprawdzenia można użyć polecenia telnet, lub połączyć się z instancją MongoDB za pomocą komendy mongo, którą można uruchomić z folderu, w którym zainstalowano MongoDB:
|
1 |
mongo --host mongo2.smartsitecore.com --port 27017 |
Komendę można powtórzyć na każdej maszynie, łącząc się z każdą instancją MongoDB.
Rezultat powinien wyglądać następująco “connecting to: mongo2.smartsitecore.com:27017/test”
Konfiguracja węzła Primary
Zaczynamy od zmiany w pliku konfiguracyjnym mongod na węźle Primary dodając następujące linie (jeśli nie używamy składni YAML wystarczy dodać replSet=rs0). “rs0” będzie nazwą replica set’u:
|
1 2 |
replication: replSetName: rs0 |
Po każdej zmianie pliku konfiguracyjnego trzeba zrestartować usługę mongod. Następnie łączymy się z MongoDB na węźle Primary za pomocą komendy mongo i inicjalizujemy replica set komendą:
|
1 |
rs.initiate( { _id : "rs0", members: [ { _id : 0, host : "mongo1.smartsitecore.com:27017" } ]}) |
W rezultacie otrzymujemy potwiedzenie { “ok” : 1}
Konfiguracja węzła Secondary
Zmieniamy plik konfiguracyjny mongod na węźle Secondary dodając takie same linie, jak na węźle Primary:
|
1 2 |
replication: replSetName: rs0 |
Restartujemy mongod na węźle Secondary, a następnie na węźle Primary, łącząc się do bazy, uruchamiamy komendę rs.add():
|
1 |
rs.add("mongo2.smartsitecore.com") |
Ponownie powinniśmy zobaczyć potwierdzenie { “ok” : 1}
Konfiguracja węzła Arbiter
Zmieniamy plik konfiguracyjny mongod na węźle Arbiter, dodając te same linie z nazwą replica oraz dodatkowo wyłączamy journal dla przechowywanych danych (jeśli nie używamy składni YAML dodajemy do pliku: journal.enabled=false). Na weźle Arbiter możemy bezpiecznie wyłączyć journal, ponieważ nie przechowuje od żadnych danych, poza konfiguracją węzła.
|
1 2 3 4 5 |
replication: replSetName: rs0 storage: journal: enabled: false |
Restartujemy mongod na węźle Arbiter, następnie na węźle Primary, po połączeniu do bazy danych uruchamiamy komendę rs.addArb():
|
1 |
rs.addArb("mongo3.smartsitecore.com") |
Ponownie powinniśmy zobaczyć potwierdzenie { “ok” : 1}
Sprawdzenie statusu Replica set
Z jednej z instancji łączymy się do bazy danych, za pomocą komendy mongo, następnie sprawdzamy status replikacji:
|
1 |
rs.status() |
W rezultacie powinniśmy otrzymać raport ze statusem replikacji. Wszystkie trzy węzły działają:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 |
MongoDB shell version: 3.2.8 connecting to: test 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 rs0 :PRIMARY> rs.status() { "set" : "rs0", "date" : ISODate("2017-02-17T07:23:45.147Z"), "myState" : 7, "term" : NumberLong(31), "heartbeatIntervalMillis" : NumberLong(2000), "members" : [ { "_id" : 0, "name" : "mongo1.smartsitecore.com:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 6902238, "optime" : { "ts" : Timestamp(1487316177, 1), "t" : NumberLong(31) }, "optimeDate" : ISODate("2017-02-17T07:22:57Z"), "lastHeartbeat" : ISODate("2017-02-17T07:23:40.893Z"), "lastHeartbeatRecv" : ISODate("2017-02-17T07:23:43.567Z" ), "pingMs" : NumberLong(0), "electionTime" : Timestamp(1480413608, 1), "electionDate" : ISODate("2016-11-29T10:00:08Z"), "configVersion" : 3 }, { "_id" : 1, "name" : "mongo2.smartsitecore.com:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 6902238, "optime" : { "ts" : Timestamp(1487316177, 1), "t" : NumberLong(31) }, "optimeDate" : ISODate("2017-02-17T07:22:57Z"), "lastHeartbeat" : ISODate("2017-02-17T07:23:41.162Z"), "lastHeartbeatRecv" : ISODate("2017-02-17T07:23:44.450Z" ), "pingMs" : NumberLong(0), "syncingTo" : "mongo1.smartsitecore.com:27017", "configVersion" : 3 }, { "_id" : 2, "name" : "mongo3.smartsitecore.com:27017", "health" : 1, "state" : 7, "stateStr" : "ARBITER", "uptime" : 6902240, "configVersion" : 3, "self" : true } ], "ok" : 1 } rs0 :PRIMARY> |
Możemy teraz wyłączyć jeden z węzłów Primary lub Secondary i obserwować co stanie się z replikacją za pomocą komendy rs.status(). Jeśli wyłaczymy Primary, Arbiter automatycznie mianuje Secondary na nowy węzeł Primary.
Konfiguracja Sitecore do użycia MongoDB replica set
Wreszcie możemy uaktualnić połączenie do baz danych w Sitecore tak aby wskazywały replica set:
|
1 2 3 4 |
<add name="analytics" connectionString="mongodb://mongo1.smartsitecore.com:27017,mongo2.smartsitecore.com:27017/analytics?replicaSet=rs0" /> <add name="tracking.live" connectionString="mongodb://mongo1.smartsitecore.com:27017,mongo2.smartsitecore.com:27017/tracking_live?replicaSet=rs0" /> <add name="tracking.history" connectionString="mongodb://mongo1.smartsitecore.com:27017,mongo2.smartsitecore.com:27017/tracking_history?replicaSet=rs0" /> <add name="tracking.contact" connectionString="mongodb://mongo1.smartsitecore.com:27017,mongo2.smartsitecore.com:27017/tracking_contact?replicaSet=rs0" /> |
Takie ustawienie gwarantuje poprawioną wydajność (poprzez odczyt z wielu maszyn) oraz automatyczne przełączenie w razie awarii. Dane są synchronizowane automatycznie pomiędzy instancjami Primary i Secondary.