Railwayの自前データセンター構築記
(blog.railway.com)- Railwayは、GCPベースのコンピュートが価格・サポート・機能開発を制約していると考え、より直接的に制御できる物理インフラであるRailway Metalを開始した
- 2024年1月に着手してから最初のサーバー接続までに5か月、ユーザーワークロード投入までさらに3か月を要し、9か月後にカリフォルニア最初のサイトが稼働した
- スペース賃貸よりも大きな制約は電力と冷却であり、RailwayはGreenfieldやラック単位の賃貸ではなくCage Colocationを選択した
- ネットワークは地域ごとに最低2つのISP、完全なインターネットルーティングテーブル、IP prefixごとの経路選択、複数zone設計によって単一データセンター障害に備えている
- ラック配置、ケーブル文書、PDU、逆方向airflowスイッチ、Redfish API、PXE、FRR、SONiCまで自分たちで扱う必要があり、自前クラウド構築はTerraformデプロイよりも家を建てる仕事に近い
GCPからRailway Metalへ移行した理由
- Railwayのコンピュートは当初からGoogle Cloud Platform上に構築されていた
- GCPは初期成長には役立ったが、運用規模が大きくなるにつれて、顧客に望むプラットフォームを提供するうえで限界が生じた
- ハイパースケーラー基盤での運用は、Railwayが提供できる価格、サービスレベル、機能開発の範囲を直接制限していた
- egress feeが価格に影響する
- 上位インフラで問題が起きても、その原因を理解できることはまれ
- 年間数百万ドルを支払っていても、サポートレベルは100ドル使う場合と大差ないと評価している
- Railwayはこれに対応するため、2024年にRailway Metalプロジェクトを開始した
- 9か月後にカリフォルニア最初のサイトを稼働させた
- ケージ内の光ファイバーケーブルからISP契約まで、設計、仕様定義、設置を自ら進めた
- さらに3つのデータセンターregionを立ち上げている最中である
最初のスペース選定: データセンターケージ
- Railway Metalプロジェクトは2024年1月に始まり、最初のサーバーを接続するまでに5か月かかった
- ユーザーワークロードをハードウェアに載せてもよいと判断するまで、さらに3か月を要した
- 自前インフラには、サーバーを置くスペース、安定した電力、十分な冷却が必要である
- 選択肢は大きく3つあった
- Greenfield buildout: データセンターを購入または賃借する
- Cage Colocation: 事業者データセンター内にメッシュ壁で囲まれた専用スペースを確保する
- Rack colocation: コロケーションデータセンターで個別ラックまたはラックの一部を賃借する
- Railwayは、4面の壁、セキュリティドア、その他を自分たちで設計できる空のスペースを得るためにCage Colocationを選んだ
- スペース自体のコストは大きくないが、最も大きいのは電力とそれに伴う冷却コストである
- 地域によってkWあたりのコスト差が大きい
- 米国西部ではシンガポールの半額以下で済むこともある
- 電力は実使用量に関係なく、オンデマンド可用性を保証するための月額コミットで支払う
電力設計とPDU
- Railwayは、GCPで使っていた容量に合わせるため、まず目標のvCPU数、RAM GB、NVMe TBを定めた
- その数値をもとにサーバーとCPUを選定した
- 中核となる変数は、一定の消費電力内に望むコンピュート密度を収める電力密度だった
- 電力計算はwattの単純合算では終わらず、特に3相電源ではより複雑になる
- Cloudflareの3相電力とPDUの紹介が関連内容を扱っている
- データセンターでは電力が最も重要な資源であり、停電は復旧時間が非常に長くなる可能性がある
- 各ラックには完全に独立した2本の電源feedが必要である
- 平常時には2本のfeedで負荷を分散する
- 片方のfeedが落ちても耐えられなければならない
- サーバーに電力を届けるにはPower Distribution Unitが必要である
- 基本的なPDUは、実質的には拡張電源タップに近い
- Railwayが配備するPDUは個別ソケットの制御と計測が可能である
- 各PDUにはネットワーク経由でアクセスでき、個別ソケットをリモートで計測・制御できる
ネットワーク: ISP、ルーティング、地域別経路
- クラウドマシンは単独では存在しないため、ネットワークが重要な役割を担う
- Railwayは低レイテンシのため、外の世界と強固に接続されたデータセンター設備を探した
- 希望条件は次のとおりである
- Tier 1 ISPとon-networkの状態である
- Internet Exchangeに接続されている
- 近隣の別データセンターへ接続できる光ファイバーがある
- Railway上にデプロイされたアプリケーションは、多様なエンドポイントと通信する
- シドニーの家庭用インターネット利用者
- 米国AWSサーバーでホストされたAPI
- 低レイテンシと低帯域コストのため、Railwayはユースケースごとに最適化された複数のインターネットプロバイダーと契約した
- ISPは対象地域でのネットワーク成熟度を基準に選定する
- 誤ったISPと組むと、特定のターゲット市場まで余計なネットワークhopが生じ、レイテンシが増えることがある
- 最悪の場合、複雑に入り組んだネットワーク経路が生じうる
- 各地域で地域footprintを基準に最低2つの独立したネットワークを選んでいる
- 接続後は各ISPから完全なインターネットルーティングテーブルを受け取り、ネットワークスイッチで統合してIP prefixごとの最適経路を決定する
- オーストラリアの利用者がシンガポールにデプロイされたアプリへアクセスする場合、Telstraにパケットを渡す可能性が高い
- 同じアプリが日本の利用者やサーバーへパケットを送る場合、PCCWに渡す可能性が高い
- Peering情報は公開されており、bgp.toolsでネットワーク相互接続を確認できる
- 冗長化のため、各region内に複数のzoneを構築しており、サイト間相互接続も拡張に重要である
- dark fiberやwavelength serviceのような手段を検討している
- アプリは、データベースが同じ部屋にあっても4ブロック離れた隣の建物にあっても違いを感じないことを目指している
- 個別データセンター障害への耐性を高めるための設計である
ラック、通路、冷却、ケーブル経路
- データセンターではラックを列状に配置し、ラック間の通路を空気の流れに使う
- Cold Aisleには施設から冷気が入り、サーバーはその空気を吸い込んだあと、背面のHot Aisleへ排出する
- 効率を高めるには、Cold AisleとHot Aisleの空気が混ざらないようにしなければならない
- ラックは19インチ幅の機器を使うとしても、高さ、幅、奥行きを機器やケーブル要件に合わせて選べる
- 多くのサーバー機器は保守のためレール上で前方に引き出せるので、ケージ寸法はそれを許容する必要がある
- ケーブルやケーブル管理にもスペースが必要なため、ラックをどれだけ高密度に詰めるかと、ケージ内にいくつラックを入れるかの間にはトレードオフがある
- Railwayの経験では、実際のスペースよりも電力と冷却のほうが制約になることが多い
- 新規サイトでは、ケーブルを排気経路から遠ざけてairflowを改善するため、800mm幅のより広いラックを選択した
- ラック以外にも、電力とデータを届けるための上部インフラやトレイが必要である
- ケージ外周から各ラックまで光ファイバーを配線する
- ラック間ケーブルも配線する
- こうした項目はデータセンター運営者がケージ見積もりに含める場合がある
- Railwayはラックごとのswitch-to-server光ファイバーケーブル密度が高いため、ポートがラック背面を向くreverse airflow switchを購入した
- ネットワークポートがある側へ排気するスイッチである
- ケーブルトレイを合わせ、すべての配線をラック片側で行えるようにした
- ラック前後でケーブルがジグザグに行き来する状況を避けている
設置文書とrack-and-stack
- Railwayは最初、自分たちで配線を試みたが結果にばらつきがあり、適切に設置するため専門家を投入した
- 設置専門家が何をどこに設置すべきか理解できるよう、包括的な文書パッケージが必要だった
- 一般的な文書は2種類ある
- Cabling matrix: 各ケーブル両端の機器位置、ポート、ケーブル仕様、光ファイバー種別、長さなどを定義する
- Rack elevation: ラック内での各機器の位置と向きを視覚的に示す
- Railwayの各設置フェーズには、60台以上の機器、300本以上の個別ケーブル、数十項目の細部が含まれる
- 設置と試運転の土台となる書面仕様やスプレッドシートは手作業で作られた
- 資材が現場に到着してからすべての設置を終えるまでには約6〜14日かかった
- その後Railwayは、build specification生成を自動化する社内ツールを作った
- データセンターケージの構築は、一般的なソフトウェア、DevOps、Terraformスタックのデプロイとは大きく異なり、家を建てる作業に近い
- データセンター設備、請負業者、ベンダーごとに、同じ組織内でも進め方が少しずつ異なるため、運用上きわめて細かな注意が必要である
現場で遭遇した例外と物理的問題
- あるサイトではPDUが上下逆に設置されており、電源が床から入っていたため、設計上のソケット番号が逆になっていた
- Amsterdamの現場では、専用demarcation pointではなく、外部光ファイバーリンクがラック内のボックスへ直接入る設備方式があった
- ある設備では他サイトと異なり、電源ソケットがphase-to-neutral方式で配線されていた一方、別の場所ではphase-to-phase方式だった
- 請負業者がネットワーク機器がreverse airflowであることを知らず、逆向きに取り付けようとしたため、データケーブルが短いと判断した事例があった
- 特定のケーブルでlinkが上がらない原因は光ファイバーのpolarity誤りで、Railwayはそのとき「rolling fibre cables」を知った
- LC connectorのプラグを抜いて入れ替える方式である
- あるベンダーのPDU約24台はソケット不良で電源プラグが正しく刺さらず、強い物理的力を加えても解決しなかった
物理設置後のソフトウェア作業
- ハードウェアが所定の位置に収まった後は、作業はより馴染みのあるソフトウェア領域へ移る
- 必要な作業は次のとおりである
- BGP設定
- OSインストール
- 監視構成
- ネットワーク機器設定
- ルーター設定作成
- RIR、すなわち地域インターネットレジストリ記録の更新
- サーバーとPDUの専用コントローラーへアクセスするためにRedfish APIsを使う
- サーバーをネットワーク経由で起動するためにPXEを使う
- Railwayのネットワーク設計では、FRRとSONiCを実行するwhitebox network switchを使用する
- この設計により、Railway control planeと深く統合されたL3-onlyソフトウェア主導ネットワークを構築している
- ここ数か月でRailwayは新しいソフトウェアツールRailyardとMetalCPを作った
- 新しいケージ設計
- ケーブル追跡と可視化
- サーバーOSインストール
- サーバーをインターネットへ接続する工程まで、ボタンクリックで実行できる体験を可能にするツールである
- 次回の記事では、部屋いっぱいのサーバー群を機能するRailway zoneへ変えていく過程を扱う予定である
1件のコメント
Hacker News のコメント
自分の経験やこういう記事を見ていると、Google は顧客がいることを嫌っているように思える。
誰かが「パブリッククラウドはやるべきだ」と決めて作ったものの、顧客のことは3メートルの棒で押しのけたい、という感じがする。
AWS のアカウント担当者は、必要なら泥沼でも一緒に転げ回ってくれる人だと100%確信している。危機的状況で頼めば、床で一緒に寝てくれる人だ。
一方で Google Cloud の担当者たちを見ると悲しくなる。彼ら自身も、私たち以上に Google 社内で愛されておらず、支援も受けていないのが見えるからだ。自社にきちんと売らせ、サービスさせようと説得している人を見るのは気の毒で、失敗するように仕組まれているように思える。
Microsoft 側の人たちは防弾のように強固で、営業もうまく、サービス提供もうまく、私の懐からお金を全部絞り取りながらも、それが私にとって良いことなのだと死ぬほど信じ込ませてくる。ただしクラウドは非常に奇妙な……何かだ。
Railway がベアメタルへ行くというのは、15年ほどやってきた立場からすると、絶対に、絶対に、絶対に戻りたくない。そこまでの価値はない。とはいえ、自分で経験してみないと分からないのだろうし、もともとそういう道なのだ。
すぐに Google がいったいなぜあれほど苦労しているのか分かるだろう。ただし、Borg や人工頭脳を作る代わりに、人々にサービスを売りたいという気持ちが本当に強いなら、Google より100倍うまくやれる。
それでも泥沼で一緒に転げ回ってくれるとは思えないので、そこは少し驚きだ。いったいどれだけ使えば泥沼同行の段階に入るのか気になる。
クラウドサービス全体が、クラウドコンピューティングをまったく知らない人が「ベアメタルサーバーのレンタル」だけを知って設計したかのように感じられる。クラウドコンピューティングではあるのだが、クラウドコンピューティングという概念そのものを壊す形になっている。
GCP のコマンドラインツールである
gcloudも、よりよく設計されているように感じる。そうすれば、数か月分の先行作業を節約できた。
個人的な経験では、Google Cloud のサポートは3人の小さなチームがごく少額しか使っていない状況でもかなりよく対応してくれたし、別の会社では Microsoft も非常によく対応してくれた。ただしそのときの支出規模は、おそらくデータセンターの電力網監視でも追跡できるレベルだったはずだ。
一方で AWS は機能について嘘をつき、結局最後まで回答もしなかった。
上級経営陣と必須の数百万ドル規模の AWS 契約について話すアカウント担当者たちは、その経営陣にどう話せばよいかをよく知っているようだ。
しかし実際に他者向けの製品を開発し提供する段階では、私たちだけが埃の中に取り残された。
さらに笑えるのは、その嘘をつかれた機能が、エンドユーザー体験を非常に優れたものにするうえで核心になる機能だとして売り込まれていた点だ。
サポートチケットに返信したが反応はなく、AWS の担当者2人にメールを送ったが、やはり返事はなかった。
昔の Rackspace 時代を思い出す。本当に戦争のような出来事が多かった。
EMC の人たちがテスト用のストレージ機器を設置しに来たところ、互いに足がもつれて、コメディのようにサーバーラックを丸ごと倒してしまった。当然、契約は取れなかった。
あるトラック運転手が心臓発作を起こし、その事故で DFW データセンターがオフラインになった。こういう事態を防ぐためにボラードはあったが、まだセメントが充填される前だった。
一時期は、通りの向こうの別の建物までレーザーで帯域を飛ばして一時接続していた。
ある日はサーバーが文字どおり燃え始め、窓を割ってボックスファンを買ってきた。
データセンター工学は初期のころからかなり進歩した。当時 Facebook と一緒に OpenCompute Project をやっていたが、その時点では非常に先進的なインフラの考え方がいくつもあった。
重要なマイクロ波リンクが、データリンク層の奥深くで断続的なパケットエラーを伴いながら切れ続けた。調べてみると、通りの向こうの木に葉が生え、枝がうちの建物の機器の見通し線の中へ揺れて入り込んでいた。はしご、のこぎり、10分で接続を復旧した。
データセンター外へ出るメインの BGP ルーターが再起動を繰り返していた。冗長機はなかった。確認すると、データセンターの温度が高すぎ、冷却があまりに悪く、吸気ファン側の空気温度が 60°C を超えていた。応急処置としてファンをそこへ向けて立てた。
数週間後、別の部屋のエアコンも壊れ、Nortel DMS-100 の上に水を吹き出し始めた。自前のスイッチを持つダイヤルアップ ISP だった。水に電気が流れているかもしれないと思い、拭き取りを手伝いたくはなかったが、仕方がなかった。
その後、小さな離島でも働いた。インターネットの主回線は GS 衛星経由の 1MB/s リンクで、ping は 500ms 以上だった。地元の人たちは 9600 ボーで等級付けされたマイクロ波電話網でダイヤルアップしていたが、どういうわけか 56k モデムが動いていた。
ある日、Solaris マシンに重要な
.soが欠けていることに気づいたが、ローカルバックアップもインストールメディアもなかった。英国の友人に電話して FTP サーバーにコピーを置いてもらい、そのマシンを再びオンラインに戻した。数年後には、Manchester の Oxford Road、当時ヨーロッパで最も混雑していたバス路線の上に レーザーリンクを設置し、オフィスと大学キャンパスを接続したこともある。楽しい時代だった。
全部とても面白かったが、今はほぼソフトウェアだけをやっていられるのが本当にありがたい。
サーバーが文字どおり火を噴いたわけではないにせよ、窓を開けてファンを使うようなことは、2024年1月に Chicago の Equinix CH1 データセンターでも起きた。Azure ExpressRoute が落ちた。
寒くなりすぎて CRAC が耐えられなかったらしいと聞いた。十分に冷たく保とうとしてすべてのドアと窓を開けていたそうだが、結局失敗した。CRAC が逝くとサーバーも一緒に逝く。
あのスイッチは間違いなく呪われていた。その週の後半、同じ機器でスパニングツリーの設定ミスが起き、LINX が数時間停止し、英国 ISP ピアリングの半分が一時的な混乱に陥った。そのプロジェクトに関わっていた他の人たちも、2年以内に全員この世を去った。
数年後に施設を見て回ったところ、その下の床に焼けた死骸がまだ残っていた。
記事に出てきた「年間数百万ドルを使っても、100ドル使う人と同じ程度のサポートしか受けられない」というくだりは痛い。Google にとってはかなり大きな問題だ。
この記事が特に面白かったのは、Blekko のインフラを構築したときに似たような冒険をしたからだ。
Blekko のようにラック間トラフィック、つまりインターネットとの出入りよりも 東西トラフィックが多い会社では、物理的に同じ場所に配置されたサービスが他のサーバーと帯域を奪い合わないことが不可欠で、SoftLayer、つまり IBM の従属クラウドでこうした特殊ケースのコストを払うより、はるかに経済的だった。
コールドアイルを囲うエンクロージャを作ってくれる、かなり良い会社もある。基本的に、床から出る冷気をすべてサーバーの背面に入れ、他の場所へ漏れないようにしてくれる。側面からあまり冷たくない空気がサーバーに巻き込まれるのも防いでくれる。
データセンターの HVAC CRAC 容量計算も興味深い。最初のコロケーション施設では、うちのケージの隣の床面積へ拡張できる先買権があったが、実際に拡張する時点では施設の冷却容量がもう残っておらず、何の意味もなかった。
こういう過程を経験すると、0xide ソリューションがずっとよく理解できるはずだ。
こうしてこそ 支配的な会社を作れる。ハイパースケーラーに閉じ込められることを当然視する泣き言めいた通念を無視したのは良い判断だ。
インフラ企業なら、販売するベアメタルを自社で所有すべきだ。そうでなければ単なるクラウド仲介業者にすぎず、送信コスト 0ドルのベアメタル競合にいつでも価格で押し負ける危険がある。
コロケーションとピアリングで送信コストを 0ドルにできるからこそ Cloudflare は無料プランを提供でき、新規参入者がクラウドサービスを再販売するだけでは Cloudflare と競争できない。
実のところ、ハイパースケーラーにとって帯域幅のぼったくりは単なる収益源ではなく、堀だ。AWS の上で次の AWS を作れないようにし、IaaS の上に「PaaS」という、まったく新しく戦略的により弱い市場区分を作り出している。
これでそのコストを半分に減らし、ストレージコストも下げ、「1席あたり」の価格設定もなくせる。
本当に楽しみだ。
かなりよい記事。ひとつ思い浮かぶのは、ラック管理用の社内ツールをなぜ自作したのかという点。NetBoxがすでにある
NetBoxは優れていて、2000年代半ばに50台以上のラックを管理していた頃にこれがあればよかったと思う
https://github.com/netbox-community/netbox
ただし、私たちが作ったツールであるRailyardがうまく合うのは、私たちのソフトウェア、ハードウェア、オーケストレーションのスタック全体に深く統合されているから
オープンソースのツールの問題は、汎用的すぎることにある。問題を解決するというより、そのツールのデータモデルに合わせて問題のほうを曲げることになる
最終的には、このツールをRailway自体に統合する可能性が高い。オンプレミスに移行したいなら、ボタンをクリックするだけでハードウェア設計、コミッショニング、デプロイ、開発者体験まで提供する、という形。Oxideがやっていることに似ているが、反対側からアプローチしていることになる
https://github.com/netbox-community/netbox/issues?q=is%3Aiss...
NetBoxは「ネットワークインフラの信頼できる唯一の情報源（source of truth）」になろうとしている
何が重要かは状況によって異なるが、NetBoxが「ある項目については別のシステムが真実になり得ない」と主張せず、中央リポジトリを目指していたなら、話は違っていたかもしれない
複雑性と制御を中央集権化しようとする試みは機能しない、ということを私たちは学んだ。Clinger-Cohen Actが成立した直後にもほぼすぐにわかっていたし、今ではITILとTOGAFもこれを明確に扱っている。今後数年間、コンサルタントたちはこの点を大いに狙ってくると思う
状態を見つけるための中央の一貫した方法は必要。権威ある情報をどこで探せばよいのかという疑問をなくすため
だが、拡張し成長したり、新しい変化に適応したりするには、こうした中央集権的な神の箱のような規範的システムは避けるべき
使っていて報われるタイプのソフトウェアではない
よくある「私たちにはXが必要で、YはXをする」という例だが、YがZ、M、Qもやり、皿洗いまでやるという事実と、それらが不要だという点を無視している
ときには、必要なものだけを作るのが最も簡単な解決策になる。特に必要なものがデータベースの前に置くCRUDならなおさら
実際にはスコープを広げるだけ。NetBoxは、そこから始めてシステムをその周囲に合わせる意思があるなら、よい出発点になる
しかし、すでにシステムがある、あるいはNetBoxのロジックに合わないことをする必要があるなら、既存システムを拡張するほうがよい可能性が高い
この場合、Railwayはラック、IPアドレス、物理サーバーを超えて、はるかに多くの追加情報を気にする必要がある
大手テック企業で機器修理の自動化をしていたことがある。修理は過小評価されているが、扱うのがより難しい仕事のひとつだと思う
AWSで動かしているときは、故障したハードウェアをほとんど気にしない。たいていは勝手に修理されるから
自前で運用すると、そうした贅沢はない。予備部品、修理する技術者、ホストから作業を退避して戻す手順、テストスイート、ハードウェア監視ツール、そのほか1001個のものが必要になる
小規模なら一部は適当にやり過ごせるが、結局は痛い目を見る。これはサーバーの話にすぎない
ネットワーク機器にはまた別の面白い問題群があり、失敗すればラック全体を落としかねない。ピーク負荷中にコロケーション事業者が電源を失わないと、どれほど信じられるだろうか。こうした状況に備えて災害復旧訓練をしてほしい
このチームの幸運を祈る。面白そうだ
キャリアの中で経験したいくつかの日々を思い出す。2003〜2010年の間に数万台のサーバーをデプロイしなければならず、データセンターについてかなり興味深いことを学んだ
ケーブル管理と標準化が極めて重要だった。めちゃくちゃな運用では持ちこたえられなかった
毎週数百台のサーバーをデプロイしていた場所では、サーバーが主要クラスタのいずれかと異なる場合に、運用担当者が選べるメニューがあった。基本的にシャーシは2種類で、2Uの大容量ディスクサーバーか、1Uのピザボックスだった。ディスクは9/36/146GB SCSIから選べた
すべて同じプロセッサのデュアルプロセッサ構成で、ラック下部には2Uボックスを10台ほど、残りは1Uボックスを20台以上詰めていた
記憶が正しければ、電力料金はかなりよい条件だった。ケージ内で施設側のラックを使っていたからだったと思う。そのラックを使うと、最初の30A 240V回路2本が無料で提供されていた気がする
10年契約で、計量もなかったので、各ラックをできるだけぎっしり詰め込んだ。片側には30Aを2本、もう片側には20Aを2本入れた
私たちが出していた熱と電力消費を考えると、データセンターはほぼ損益分岐だったと思う。おそらく接続やピアリング費用で埋め合わせていたのかもしれない
細部はよく覚えていないので、当時そこで働いていた友人に確認してみる必要がある
クラウド上にあるのが正しいものもあれば、そうでないものもある。最もよい例は高帯域幅またはディスクを多用するアプリケーション
Netflixを見ると、ほぼすべてがクラウド上にあるが、実際の動画配信は自社ハードウェアで行っている。Netflixの規模でも、これを他社に料金を払ってやっていたら経済的に成り立ったのか疑問
よく見る数字を少し変えてみると、20PBの送信でGBあたり0.02ドルなら月40万ドル
20PBはおおよそ95パーセンタイルで67Gbpsに相当する
100Gbpsの定額回線は月5000ドルでも見つけるのは難しくない
もちろんこれは単純化しすぎた計算で、実際にははるかに多くの要素が入る。それでも差は大きい
ある会社にとっては年468万ドルは大したことではないかもしれないが、別の会社にとっては生存がかかった金額になり得る
もっと詳しい内容があるとうれしい。WTF セクションがいちばんよかった。
機器には「こちらを敵に向けよ」のような表示や、一方向にしか入らないようにする適切なアフォーダンスが必要そうに見える。
ラックレベルでレイアウトを標準化したのか？ ミスを防ぐためにどんなポカヨケ手順を入れたのか？
ベアメタルからブートまでのスタックはどうなっているのか？
異なるクラウドプロバイダー 2 社で働き、PXE ブートホストで社内クラウドを自作した立場からすると、こういう内容は本当に興味深い。
新しいデータセンターを立ち上げるときは、できるだけ活用して、思いつく限りの障害シナリオと、ランダムな障害注入で思いつかなかったシナリオまでテストするとよい。
ラックレベルのレイアウト標準化は今はやっている。2 つ目のサイトの後になってようやく気づいた。そのおかげで検証がずっと簡単になった。
検証は難しく、今のところ手作業でやっている。LLDP データを収集することを試したいが、スイッチのソフトウェアスタックにバグがある。
継続的に進化しているプロセスだ。異なる施工業者と作業するほど、より多くの例外ケースを見つけて反映することになる。
最大の改善は、社内 DCIM を作ってラック設計をテンプレート化し、現場技術者向けにインタラクティブな「ケーブリング・エクスプローラー」を出力するようにしたこと。ポート名などが表示された機器の詳細な注釈付き図も含まれる。記事に出ているラック立面図のスクリーンショットは、そのツールの一部だ。
ベアメタルからブートまでは、https://github.com/danderson/netboot/tree/main/pixiecore の上にハックして作ったものがある。Debian netboot と preseed ファイルを提供する。
BMC の Redfish API に接続してこの装置を操作するカスタム Temporal ワーカーもある。その後、カスタムホストエージェントが QEMU VM をプロビジョニングし、ホスト上で FRR を使って割り当てられた IP を BGP で広告する。
新しいデータセンターの障害シナリオについては、すでにブレーカーを落としてテストしており、そのおかげで相バランスが崩れていることに気づいた。別のサイトでは赤外線カメラを持ち込んだ。
来週 AMS サイトが立ち上がるが、目標は、フル実装したスイッチファブリックをどこまで追い込めるかを見ることだ。
いい記事だ。100G 速度が必要なとき、Google は本当にひどい価格をふっかけてくる。ほとんど侮辱的なほどだ。
たとえば冗長化された 100G Dedicated Interconnect は月額約 3 万 5 千ドルで、これには VLAN attachment、コロケーションのクロスコネクト費用、トランジットなどは含まれない。しかも VLAN attachment は最大 50G だ。
この費用を比べると、同じ金額で Arista の新しい 32 ポート 100G スイッチを 2 台買える。
北米では 100G WAN 回線、つまりマネージド Wavelength を月額 5 千ドル未満で入手できる。ローカルメトロなら、ダークファイバーをもっと安く入手して、好きな速度で動かすこともできる。