S3 DataLineストレージの構築方法。 実験、テスト、カバについて少し

こんにちは、Alexey Pristavkoが連絡を取り合っています。これは、Cloudian HyperStoreに基づくS3オブジェクトストレージDataLineについての私の話の第2部です。



今日は、S3ストレージの配置方法と、その作成プロセスで遭遇した困難について詳しく説明します。 「鉄」のトピックに触れて、私たちが滞在することになった機器を分析してください。



行こう！



読書中にCloudianソリューションのアプリケーションアーキテクチャに精通したい場合は、 前の記事で詳細な分析を見つけることができます。 そこで、Cloudianの内部デバイス、フォールトトレランス、および組み込みSDSのロジックについて詳しく説明しました。

物理機器の最終スキーム

後で「選択の苦痛」について話すので、すぐに私たちが来た鉄の最終リストを提供します。 小さな免責事項：ネットワーク機器の選択は、主に（ちなみに非常に堅実な）倉庫に存在するためです。



したがって、ストレージの物理レベルでは、次の機器があります。

お名前	機能	構成	数量
Lenovo System x3650 M5サーバー	作業ノード	1x Xeon E5-2630v4 2.2GHz、 4x 16GB DDR4、 14x 10TB 7.2K 6Gbps SATA 3.5 "、 2x 480GB SSD、 Intel x520デュアルポート10GbE SFP +、 2x750W HS PSU	4
HP ProLiant DL360 G9サーバー	ロードバランサーノード	2 E5-2620 v3、 128G RAM、 2 600GB SSD、 4 SAS HDD、 Intel x520デュアルポート10GbE SFP +	2
Cisco C4500スイッチ	国境ゲートウェイ	Catalyst WS-C4500X-16SFP +	2
Cisco C3750スイッチ	ポートエクステンダー	C3KX-NM-10Gを搭載したCatalyst WS-C3750X-24T	2
Cisco C2960スイッチ	コントロールプレーン	Catalyst WS-C2960 + 48PST-L	1

アーキテクチャをよりよく理解するために、すべての要素を順番に見て、それらの機能とタスクについて説明します。



サーバーから始めましょう。 Lenovoサーバ​​ーには、Cloudianの推奨事項と仕様に完全に準拠して共同で実装される特別な構成があります。 たとえば、直接ディスクアクセスのあるコントローラーを使用します。 私たちの場合、RAIDはアプリケーションソフトウェアレベルで構成されているため、このモードは信頼性を高め、ディスクサブシステムを高速化します。 Cloudianアプライアンスとしてすべてのライセンスとともにまったく同じサーバーを購入できます。



Nginx for CentOSを搭載した負荷分散サーバーは、作業ノードでの負荷分散を保証し、ユーザーを内部トラフィック組織から抽象化します。 また、楽しいボーナスとして-必要に応じて、キャッシュを整理できます。



Cisco 4500Xの16個の10GB SFP +ペアは、小規模でありながら誇り高いストレージネットワークのコアおよび境界として機能します。 もちろん、鉄は少し時代遅れですが、信頼性の「新しい」に劣らず、内部の冗長性があり、その機能はすべての要件を満たしています。 C3750は工場拡張の役割を果たし、1Gトランシーバーを10Gスロットに押し込む必要はありません。 また、10GBリンクに完全に切り替えることも、まだあまり意味がありません。 テストが示しているように、プロセッサとディスクに以前に遭遇しました。



次の図は、私が説明した物理的な組織を十分に詳細に示しています。



1.物理ストレージ組織のスキーム



スキームを見ていきましょう。 ご覧のとおり、物理レベルでのフォールトトレランスは、各デバイスを複製し、少なくとも2つの光リンク（ペアの各デバイスに1つ）で接続することで実現されます。 これにより、ネットワークデバイスまたは異なるペアの2つのデバイスが同時に故障した場合に、回線の物理的な接続を維持することができます。



スキームの下に行きます。 両方のシスコペア（4500 / 4500、3750 / 3750）は、スタックとVSSを使用して単一の論理デバイスに結合されます。 スタックは、3つの10G光リンクを介して、2本のスタックケーブルVSSで組み立てられます。 これにより、各ペアの両方のデバイスが全体として相互作用することを保証できます。 このテクノロジーは、ペアの両方のデバイスを介して1つのトランスペアレントL2セグメントのフレームワーク内で動作し、LACPを使用して一般的なリンク集約を行うことができます。このテクノロジーはサーバーOSとCisco IOSの両方でネイティブにサポートされているためです。 サーバー側から見ると、2つではなく1つのスイッチで動作しているように見えます。また、アプリケーションの上には、2倍の容量の集約チャネルがあります。



自身と着信チャネルへのすべてのネットワーク機器の切り替えは10G光リンクを使用して行われ、サーバー機器は10G Twinax Ciscoケーブルと1G銅線を使用して接続されます。



BGPは着信チャネルのフォールトトレランスに使用され、ラウンドロビンDNSは外部IPアドレス間のバランシングに使用されます。 外部アドレス自体は負荷分散サーバーにパークされ、必要に応じて、Pacemaker / Corosyncバンドルを使用してノード間を移行します。



IPMIを介した監視と制御は、直接的な内部リンクを介して実行されます。 すべての管理インターフェイス（サーバーとシスコの両方）は、個別のコントロールプレーンスイッチを介して接続されます。 これらは、データセンター管理ネットワークに含まれています。 これにより、作業中または外部ネットワークでの事故の結果として、機器との通信が失われる可能性がなくなります。 最も極端な場合には、KVMのアテンダントがいます。

論理ネットワーク

DataLineストレージのS3論理ネットワークがどのように機能するかを理解するために、別のスキームを見てみましょう。





2.ストレージ論理ネットワーク図



ご覧のとおり、ネットワークロジックは複数のセグメントで構成されています。



合計容量が20Gの外部ネットワーク（Q）は、プロバイダーエッジに直接接続されます。 これには、Cisco 4500とバランサーが続きます。



次の論理ブロック（X）は、バランサーと作業ノード間のVLANです。 バランサーは、着信トラフィックと同じ接続を使用します。 作業ノードは、3750スタックを介して4つの1Gリンク（3750ごとに2つ）で接続されます。 すべての物理リンクは、LACPを使用して単一の論理リンクにアセンブルされます。 このネットワークは、クライアントトラフィックの処理にのみ使用されます。



Cloudian（Y）クラスター内のすべての接続は、10Gの上に構築された3番目の論理セグメントを通過します。 このような組織は、内部トラフィックによる外部チャネルの問題を回避するのに役立ち、逆もまた同様です。 これは、クラスターの操作にとって非常に負荷の大きい重要なセグメントです。 これにより、データとメタデータが複製され、リバランス手順などで使用されます。したがって、「沈めないこと」を別のタスクとして区別しました。

ちょっとした美しさ

これはすべてがどのように見えるかです：





3.フル装備のネットワーク機器とバランサー





4.同じ背面図



切り替えに注意してください。 以前の記事で、同僚はカラーマーキングケーブルの重要性について書きましたが、ここでこのトピックに触れることは場違いではありません。



私たちはネットワークだけでなく、電力にもカラースイッチングを使用しています。 これにより、エンジニアはラック内をすばやく移動し、切り替え中の人的要因の影響を減らすことができます。





5.作業ノード





6.背面図



この写真では、稼働中のサーバーにディスクがどれだけ密に充填されているかを明確に確認できます。実際には、背面にも空のスロットはありません。 ちなみに、このようなケーブルをコンパクトなバンドルにまとめることは、審美的な機能を果たすだけでなく、電源のファンの重複を防ぎ、鉄の過熱を防ぎます。

ホワイトリスト

前回の記事のコメントで、ホワイトリスト登録デバイスについて詳しく説明することを約束しました。



何らかの理由で、データセンターの内部から、または機器への直接チャネルを介してストレージと連携するすべてのアカウントからアカウントを除外することにクライアントと合意した場合、ストレージへのプライベート接続を編成する必要があります。



最初の図では、DISTとクラウドにブランチがあったことを覚えていますか？ メインの20Gbインターネットチャネルに加えて、集約されたチャネルをスイッチに使用して、データセンターレベルですべてのクライアントを接続します。 クライアントがストレージへの直接リンクを必要とする場合、クライアントから4500XへのVLANを別のルートを構築して（またはルートなしで）設定し、L3を開始できます。 その後、料金プランへのバインドは、Cloudian自体に既に存在するクライアントアドレスで構成されます。 その後、この料金プランに関係するすべての人にとって、ホワイトリスト登録アドレスからのS3の使用は考慮されません。





7.そして、これはCloudianの特別なインターフェースです。



現在、このような関税はグリッドにありませんが、本当に必要な場合は提供できます。

建設の歴史

歴史の中で最も興味深い部分、つまり貯蔵施設の建設に徐々に近づいています。 多くの写真がありますが、トラフィックバランシングといくつかの悪いヒントを整理しようとする試みは3回までです。 途中で遭遇したトラブルの分析が、ウェブ上で10Gb +の速度で作業する準備をしている人に役立つことを願っています。

10Gの実験

このセクションの本質に直接進む前に、別の小さな免責事項を作成することを許可します。



確立された伝統によると、新しい補助機器を購入する前に、倉庫に行き、多かれ少なかれ適切なコンポーネントを選択します。 これにより、テストを迅速に実施し、将来の買い物リストを決定できます。 もちろん、100％信頼できる結果を達成することはできませんが、生産性には何も費やされません。



それで、今回でした。 シスコが驚きを投げかけなかった場合、ロードバランサーの「欲」がほとんど台無しになりました。

最初の経験。 Supermicroサーバー

ここで、最小限のコストで迅速なテストを実施したいという希望に失望しました。 倉庫で、SFPインターフェイスがないことを除いて、完全にすべてを備えたSupermicroサーバーを見つけました。 最愛のIntel 520DA2をそれらにインストールすることに決め、すぐに最初の問題に遭遇しました。マシンは単一ユニットですが、ライザーはありません。 同時に、何らかの理由で、私たちの軍団は互換性リストにありませんでしたが、多くのネイティブライザーがありました。



革新的な開発の責任者であるミシャ・ソロヴィヨフの助言を受けて、私たちはすべてを採掘農場の柔軟なライザーに接続しました。 結果はそのような「死体」でした：





8.プロトタイプNo. 1



いくつかの場所で有名な青い電気テープを使用しなければならなかったので、神は禁じられていますが、短いことは何でもします。 はい、集合農場です。 はい、恥ずかしいです。 しかし、このような「構成」は、実験期間中は非常に受け入れられます。





9.背面図



この結果は、iperfのスクリーンショットにはっきりと表示されています。





10.実際には、これはスクリーンショットではありません:)



メトリックは非常に興味深いですよね？ だから私たちは悲しかった。 最初はスパイチップについて考え、すべてを分解して修正しました。





11.一見すると、スパイチップはありません



彼らは物理学のコースを思い出しました：電磁干渉、高周波信号など。もちろん、「集団農場」のそのような量と質で実験を続けることは意味がありませんでした。 そこで、ようやくシステムを分解してサーバーを元の場所に戻しました。

2番目の経験。 Citrix Netscaler MPX8005

サーバーを元の場所に戻す過程で、新しいヒーローであるCitrix Netscaler MPX8005が見つかりました。 これは素晴らしいブランドのアイロンであり、ほとんど使用されていません。 次のようになります。





12.ラック内のスライドは長さが合わなかったが、先見の明があるため、後まで延期することにした。



機器をラックに配置し、切り替えて構成します。 これらは本当に優れた「大人の」鉄片、それぞれ10GB未満の2つのSFPスロット、HA、高度なアルゴリズムであり、L7もあります。 確かに、ライセンスに基づいて最大5ギガビットですが、L3を引き続き使用しましたが、そのような制限はありません。



交差した指、テスト。 速度はありません。 インターフェース上-不適切なトランシーバーに関する確実なエラー、約5ギガビットの速度、絶え間ないドロップ。 彼らは柔軟なライザーを思い出し、再び悲しかった。 そこでも、速度は速く、エラーは少なかった。 私たちは理解し始めます：

show channel LA/1 1)  Interface LA/1 (802.3ad Link Aggregate) #10  flags=0x4100c020 <ENABLED, UP, AGGREGATE, UP, HAMON, HEARTBEAT, 802.1q>  MTU=9000, native vlan=1, MAC=XXX, uptime 0h03m23s  Requested: media NONE, speed AUTO, duplex NONE, fctl NONE,        throughput 160000  Link Redundancy Throughput 80000  Actual: throughput 20000  LLDP Mode: NONE  RX: Pkts(9388) Bytes(557582) Errs(0) Drops(1225) Stalls(0)  TX: Pkts(10514) Bytes(574232) Errs(0) Drops(0) Stalls(0)  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)  bandwidthHigh: 160000 Mbits/sec, bandwidthNormal: 160000 Mbits/sec.  LA mode: AUTO > show interface 10/1 1)  Interface 10/1 (10G Ethernet, unsupported fiber SFP+, 10 Gbit) #1  flags=0x400c020 <ENABLED, UP, BOUND to LA/1, UP, autoneg, 802.1q>  LACP <Active, Long timeout, key 1, priority 32768>  MTU=9000, MAC=XXX, uptime 0h05m44s  Requested: media AUTO, speed AUTO, duplex AUTO, fctl OFF,        throughput 0  Actual: media FIBER, speed 10000, duplex FULL, fctl OFF, throughput 10000  LLDP Mode: TRANSCEIVER,    LR Priority: 1024  RX: Pkts(8921) Bytes(517626) Errs(0) Drops(585) Stalls(0)  TX: Pkts(9884) Bytes(545408) Errs(0) Drops(3) Stalls(0)  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)  Bandwidth thresholds are not set. > show interface 10/2 1)  Interface 10/2 (10G Ethernet, unsupported fiber SFP+, 10 Gbit) #0  flags=0x400c020 <ENABLED, UP, BOUND to LA/1, UP, autoneg, 802.1q>  LACP <Active, Long timeout, key 1, priority 32768>  MTU=9000, MAC=XXX, uptime 0h05m58s  Requested: media AUTO, speed AUTO, duplex AUTO, fctl OFF,        throughput 0  Actual: media FIBER, speed 10000, duplex FULL, fctl OFF, throughput 10000  LLDP Mode: TRANSCEIVER,    LR Priority: 1024  RX: Pkts(8944) Bytes(530975) Errs(0) Drops(911) Stalls(0)  TX: Pkts(10819) Bytes(785347) Errs(0) Drops(3) Stalls(0)  NIC: InDisc(0) OutDisc(0) Fctls(0) Stalls(0) Hangs(0) Muted(0)  Bandwidth thresholds are not set.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

理論的には問題が発生しないはずのネイティブシスコトランシーバーを使用しました。 彼らは光学系をチェックし、念のためトランシーバーを変更しました-同じ写真です。 私たちの車は行きません、それだけです！ もっとよく見ます。



「美しい」Ciscoトランシーバー：

 ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe000-0xe01f mem 0xf7800000-0xf781ffff,0xf7840000-0xf7843fff irq 17 at device 0.1 on pci1 ix1: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8 SFP+/SFP, vendor CISCO-AVAGO , part number XXX , 10G 0x10 1G 0x00 CT 0x00 *** Unsupported SFP+/SFP type!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

トランシーバーは正常に検出されず、サポートされていません！



最も「相対的な」ものを見つけなければなりませんでした。





13.ワイルドウェストで最もネイティブなトランシーバー

 ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe020-0xe03f mem 0xf7820000-0xf783ffff,0xf7844000-0xf7847fff irq 16 at device 0.0 on pci1 platform: Manufacturer Citrix Inc. platform: NSMPX-8000-10G 4*CPU+6*E1K+2*IX+1*E1K+4*CVM 1620 675320 (28), manufactured at 8/10/2015 platform: serial 4NP602H7H0 platform: sysid 675320 - NSMPX-8000-10G 4*CPU+6*E1K+2*IX+1*E1K+4*CVM 1620 ix0: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8 SFP+/SFP, vendor CITRIX           , part number XXX   , 10G 0x10 1G 0x01 CT 0x00 ix0: [ITHREAD] 10/2: Ethernet address: 00:e0:ed:45:39:f8 ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.7.4> port 0xe000-0xe01f mem 0xf7800000-0xf781ffff,0xf7840000-0xf7843fff irq 17 at device 0.1 on pci1 ix1: ixgbe bus speed = 5.0Gbps and PCIe lane width = 8 SFP+/SFP, vendor CITRIX           , part number XXX  , 10G 0x10 1G 0x01 CT 0x00
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのトランシーバーは問題なく決定されましたが、これは状況を救いませんでした。 ファームウェアの更新-同じこと。 Citrixのサポートは、無言のままでいることにしました（いいえ、トランシーバーの系譜のためではありません）。



深呼吸をして、ハードウェアの仕様に埋もれました。 これまでの答えはすべて目の前にあったことが判明しました。ixgbeバス速度= 5.0GbpsおよびPCIeレーン幅=8。これはカードの問題です。 彼女自身はPCIeの速度に欠けています。 当社のCitrixは、 5.0 Gbpsのトランシーバーを搭載したカードのPCI-eスロットの最大のパフォーマンスを備えています。 MPX8015上のCitrixのように（ハードウェアでもまったく同じです！）15ギガビットを提供したかったのですが、明確ではありません。 しかし、なぜこのような「クールな」バランサーが常に倉庫にあるのかを理解しました。 原則として10Gリンクでは正しく機能しません。

最後の経験。 適切なアイロンを使用して美しくします

ここで、私たちの忍耐は人類への信頼で終わり、「スペア」テクノロジーを使用して、上の写真からHP ProLiant DL360 G9の形で通常のハードウェアを取得する必要がありました。 彼らは私たちのために驚きを手配し始めませんでした、彼らは10Gをダウンロードして、文句を言いません。 :)

負荷試験

hujak-hujak-および生産アプローチを受け入れておらず、経験から、ほぼ100％保証されたアセンブリ後のテストされていないシステムが動作不能になることがわかっているため、負荷テストを実施することにしました。 さらに、その助けを借りて、将来のチューニングを行うことができます。



負荷を生成するために、通常のツールであるApache Jmetrが選択されました。 数回前に記事を書いたように、それ自体は非常に優れており、これはJavaが食べるのが大好きですが、市場で最も柔軟なソリューションの1つです。 S3を使用するために、AWS SDKを使用したJavaの自己記述モジュールを使用しました。 テストでは、5メガバイトのチャンクによる並列ロードで250メガバイトを超えるファイル、および5メガバイト未満のファイルの書き込みで12.5 Gbpsの速度を達成することができました-1秒あたり約3000のHTTP要求を処理します。 両方のテストを並行して実行すると、1秒あたり約11ギガビットと2200リクエストが判明しました。 同時に、混合負荷と小さなオブジェクトで作業を改善する可能性があります。 CPUに「埋め込み」、2番目のソケットは無料です。 負荷ジェネレーターでは、ジェネレーター自体のディスクサブシステムの結果への影響を排除するために、RAMからテストファイルが取得されました。 テストでは、RAMに対するJavaの愛情と並列ロード中に多数のスレッドを処理する必要性を思い出して、ジェネレーターとしてHP DL980 g7サーバーを使用しました。 これは、8つのIntel E7-4870プロセッサと512GbのRAMを搭載した8ユニットサーバーです。



チームの内部では、愛情のこもったニックネームのヒッポが彼にこだわった。





14.カバ。 本当ですか、似たようなものですか？





15.背面図。 下部中央の怖いケーブルは、内部バスブリッジの相互接続です。





16.これは、2つのサーバー目標の1つです。 それぞれに4つのプロセッサと16ギガバイトのRAMの16スロットがあります





17.このようなサーバーのコンソールで快適にHtopを使用するには、大きなモニターが必要です:)



実際には、このような強力なサーバーであっても、混合テストが顕著にロードされています。

取得したパフォーマンス結果を得るために、クラスターの内部ネットワークを9kジャンボフレームに転送し、バランサーと作業ノードのネットワークスタックをわずかに調整し（CentOS Linuxを使用）、作業ノード上の他の多くのカーネルパラメーターを最適化する必要がありました：

 cat /etc/sysctl.conf … kernel.printk = 3 4 1 7 read_ahead_kb = 1024 write_expire = 250 read_expire = 250 fifo_batch = 128 front_merges = 0 net.core.wmem_default = 16777216 net.core.wmem_max = 16777216 net.core.rmem_default = 16777216 net.core.rmem_max = 16777216 net.core.somaxconn = 5120 net.core.netdev_max_backlog = 50000 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_max_syn_backlog = 30000 net.ipv4.tcp_max_tw_buckets = 2000000 fs.file-max = 196608 vm.overcommit_memory = 1 vm.overcommit_ratio = 100 vm.max_map_count = 65536 vm.dirty_ratio = 40 vm.dirty_background_ratio = 5 vm.dirty_expire_centisecs = 100 vm.dirty_writeback_centisecs = 100 net.ipv4.tcp_fin_timeout=10 net.ipv4.tcp_congestion_control=htcp net.ipv4.netfilter.ip_conntrack_max=1048576 net.core.rmem_default=65536 net.core.wmem_default=65536 net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.ipv4.ip_local_port_range=1024 65535
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チューニングが行われた主な設定は、バッファーのサイズ、ネットワーク接続の数、ポートへの接続の数、ファイアウォールによって監視される接続、およびタイムアウトです。



Cisco C3750 + LACP =痛み

ネットワークパフォーマンスのもう1つの落とし穴は、LACP / LAGpを使用する場合の負荷分散です。 残念ながら、Cisco 3750は、送信元アドレスと宛先アドレスでのみ、ポート間で負荷を分散できません。 正しいトラフィックバランシングを実現するために、12のIPアドレスを作業ノードのボンドインターフェースに掛けて、クライアントの方を「見て」いました。 条件付きで、物理リンクごとに3つ。 この構成では、すべてのアドレスがNginx構成で指定されているため、作業ノードの「外部」インターフェイスでLACPなしで実行できましたが、リンクが失われた場合、バランシングのノードの重みを自動的に削減します。 「ダンプ」を使用すると、LACPリンクにより、すべてのアドレスへの完全なアクセスを維持できます。

 bond0.10  Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1       RX packets:2390824140 errors:0 dropped:0 overruns:0 frame:0       TX packets:947068357 errors:0 dropped:0 overruns:0 carrier:0       collisions:0 txqueuelen:0       RX bytes:18794424755066 (17.0 TiB)  TX bytes:246433289523 (229.5 GiB) bond0.10:0 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:1 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:2 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:3 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:4 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XX  Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:5 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:6 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:7 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:8 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:9 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX Bcast:192.168.XXMask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1 bond0.10:10 Link encap:Ethernet  HWaddr XXX       inet addr:192.168.XX  Bcast:192.168.XX Mask:255.255.255.0       UP BROADCAST RUNNING MULTICAST  MTU:9000 Metric:1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

機能テスト

リポジトリでの作業が終了すると、サービスflexify.ioに会いました。 これらは、異なるオブジェクトストア間の移行を容易にします。 ただし、Flexifyパートナーになるには、深刻なテストに合格する必要があります。 「どうして？」と思いました。 サードパーティのテストは常にやりがいのある経験です。



テストの主なタスクは、さまざまな構成に関連するプロキシを介してS3プロトコルメソッドの動作を検証することです。その中には、サービスプロバイダーによってサポートされるS3互換バケットのセットがあります。



まず、バケット内のオブジェクトを操作するメソッドがチェックされます。 ストレージは幅広いテストデータを使用してテストされ、メソッドの動作はさまざまなサイズと内容のオブジェクト、Unicode文字のあらゆる種類の組み合わせを含むキーについてチェックされました。



ネガティブテストでは、可能な限り無効なデータを転送しようとしました。 プロセス中のデータの安全性に特に注意が払われました。



バケットを操作するメソッドもテストされていますが、主に肯定的なシナリオでテストされています。 これらのテストのタスクは、プロキシ経由でメソッドを使用しても、データの破損やクラッシュなどの深刻な問題が発生しないことを確認することでした。



カバレッジの幅は、プロキシを介して直接使用されたテストによって判断できます。 ほとんどのテスト、特にオブジェクトを操作するテストはパラメーター化されており、多数の異なるオブジェクト、範囲などをテストします。











ご想像のとおり、これはかなり厳しいテストですが、全体的にはポジティブに合格しました。 当時、SSEおよびUnicodeをサポートしている小さな学校に対するサポートが不足していたため、いくつかの問題が発生しました。



次を含むキーで失敗したapload

• U + 0000-U + 001F-最初の32個の読み取り不能制御文字。 たとえば、Amazonでは、最初のU + 0000のみが直接注がれません。
  
  

• また、U + 18D7C、U + 18DA8、U + 18DB4、U + 18DBA、U + 18DC4、U + 18DCE。 これらも読めない文字ですが、Amazonはそれらをキーとして受け入れます。 他のすべてのキャラクターに問題はありませんでした。
  
  

バケットの内容を読み取るときに、シンボルU + FFFEを含む66,675キーに問題があります。 そのようなキーを持つオブジェクトを含むバケット内のキーの完全なリストを取得することは不可能です。



そうでなければ、テストは成功し、9月末に利用可能なサプライヤーのリストに登場しました！

短いあとがきと読者のためのボーナス

以前、Cloudian HyperStoreは、多くの利点があるにもかかわらず、インターネットのロシア語圏では実質的にカバーされていないことを書きました。



最初の記事は、Cloudianとの連携の基本についてでした。 内部構造、建築上のニュアンスを分解し、公式文書の翻訳を読みました。



今日、私たちは自分のストレージをどのように構築し、どのようなニュアンスと落とし穴に遭遇したかを話しました。



私たちが話している2つの記事を連続してペンで触れたい人は、このページのフィードバックフォームを使用して、個人的に塩とは何かを知ることができます。 標準として、もちろんユーザーアクセスで2週間15Gbを無料で提供します。 リポジトリを操作した感想を共有したい場合は、PMに書いてください。 :)



2週間で15 Gbが足りない人のために、 小さなクエストを用意しています！ 記事の写真では、3つのカバを配置しました。 それらを見つけた最初の50人は、4週間で30Gbを受け取ります。 拡大テストを行うには、カバが隠れた写真の数をコメントに記入し、上記のリンクを使用して申請書を提出してください。 アプリケーションへのコメントへのリンクを含めることを忘れないでください。



伝統的に、まだ質問がある場合は、コメントで質問してください。

喜んでお答えします。