web-dev-qa-db-ja.com

予算内でのMagentoホスティング

Magentoのセットアップを行う必要があります。私の制約は、主にセットアップの容易さとフォールトトレランス/フェイルオーバーです。さらに、コストが問題になります。私は仕事を成し遂げるために3つの同一の物理サーバーを持っています。各サーバーノードには、ソフトウェアRAID 1構成でi7クアッドコア、16GB RAM、および2x3TBHDがあります。各ノードはUbuntu12.04を実行します。たった今。これらのノードのいずれかにルーティングできる追加のIPアドレスがあります。

Magentoショップには最大数があります。 1000製品、その50％はバンドル製品です。私はその最大を推定します。一度に10人のユーザーがアクティブになります。これは、パフォーマンスがここでは最優先事項ではないという結論に私を導きます。

私の最初のセットアップのアイデア

1つのノード（lb）は、ロードバランサーとしてnginxを実行します。追加のIPはドメイン名で使用され、デフォルトでこのノードにルーティングされます。 Nginxは、他の2つのノード（shop1、shop2）に負荷を均等に分散します。 Shop1とshop2は等しく構成されています。各サーバーはApache2とMySQLを実行します。 Mysqlは、マスター/スレーブレプリケーションで構成されます。

私のフェイルオーバー戦略：

  • Lbが失敗する=> IPをshop1（MySQLマスター）にルーティングし、続行します。
  • Shop1が失敗する=> Lbはそれを自動的に処理し、shop2のMySQLスレーブをマスターにプロモートし、書き込みにshop2を使用するようにMagentoを再構成して続行します。
  • Shop2が失敗する=> Lbがそれを自動的に処理し、続行します。

これは正気の戦略ですか？ Magentoで同様のセットアップを行った人はいますか？

私の2番目のセットアップのアイデア

これを行う別の方法は、mySQLデータファイルをshop1とshop2に保存するためにdrbdを使用することです。このシナリオでは、1つのノード/ MySQLインスタンスのみをアクティブにでき、もう1つはホットスタンバイとして使用されることを理解しています。したがって、shop1に障害が発生した場合は、shop2でMySQLを起動し、IPをshop2にルーティングして、続行します。 MySQLのセットアップが簡単で、ノードを99％同一に構成できるので、私はそれが好きです。したがって、この場合、ロードバランサーは役に立たなくなり、予備のサーバーがあります。

私の3番目のセットアップのアイデア

3番目の方法は、MySQLデータベースのマスターマスターレプリケーションです。ただし、私の意見では、Magentoはこのシナリオ用に構築されていないため（新しい行のIDが競合するなど）、これは注意が必要な場合があります。実例を聞くまではそうしません。

どのルートをたどるかアドバイスをいただけますか？それを行うための「良い」方法は1つではないようです。例えば。 MagentoのMySQLマスター/スレーブセットアップについて説明しているブログ投稿を読みましたが、他の場所では、スレーブがマスターより遅れているとデータが重複する可能性があります（たとえば、注文時に顧客が2回作成される可能性があります）。私はここでちょっと迷っています。

failoverdrbdmagentomaster-slavemaster-master
7
spa

KISS

単純にばかげてください。

私はここでちょっと迷っています。

このため、複雑にする必要のないものを過度に複雑にし始めないでください。最初に何かを実装するための正しい方法がわからない場合、何かがうまくいかなかったときに何をすべきかは確かにわかりません。

まず、ハードウェアについて説明します

参照： https://www.sonassihosting.com/help/magestack/cpu-sizing/

a）標準のMagentoデモストアは、1時間あたり1GHzあたり約230のユニーク数を配信できます。

b）管理者ユーザーアクティビティ、開発アクティビティ、製品の追加/削除を行う一般的なWebストアでは、これが約100％低下し、1時間あたりGHzあたり115の一意になります。

いつでも100人のアクティブな訪問者の数字を使用して、

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

したがって、サイトでの業界平均時間は1回の訪問あたり8分、8ページビューであると想定します。

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

これにより、750時間ごとのユニークビジター数、または1日あたり約7,500の数値が得られます。ユニークビジター。

115ユニーク/ GHzで1時間あたり750人の訪問者をサポートするには、7x 1GHzCPUコアに相当するものが必要です。それで、あなたのi7クアッドコアが2.5GHzであると仮定しましょう-それは累積合計10GHzを与えるでしょう。

次に、構成に対処しましょう

あなたの目標は正確には何ですか？

  1. 高可用性
  2. 信頼性
  3. 管理のシンプルさ
  4. パフォーマンス
  5. スケーラビリティ

あなたのアイデアはどれも特に良いものではありません。ロードバランサーは単一障害点であり、MySQLの冗長性に少し巻き込まれすぎているように感じます。

マスター-マスターは構成の悪夢であり、noのメリットがあります。 Magento IS少しでもMySQLにバインドされていません。参照 どちらを大きくする必要がありますかマシン？MagentoデータベースのMagento Webサーバー？

そして、アーキテクチャ内のすべてを冗長にすることを計画していない限り、つまり。

  1. 結合ネットワークインターフェース
  2. A + Bスイッチ
  3. A + Bファイアウォール
  4. A + BはさまざまなUPSから給電を分離します
  5. マルチホームアップストリーム接続

...ソフトウェア層である程度の回復力を構築しようとしても意味がありません。

どのようにそれを行うか

Magentoで同様のセットアップを行った人はいますか？

一言で。はい。

MageStackでは、単一サーバーからnサーバーまで、すべての単一ノードをコンテナ化することで構成します。

したがって、あなたの場合、通常は次のように設定します（HAを要求したと仮定します）。

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

LBおよびDB仮想サーバーは、DRBDミラー（<==>で表される）にルートパーティションを持ちます。 Webノードは、共通のNFSストアを使用するか、より一般的には、ライブWebノードのレポプルを使用します。

ここで返信を参照するだけです VarnishでWebサーバーを配置する方法は？

私たちの典型的なアーキテクチャは

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

ハートビートは、マシン間のヘルスチェックを維持し、IPのフェイルオーバーを提供し、それぞれの仮想サーバーを開始/停止します。

したがって、結果として得られるコンテナ化されたアーキテクチャは次のようになります...（グラフィックを失礼します。マーケティングPDFからポーチしました）。

MageStack example configuration

私はあなたがそれをすることをどのように勧めますか

マスター/スレーブを使用せず、DRBDを使用せず、本当にシンプルに保つだけです。そのため、問題が発生したときに管理とデバッグを簡単に行うことができます。

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

そうすれば、負荷分散とハードウェアの完全な利用が得られます。最悪のシナリオ（サーバー1またはサーバー3に障害が発生した場合）では、ハードドライブをプルしてサーバー2に配置します。リモートハンドを使用してDC-これは約5分以内に実行できます。管理が簡単なサイトになります。つまり、マシンの構成とRun-bookの手順に関する30ページのドキュメントを作成する必要がなく、セットアップにかかる時間が大幅に短縮されます。

稼働時間が3年を超えるサーバーがあるため、サーバーグレードの機器が故障する頻度を考慮する必要があります。多くの場合、サーバー上の問題の最も一般的な原因は、純粋に危険なソフトウェア構成にあります。

私の唯一の懸念は、ハードウェアがサーバーグレードではないことです。そのため、故障率が高くなるリスクがありますが、それを使用して選択するリスクがあります。

要約すれば

ホスティングとサポートがビジネスをオンラインに保つための最も重要な部分であるeコマースストアのサーバー構成を自分で構築、管理、監視することはお勧めしません。

14
Ben Lessani - Sonassi

単一のサーバー？

Eコマース用のSPoF（単一障害点）を含むソリューションは決してお勧めしません

FWIW、私は現在、AmazonのElastic Beanstalkサービスのセットアップガイドに取り組んでいます。これにより、実際に使用するリソースに対してのみ料金を支払いながら、すべてのディメンションを自動的にスケーリングできます。

もちろん、それはすべてマルチゾーンであり、冗長性とフェイルオーバーが組み込まれています:)

メンテナンスは簡単です-AWSコマンドラインツールとgitを使用して直接Magentoを更新するか、MagentoアプリケーションのZipをAWSコンソールにアップロードすることで更新できます-それ以上に簡単なことはありません！

0
Lee Bolding