既存の顧客の既存の仮想マシンは、さらに変更なしでサービスされます。 また、「予備の車」を作らないでください-良い状況からではなく、新しい顧客の受け入れを停止しました。
その理由は、計算されたキャパシティの境界を越えており、「外出先で」アーキテクチャを書き換えることはひどい習慣だからです。 この点で、タイムアウトを取り、広告部門を追いかけるのをやめることにしました（ちなみに、このため、Habréについては黙っていました-訪問者の流れを少し減らすことを望みました）。 しかし、人々が来ました-そして、それは面白いポイントになりました、長く慎重に書かれたコンポーネントの1つで、私たちは約10kの接続で天井に置きました。 テスト/修正（プリプロダクションプロセス）は1か月遅れました...そして、このコンポーネントを展開する頃には、すでに「突っ込んでいる」（1秒あたり6-9k接続）ことがわかりました。 しかし、私たちは数ヶ月間それを書きました！
そして、私たちは単に対処できなかったことが明らかになりました。 新規顧客の受け入れを停止する決定は簡単ではありませんでした（「給与を支払う理由」などのスタイルの論争）。しかし、一般的な技術的感覚は会社の成功に対する健全な
処理にはどれくらいかかりますか？ 計画期間は約2〜3か月で、実際に必要な量は-わかりません。 まず、アーキテクチャを真剣にやり直す必要があるため、集中型データベースは完全に削除されます。 すべての分散化とすべてが非常に重要なタスクです。
高い確率で、既存の構成を変更できないため、クラウドの2番目のコピーが起動されます。 最初のクライアントから2番目のクライアントへのクライアントの移行がどのように見えるか-繰り返しますが、わかりません（まだ考えていません）。
読み取りエラー
事故について。 はい、私たちは非常に幸運で、連続して3回の一貫性のない事故がありました。 1つは日曜日、2つ目は火曜日、3つ目は金曜日です。 誰のせいですか？ まあ、それはだれが尋ねているかによるが、本質的に-私たちはそうだ。 すべての障害はソフトウェアに関連していました（当社のものではありません）。 曲がった電気技師、掃除機、その他のスケープゴートの方向にうなずくことさえできません。
見た目に興味がある人のために（品質の面でごめんなさい、高品質の撮影はできませんでした）：
クラッシュ1-150人のお客様：
事故時の稼働時間-4か月24日。 試運転以来、最初の失敗。
クラッシュ2-391クライアント：
稼働時間-6か月4日（前の事故の瞬間から。その後、NFSサーバーのバグのため、すべての仮想マシンを強制的に再起動し、/ etc / fstabからNFSの言及を削除するように人々に依頼する必要がありました）。
クラッシュ3-398人の顧客。
同じリポジトリ。 事故時の稼働時間-2日4時間。
このようなボトルネックの解消は、タイムアウトが発生したときに解決する2番目のタスクです。
クライアントデータを格納するために提案されたモデルでは、システムコアの完全かつ無条件の終了は期待していませんでした。 制御された再起動、特定のサービスの低下、多重冗長RAIDでのディスクの死（さらにはSASコントローラーの死さえ）を想定しました。 しかし、そのような「良い」というものはありません。
それが私たちの間違いでした。 そして、少なくともサービスの停止について知ることができるものに依存していたため、このエラーの責任を負います。 クラウドでの作業の過程で、これは私が取り組む主なタスクの1つになります。
問題は何ですか？
事故が発生すると、顧客は多くのジェスチャーを開始します。 マシンを再起動し、オンとオフを繰り返してみてください。
視覚的には何も起こりません。実際、システムはすべてを記憶しています。 その結果、一部のマシンのタスクキューは50〜100タスクに達します。 また、同じタスクを組み合わせる方法を学習した場合（クライアントが3回再起動を要求した場合は、1回だけ再起動する必要があります）、異なるタスクが引き続き実行されます。 はい、マシンを再起動する、電源を切る、電源を入れる、再起動する、電源を切って入れ直す、と言われた場合、まさにそれが行われます。
そして、そのような顧客が数百人いると...不愉快になります。 特に、すべてのリクエストがほぼ同時に来る場合。 プールマスターには、平凡な方法で十分なリソースがありませんでした。 つまり、プロセッサ負荷の800％と数百のジョブのキューです。
しかし、プールマスターをいくつかに分割するには、まったく準備ができていません。 これまで。 これは、私たちが考えるタスクの1つです。
upd：記事は私の参加なしに公開されました 。 写真は明日です。