Ich muss ein Setup für Magento machen. Meine Einschränkung ist in erster Linie die einfache Einrichtung und Fehlertoleranz / Failover. Darüber hinaus sind Kosten ein Thema. Ich habe drei identische physische Server, um die Arbeit zu erledigen. Jeder Serverknoten verfügt über einen i7 Quad Core, 16 GB RAM und 2 x 3 TB HD in einer Software-RAID 1-Konfiguration. Auf jedem Knoten wird Ubuntu 12.04 ausgeführt. jetzt sofort. Ich habe eine zusätzliche IP-Adresse, die an jeden dieser Knoten weitergeleitet werden kann.

Der Magento Shop hat max. 1000 Produkte, 50% davon sind Bündelprodukte. Ich würde schätzen, dass max. 10 Benutzer sind gleichzeitig aktiv. Dies führt mich zu dem Schluss, dass Leistung hier nicht oberste Priorität hat.

Meine erste Setup-Idee

Ein Knoten (lb) führt nginx als Load Balancer aus. Die zusätzliche IP wird mit dem Domänennamen verwendet und standardmäßig an diesen Knoten weitergeleitet. Nginx verteilt die Last gleichmäßig auf die beiden anderen Knoten (shop1, shop2). Shop1 und shop2 sind gleichermaßen konfiguriert: Auf jedem Server werden Apache2 und MySQL ausgeführt. Die MySQLs sind mit Master / Slave-Replikation konfiguriert.

Meine Failover-Strategie:

• Lb schlägt fehl => IP an shop1 (MySQL-Master) weiterleiten, weiter.
• Shop1 schlägt fehl => Lb wird das automatisch erledigen, MySQL-Slave auf shop2 zum Master hochstufen, Magento neu konfigurieren, um shop2 für Schreibvorgänge zu verwenden, fortfahren.
• Shop2 schlägt fehl => Lb erledigt das automatisch, fahren Sie fort.

Ist das eine vernünftige Strategie? Hat jemand ein ähnliches Setup mit Magento durchgeführt?

Meine zweite Setup-Idee

Eine andere Möglichkeit wäre die Verwendung von drbd zum Speichern der MySQL-Datendateien auf shop1 und shop2. Ich verstehe, dass in diesem Szenario nur ein Knoten / eine MySQL-Instanz aktiv sein kann und der andere als Hot Standby verwendet wird. Für den Fall, dass shop1 fehlschlägt, würde ich MySQL auf shop2 starten, die IP an shop2 weiterleiten und fortfahren. Ich mag das, da das MySQL-Setup einfacher ist und die Knoten zu 99% identisch konfiguriert werden können. In diesem Fall wird der Load Balancer unbrauchbar und ich habe einen Ersatzserver.

Meine dritte Setup-Idee

Der dritte Weg könnte die Master-Master-Replikation von MySQL-Datenbanken sein. Meiner Meinung nach kann dies jedoch schwierig sein, da Magento nicht für dieses Szenario erstellt wurde (z. B. widersprüchliche IDs für neue Zeilen). Ich würde das nicht tun, bis ich von einem funktionierenden Beispiel gehört habe.

Können Sie mir einen Rat geben, welchen Weg ich einschlagen soll? Es scheint keinen "guten" Weg zu geben, dies zu tun. ZB lese ich Blog-Beiträge, die ein MySQL-Master / Slave-Setup für Magento beschreiben, aber an anderer Stelle lese ich, dass Daten möglicherweise dupliziert werden, wenn der Slave hinter dem Master zurückbleibt (z. B. wenn eine Bestellung aufgegeben wird, wird ein Kunde möglicherweise zweimal erstellt). Ich bin hier irgendwie verloren.

KUSS

Halte es einfach albern.

Ich bin hier irgendwie verloren.

Beginnen Sie aus diesem Grund nicht, etwas zu komplizieren, das nicht kompliziert sein muss. Wenn Sie zunächst nicht die richtige Methode kennen, um etwas zu implementieren, wissen Sie sicherlich nicht, was zu tun ist, wenn etwas schief geht.

Lassen Sie uns zunächst die Hardware ansprechen

Ref: https://www.sonassihosting.com/help/magestack/cpu-sizing/

a) Ein Standard-Magento-Demo-Store kann ungefähr 230 Unikate pro GHz und Stunde liefern.

b) In einem typischen Webshop mit Administratorbenutzeraktivität, Entwicklungsaktivität und Produktaddition / -löschung kann sich dies um etwa 100% auf 115 Unikate pro GHz und Stunde verschlechtern.

Verwenden Sie Ihre Zahl von 100 aktiven Besuchern zu einem bestimmten Zeitpunkt.

hourly_hits = (60 / time_on_site (mins)) * concurrent_users

Wir gehen daher von einer Branchendurchschnittszeit vor Ort von 8 Minuten und 8 Seitenaufrufen pro Besuch aus.

hourly_hits = (60 / 8) * 100
hourly_hits = (7.5) * 100
hourly_hits = 750 

Dies ergibt eine Zahl von 750 stündlichen Einzelbesuchern oder rund 7.500 täglichen Einzelbesuchern.

Um 750 Besucher pro Stunde bei 115 Uniques / GHz zu unterstützen, benötigen Sie das Äquivalent von 7x 1 GHz CPU-Kernen. Nehmen wir also an, Ihr i7 Quad Core ist 2,5 GHz - das ergibt eine Gesamtsumme von 10 GHz.

Lassen Sie uns zweitens Ihre Konfiguration ansprechen

Was genau ist dein Ziel?

1. Hohe Verfügbarkeit
2. Verlässlichkeit
3. Einfachheit der Verwaltung
4. Performance
5. Skalierbarkeit

Keine Ihrer Ideen ist besonders gut, Ihr Load Balancer ist ein einzelner Fehlerpunkt, und ich glaube, Sie sind ein bisschen zu sehr in die MySQL-Redundanz verwickelt.

Master-Master ist ein Konfigurations-Albtraum, und Sie haben keine Vorteile daraus. Magento ist im geringsten NICHT an MySQL gebunden. Siehe Was soll ich auf meine größere Maschine setzen? Magento Webserver der Magento Datenbank?

Und es sei denn, Sie planen, ALLES in Ihrer Architektur überflüssig zu machen, d. H.

1. Verbundene Netzwerkschnittstellen
2. A + B-Schalter
3. A + B Firewalls
4. A + B trennen Stromversorgungen von verschiedenen USVs
5. Multihomed-Upstream-Konnektivität

... es macht nicht viel Sinn, auf der Softwareebene eine gewisse Ausfallsicherheit aufzubauen.

Wie würden wir das machen?

Hat jemand ein ähnliches Setup mit Magento durchgeführt?

In einem Wort. Ja.

Wir konfigurieren alles von einem einzelnen Server bis zu nServern in MageStack - indem wir jeden einzelnen Knoten containerisieren.

In Ihrem Fall richten wir normalerweise Folgendes ein (vorausgesetzt, Sie haben HA angefordert).

**Server 1**        **Server 2**        **Server 3**
LB  (m)    <==>     LB  (s)             
Web (m)             Web (m)             Web (m)
                    DB  (s)    <==>     DB  (m)

Die virtuellen LB- und DB-Server würden ihre Root-Partitionen auf einem DRBD-Spiegel (dargestellt durch <==>) haben. Die Webknoten würden entweder einen gemeinsamen NFS-Speicher oder häufiger einen Repo-Pull auf den Live-Webknoten verwenden.

Nur um hier auf eine Antwort zu verweisen Wie arrangiere ich Webserver mit Varnish?

Unsere typische Architektur ist

lvs (initial ssl load balancing)
 -> pound (ssl-unwrapping) 
 -> varnish (caching) 
 -> haproxy (load balancing) 
 -> nginx (static content) 
 -> php (dynamic content) 
 -> mysql (db)

Heartbeat würde Integritätsprüfungen zwischen Computern aufrechterhalten und ein Failover der IP-Adresse bereitstellen und die jeweiligen virtuellen Server starten / stoppen.

Die resultierende containerisierte Architektur würde also so aussehen ... (entschuldigen Sie die Grafik, ich habe sie aus einem Marketing-PDF pochiert).

Wie ich Ihnen empfehlen würde, es zu tun

Verwenden Sie keinen Master / Slave, verwenden Sie kein DRBD und halten Sie es einfach, wirklich einfach - so können Sie es einfach verwalten und debuggen, wenn die Dinge nicht funktionieren.

**Server 1**        **Server 2**        **Server 3**
LB                           
Web                 Web                 Web 
                                        DB  

Auf diese Weise erhalten Sie eine Lastverteilung und eine vollständige Auslastung der Hardware. Im schlimmsten Fall - wenn Server 1 oder Server 3 ausfallen - ziehen Sie die Festplatten und legen sie in Server 2 ein. Mit Remote-Händen an einem DC kann dies innerhalb von ~ 5 Minuten erfolgen. Es wird eine verdammt einfachere Site sein, die bedeutet, dass Sie kein 30-seitiges Dokument über die Konfiguration der Maschinen und Run-Book-Prozeduren erstellen müssen und die Einrichtung erheblich weniger Zeit in Anspruch nimmt.

Wir haben Server mit einer Betriebszeit von mehr als 3 Jahren. Daher sollte relativiert werden, wie oft Geräte mit Serverqualität ausfallen. Meistens liegt die häufigste Ursache für Probleme auf einem Server in einer zweifelhaften Softwarekonfiguration.

Meine einzige Sorge ist, dass Ihre Hardware nicht Serverqualität hat - daher besteht möglicherweise das Risiko höherer Ausfallraten -, sondern das Risiko, das Sie durch die Verwendung dieser Hardware eingehen.

Zusammenfassend

Ich würde nicht empfehlen, die Serverkonfiguration für einen E-Commerce-Shop selbst zu erstellen, zu verwalten und zu überwachen, in dem Hosting und Support die wichtigsten Bestandteile sind, um Ihr Unternehmen online zu halten.

Ein einzelner Server?

Ich würde niemals eine Lösung empfehlen, die einen SPoF (Single Point of Failure) für den E-Commerce enthält

FWIW, ich arbeite derzeit an einem Einrichtungshandbuch für den Elastic Beanstalk-Dienst von Amazon, mit dem Sie automatisch in allen Dimensionen skalieren können, während Sie nur für die Ressourcen bezahlen, die Sie tatsächlich verwenden.

Natürlich ist alles mehrzonig und hat Redundanz und Failover eingebaut :)

Die Wartung ist ein Kinderspiel - und Sie können Ihr Magento entweder direkt mit den AWS-Befehlszeilentools und Git aktualisieren oder indem Sie eine Zip-Datei Ihrer Magento-Anwendung in die AWS-Konsole hochladen - einfacher geht es nicht!