問題タブ [infrastructure]

私たちが持っているシナリオは、私たちの組織がいくつかの地理的な場所にあるというものです。

分散した各チームが変更をプッシュして残りのチームと共有できるように、git中央サーバーをセットアップしたいと思います。

私はそのようなことをするための最良の選択肢は何であるか疑問に思っています。

私が考えることができる現在の2つのオプションは次のとおりです。

1. すべてのグローバルチームに1つの中央サーバー。
2. 地理的サイトごとに1つの中央サーバー。同期を維持するために、サーバー間にある種の自動PUSHを設定します。
3. ホスト型ソリューション。

＃3は現在、私たちの組織AFAIKのオプションではありませんが、他にそうするオプションはありますか？最良の選択肢は何ですか？

この特定の問題を解決するためのガイドラインとベストプラクティスがすでにいくつかあると思います。

多数の人が使用する多数の異なるサービスを備えた多数のサーバーを管理することを想像してみてください。ここで、それらのサーバーの 1 つで、一部のソフトウェアを再構成または交換したいとします。明らかに、運用中のサーバーで作業したくないでしょう。

これがコードの変更である場合、開発者として、ローカルの開発マシンで変更を行い、ローカルでテストして、変更をバージョン管理システムにコミットします。その後、変更をステージング環境にデプロイし、さらにテストして、最終的に本番環境にデプロイできます。必要に応じてロールバックすることも簡単です。

一般的に、または具体的に、システム管理でこれをどのように達成しますか?

(最初に頭に浮かぶのは、仮想マシンを使用して仮想マシン イメージをバージョン管理することですが、私が現在認識していない文献や巧妙なソリューションがたくさんあると確信しています。)

EC2 で自動スケーリング グループを使用する場合、ドキュメントには、cloudwatch メトリクスに基づいて新しいサーバーをトリガーできると記載されています。自分で新しいインスタンスを起動することはできますか?

たとえば、アプリにはアイテムの内部キューがあり、そのキューがしきい値に達すると、EC2 に通知を送信してグループにサーバーを追加します。

それは可能ですか？

現在、Magento を搭載した 1 台のサーバーを所有しているクライアントがいてadmin、更新のためにサイト全体を数時間ダウンさせています。彼がどのように設定すべきかについて新しい解決策を提案したかったので、私はそれを即座に処理したいと思います。

• Magento 本番サーバー 1 (WEB+DB)
• Magento 本番サーバー 2 (WEB+DB)
• マジェント開発サーバー 1

DBはこれらの2つのサーバー間で何らかの方法で同期する必要があり(クラスター?レプリケーション?)、可能な限りダウンタイムを最小限に抑えるために、最初にDev Server(アップグレードの直前に本番サーバーからDB / WEBを同期)で更新をテストする必要があると考えていました。それが正常に動作することを確認し、プロセスがどのように見えるかを知ることで、サーバー 1 のみに対して LoadBalancing または RoundRobin DNS を無効にしてから、サーバー 2 でアップグレード/更新を行い、次に運用サーバーとしてサーバー 2 に切り替え、サーバー 1 を更新します。オン LoadBalancing/ラウンド ロビン オン。

私はWindows環境から来たので、これはWindowsで行う方法です（おそらく別のデータベースとWebでも）、RedGate SqlCompare/Sql Data Compareなどのツールを使用すると動作するはずです。

しかし、私はMagentoをまったく知らないので、クライアントが自分のショップをダウンさせたくない場合に何が可能で、どうすればよいか教えてください...

だから私はいくつかのコンポーネントを持つ会社のプロジェクトを始めています:

初めに...

1. ジョブリスト
2. クライアント プロファイルの作成と管理
3. ユーザー管理とアクセス (ログイン、サインアップ、役割など)

後で...

1. メッセージング
2. スケジュール
3. 基本的なレポート

ずっと後...

1. より深い分析とバイ

各箇条書き項目が独自の Rails プロジェクトであり、自己完結型でモジュール式であることが理にかなっているのかどうか疑問に思っています (実際にそうである場合)。または、同じアプリにあることが最善の場合。各モジュールが互いに独立して動作し、残りの部分 (ユーザー機能を除く) を必要としない状況と、すべてのモジュールが一緒に使用される別の状況を想像できました。

多くのタスクは、Sinatra のような軽いフレームワークで処理できるように思えます (そして、レール アプリの下に物理的に置かれます)。また、複数の Rails アプリをサーバー上で実行すると、多くのオーバーヘッドが発生するようです。しかし、私は各シナリオを運用する上でのプラスとマイナスのすべてを完全に認識しているわけではありません。

これは一種の一般的な質問であり、多くの「場合による」種類の回答が得られることはわかっています (当然のことですが)、この種の/あなたの種類のプロジェクトをレールでどのようにセットアップするかについての意見/例を探していました。準初心者なのでお手柔らかに。

前もって感謝します！

開発チームと、アプリケーションサーバーにローカルMTAをインストールするか、内部ネットワークにあるMTAサーバーを使用して電子メールを送信するかについて話し合いました。両方のソリューションには長所と短所があります。

長所：電子メールを送信するプログラムは、それをローカルMTAに配信し、配信、再試行、または発生する可能性のあるエラーを忘れることができます。

短所：電子メールを送信するユーザーは、メールの送信に問題があったことを遅く通知される場合があります。プログラムは、リモートサーバーが利用できないかどうかをすぐに検出できます。短所：セキュリティ。ローカルMTAは、サーバーのセキュリティを確保するために適切に構成する必要があります。短所：プロセスの複雑さの追加レイヤー。

私の見解では、それを単純に保つ必要があります。私たちは、私たちによって制御されておらず、その状態がわからないMTAサーバーと通信しているプログラムについて話しているのではありません。私の見解では、カウンターパーツについて確信が持てない場合は、ローカルMTAを用意する必要がありますが、ここでは、プログラムがそれを「既知の」MTAシステムに配信します。ですから、追加のレイヤーは必要ないと思います。さらに、各システムにローカルMTAを設定して電子メールを送信しようとすると、追加の問題/エラーやより多くの管理タスク（メンテナンス/パッチ）が発生する可能性があります。Unixシステムでは常にローカルMTA（sendmail）を実行していると言う人もいるかもしれませんが、私たちの組織では、潜在的なリスクにつながる可能性のある余分なサービスが実行されないように、システムを最小限に抑えています。

ただし、既知の/制御された/監視されたMTAシステムと通信することを念頭に置いて、インフラストラクチャをどのように設計するかを知りたいと思います。それとも単に視点の問題ですか？

フィードバックをありがとうございます。

イヴ

私は、それがフェッチ、分類、...（通常はクロール）に使用するナッチとそのアルゴリズム（私のプロジェクトに関連しているため）について知りたいと思っています（そして知る必要があります）。私はこの
資料 を読みましたが、少し理解しにくいです。 完全でわかりやすい方法でこれを私に説明できる人はいますか？ 前もって感謝します。

OnStart()「小さな」インスタンスを使用して、Azure ロールで実験しています。ドライブ D の「ローカル ストレージ」にある 400 メガバイトの ZIP ファイルをドライブ E のフォルダに展開するには、約 2 分かかります。

他の方法で実行する必要があるかもしれませんが、Azure VM 上のローカル ディスクの通常の速度に関するデータが見つかりません。

Azure VM ローカル ディスクの速度に関するテスト結果はありますか?

現在のプロジェクトの 1 つのインフラストラクチャを構築しているときに、既存の HDFS ファイルを置き換えるという問題に直面しました。より正確には、次のことを行いたいです。

継続的にログを生成しているいくつかのマシン ( log-server ) があります。log-serverからログ チャンク (各チャンクの長さは約 30 分、サイズは 500 ～ 800 MB) を受信し、それらを前処理し、Hadoop クラスターの HDFS にアップロードする専用マシン ( log-preprocessor ) があります。 .

前処理は 3 つのステップで行われます。

1. 各logserver : フィルター (並列) 受信したログ チャンク (出力ファイルは約 60 ～ 80 MB)
2. ステップ 1 からのすべての出力ファイルを結合 (マージソート) し、マイナーなフィルタリングを行います (さらに、30 分のファイルは 1 時間のファイルに結合されます)。
3. 外部 DB からの現在のマッピングを使用して、ステップ 2 のファイルを処理して最終的なログ ファイルを取得し、このファイルを HDFS に配置します。

最終的なログファイルは、HADOOP クラスターで実行されているいくつかの periodoc HADOOP アプリケーションの入力として使用されます。HDFS では、ログファイルは次のように保存されます。

問題の説明:

ステップ 3 で使用されるマッピングは時間の経過とともに変化するため、ステップ 3 を再計算し、古い HDFS ファイルを新しいファイルに置き換えることで、これらの変更を反映する必要があります。この更新は、少なくとも過去 12 時間は一定の周期 (10 ～ 15 分ごとなど) で実行されます。マッピングが変更された場合、同じ入力ファイルに step3 を適用した結果が大幅に異なる可能性があることに注意してください(以前の結果の単なるスーパーセット/サブセットにはなりません)。したがって、HDFS の既存のファイルを上書きする必要があります。

ただし、一部の HADOOP アプリケーションが一時的に削除されたファイルを使用している場合、アプリが失敗する可能性があるため、hadoop fs -rmを実行してから hadoop fs -copyToLocalを実行することはできません。私が使用する解決策 - 新しいファイルを古いファイルの近くに置きます。ファイルの名前は同じですが、ファイルのバージョンを示す接尾辞が異なります。現在、レイアウトは次のとおりです。

開始 (セットアップ) 中の Hadoop アプリケーションは、最新バージョンのファイルを選択し、それらを操作します。そのため、何らかの更新が行われている場合でも、入力ファイルが削除されないため、アプリケーションで問題が発生することはありません。

質問:

1. この複雑で醜いファイルのバージョン管理を使用しない、この問題へのより簡単なアプローチを知っていますか?

2. 一部のアプリケーションは、現在アップロード中だがまだアップロードされていない HDFS ファイルの使用を開始する場合があります (アプリケーションは HDFS でこのファイルを参照しますが、一貫性があるかどうかはわかりません)。gzip ファイルの場合、これによりマッパーが失敗する可能性があります。どうすればこの問題を処理できるかアドバイスをいただけますか? ローカルファイルシステムの場合、次のようなことができることを知っています:

   cp infile /finaldir/outfile.tmp && mv /finaldir/output.tmp /finaldir/output

mvはアトミック操作であるため、これは機能しますが、これが HDFS の場合かどうかはわかりません。従来のローカル ファイル システムでHDFS にmv のようなアトミック操作があるかどうかアドバイスをいただけますか?

前もって感謝します！