Ben Feng: TusDesign プライベートクラウドデータセンター構築の実践 | V教室109号室

第109回[スマート製造+V教室]「優秀なCIO」テーマ共有月間第1回では、Tus-Designグループ株式会社の情報技術センター所長兼シニアエンジニアであるBen Feng氏が、Tus-Designのプライベートクラウドアーキテクチャ設計、プラットフォーム機能、データセンターコンピュータルームの構築など、さまざまな側面から、Tus-Designのプライベートクラウドデータセンターの企業展開の実際の経験と探求について詳しく語りました。

1. ゲストの共有

[[228585]]

Tus-Design Group Co., Ltd. 情報技術センター所長 Ben Feng 氏

1. 個人プロフィール

タスデザイングループ株式会社情報技術センター所長/シニアエンジニア。
彼は30年以上にわたり情報構築の最前線で活躍し、TusParkの情報化の発展を推進し、その発展を目の当たりにし、企業情報化計画、ERP、共同設計、デジタル配信プラットフォームなど、あらゆる情報化プロジェクトの実施を主導してきました。

2. 受賞歴

彼が指揮したプロジェクトは、省の測量設計産業ソフトウェア部門で第2位を獲得しました。
彼が率いたチームは、「第11次5カ年計画」と「第12次5カ年計画」期間中に中国測量設計業情報化先進建設単位の称号を授与され、2017年には江蘇省企業情報化優秀チームに選ばれた。
中国測量設計業第12次5カ年計画期間情報建設先進個人の称号、2016年国家優秀CIOの称号、2017年江蘇省企業優秀CIOの称号を受賞。

2. トピックの共有

《QIDI設計プライベートクラウドデータセンター構築実務》

3. アウトラインを共有する

1. 啓蒙デザインの概要

2. プライベートクラウドアーキテクチャの啓蒙設計

3. プラットフォーム機能

4. 伝統的な建築との比較

5. 最適化する部品

6. データセンターコンピュータ室の建設。

IV.原文

元のテキストのコンテキスト:

本日は皆様とここに集まり、エンタープライズプライベートクラウドの構築に関する経験をシェアできることを大変嬉しく思います。まず、このプラットフォームでコミュニケーションをとり、共に学ぶ機会を与えてくださった江蘇省企業情報化協会に感謝申し上げます。

今年は江蘇省における企業情報化とクラウドコンピューティングの推進年です。江蘇省は、企業向けクラウドコンピューティングのガイドと星評価クラウドコンピューティング企業を評価するための標準を発行したばかりです。トレンドを追いながら、クラウドコンピューティングについて一緒に話し合いましょう。まず初めに、慣例に従い、私たちのTus-Designグループについて簡単に紹介させてください。

Tus-Design Group は 1950 年代に設立され、約 60 年の歴史を誇ります。

2002年、蘇州市人民政府直属の蘇州建築設計研究所が民間企業に転換されました。 2016年2月に深センで株式コード300500で正式に上場しました。注目してください。 2017年3月8日、清華大学のTus-Holdings HoldingsがSuzhou Design（当社の前身）の株式を取得し、正式に社名をTus-Designに変更しました。現在、タスデザイングループ株式会社は全国に約20の支店・子会社を構えております。

これは私たちの写真です

これは、QIDI Design が情報化の過程でたどってきた道のりの縮図です。

QIDIAN Design は、測量・設計業界全体で情報化に投資した最も早い企業の 1 つです。 1990年代から製図板を経てコンピュータ時代に入り、2004年には正式にLAN運用時代に入りました。 2004年、当社は国内で初めて共同設計と情報管理を行う設計会社の一つとなりました。 2006年から2015年は、当社の情報開発にとって飛躍の年でした。このプロセスでは、設計入力→設計出力→統合された共同設計プラットフォームの構築というプロジェクト全体の情報管理に重点を置いています。 2015年、株式改革後の当社グループ運営とリソース統合に適応し、グループの国家配置戦略に準拠するために、プライベートクラウド構築の実験を始めました。プライベートクラウド構築のプロセスを通じて、ERPシステム、統合コラボレーション設計とデジタル配信、デジタルアーカイブの全プロセス情報アプリケーションプラットフォームなど、コア情報システムのクラウド展開を実現しました。

2016年に現在のプライベートクラウドデータセンターを構築しました。この図は、当社のプライベートクラウドアーキテクチャの設計です。

最下層は、ストレージ、ネットワーク、コンピューティングユニットなど、コア物理インフラストラクチャ層と呼ばれるものです。実際、どんなに混乱していても、IT インフラの構築なしにはやっていけないのです。

IT 物理インフラストラクチャの上に、図の中間層となる仮想化環境を構築しました。上位層では、クラウドサービスコンポーネントによる自動配信と自動展開を実現しました。最上位層は EMC ベースの EHC プライベートクラウドポータルです。

図の左側は、クラウド環境全体のデータのセキュリティと整合性を保護するデータバックアップソリューションです。

画像の右側には、ログ管理とインテリジェントな運用および保守コンポーネントがあります。

外部とのコミュニケーションにおいて、一部の同僚が特定のシステムインテグレーターによって仮想化とクラウドを混同しているとよく耳にします。彼らは多くの場合、いくつかの仮想マシンをセットアップし、すでにクラウドベースに移行してプライベートクラウドを展開していると全員に伝えます...

この図を通じて、プライベートクラウドの完全なアーキテクチャがカバーすべき基本要素を誰もが明確に理解できるはずです。仮想化レイヤーに加えて、基盤となるアーキテクチャ、自動展開サービスと配信、データセキュリティ、インテリジェントな運用と保守も、すべて欠かせない要素です。

次の図は、プライベートクラウドプラットフォームの機能モデルです。

プライベートクラウドを構築する最初のステップは、すべてのリソースをプールして統合することであることは周知の事実です。このソリューションには、コンピューティングリソースプール、ストレージリソースプール、ネットワークリソースプールがあります。そして、仮想化された管理と自動オーケストレーションを通じて、サービスとしてのコンピューティング、サービスとしてのストレージ、サービスとしてのバックアップを実現できます。

この図は、当社のプライベートクラウドプラットフォームの論理アーキテクチャ図です。

最下層は x86 サーバーであり、その上には左から右の順にコンピューティング仮想化、ストレージ仮想化、ネットワーク仮想化があります。これら 3 つの仮想化は、3 つの異なるリソースプールを構成します。

画像の右側は、クラウドデータ全体のセキュリティを保証する、当社の包括的かつ完全なクラウドベースのバックアップシステムです。もちろん、このプライベートクラウドプラットフォームは、最終的にはパブリッククラウドとの完全なハイブリッドクラウドアーキテクチャを形成し、パブリッククラウドリソースを追加して共同管理できるようになります。

図の上部には、リソースプールの集中監視、運用、保守管理コンポーネントとプラットフォームポータルがあります。

上の写真に続いて、この写真は前の写真のソフトウェアモジュールを投影した後の結果を示しています。

これには、VMware vCloud テクノロジーと IT インフラストラクチャを組み合わせて、ハードウェアを投影した後に形成されるプライベートクラウドプラットフォームの論理アーキテクチャが含まれます。

この図は、リソース割り当てプロセスのフローを実装するクラウドプラットフォームのテナント分離システムと自動展開コンポーネント + EHC エンタープライズポータルを含む、VMware vCloud に基づいて自動的に配信されるすべてのクラウドコンポーネントを示しています。

これまで、プライベートクラウドプラットフォームの基本的なアーキテクチャ設計と、プラットフォームのいくつかの機能モデルについて説明してきました。プライベートクラウドの論理アーキテクチャについても説明しました。この図は、プライベートクラウドアーキテクチャのコンポーネントを物理レベルで示しています。

下から始めましょう。ストレージについては、EMC に基づいて 2 つのストレージパーティションを作成しました。 1つはファイル保存用のNASです。当時は 5 ノードの Isilon が導入され、合計容量は 400 TB で、主に非構造化ファイルの保存に使用されていました。 2つ目のストレージはSANストレージで、仮想化環境のデータやアプリケーションデータベースなどの構造化データを保存するためのコアストレージとしてEMCハイエンドストレージVmax100Kを導入しました。すべてのストレージは、2 つの 8GB 光ファイバースイッチを介して上位のクラウドコンピューティングノードに接続されています。これら 2 つの 8GB ファイバーは、仮想化の実践で一般的に使用されるストレージ光ファイバースイッチ DS6510 でもあり、すべて 10G モジュールが装備されています。

クラウドコンピューティングノードの初期段階では、4 台の X86 サーバーを構成し、プライベートクラウドデータセンターとして展開しました。さらに、仮想デスクトップサーバークラスターを構築するために、仮想化されたプロフェッショナルグラフィックカードを搭載した 3 台の X86 サーバーを導入しました。 X86 仮想デスクトップサーバークラスターは、3 次元設計された VDI デスクトップ仮想化アプリケーションの解決に重点を置いています。

図の最上層には、2 つの LAN データセンターレイヤー 3 コアスイッチが表示されています。これら 2 つの 10 ギガビットデータセンタースイッチを介して、当社グループ本社全体の LAN に接続されます。現在のネットワークレイアウトは、10G バックボーン + デスクトップ展開への 1G です。

写真の右側は、EMC のバックアップストレージ DATA DOMAIN と、仮想化環境、コアアプリケーションデータベース、大規模な非構造化ファイルのバックアップをバックアップする EMC のバックアップ管理スイート Network+AVMAR 全体をベースにしたバックアップユニットです。

この図は、展開後のクラウド環境全体のトポロジー図です。

先ほど述べた SAN ストレージと NAS ストレージに加えて、最下層の右側にはバックアップストレージもあります。その後、EMC の ViPR コンポーネントを通じてストレージ仮想化が実行されます。中央には仮想化レイヤーがあります。仮想化データセンター全体のコンピューティングユニットには合計 40 台以上のビジネス仮想マシンが展開されており、プライベートクラウドプラットフォームには 20 台以上のコンポーネント仮想マシンが展開されており、合計で 60 台以上の仮想マシンが存在します。

コンピューティングユニットとストレージユニットについて話すとき、クラウド展開プロセス中に見落とされやすいものを強調する必要があります。クラウド環境自体が占有するリソース。実際、この分野での資源消費も比較的大きいです。まず、コンピューティングユニットの観点で言うと、クラウド環境全体で約 20 台の仮想マシンが必要であり、ストレージには 3 ～ 4 TB 近くのストレージが必要であり、これがコアストレージのオーバーヘッドとなります。実際、このオーバーヘッドのコストは非常に高くなります。この時点で、プライベートクラウドデータセンターのコンピューティングユニットを評価および査定する際には、ストレージリソースやコンピューティングリソースなど、対応するクラウド自体に必要なリソースを明確に検討または確保する必要があります。これはとても重要です。

図の仮想化レイヤーは、Citrix に基づいて展開された仮想デスクトップ環境を示しており、VDI 仮想デスクトップに対する当社の R&D アプリケーションのニーズの一部を解決することに重点を置いています。もちろん、このプロセス中に、業界の特性、グラフィックカードの要件、および大量の非構造化データ転送により、仮想デスクトップの使用中にネットワークトラフィックのオーバーヘッドが比較的大きくなることに気付きました。イントラネットでは感じなかったのですが、社外ネットワークに投影すると、基本的に1ユーザーが占有するネットワーク帯域は10～15MB程度で、普段オフィスで使っている仮想デスクトップとは違います。

この導入は 2016 年の初めに完了しましたが、当時使用されていた GPU 仮想化グラフィックカードは NVIDIA の K2 でした。しかし、現在、容量を拡張すると、GPU 仮想化のコストが急激に上昇したため、NVIDIA の新世代 GPU 仮想化グラフィックカードの料金には、グラフィックカードの購入料金に加えて、GPU 仮想化チャネルのライセンス認証のための年間サービス料金が必要になることがわかります。そのため、GPU 仮想化のコスト圧力が大きすぎるように感じます。ここでもこの問題を取り上げたいと思います。他の同僚はより優れた GPU 仮想化ソリューションを持っていますか?後でお互いにコミュニケーションを取り、学ぶこともできます。

図の仮想化レイヤーの右側には、EMC のクラウドポータル EHC、ストレージ仮想化コンポーネント、バックアップスイートを含むクラウドサービスプラットフォームがあります。

次に、アプリケーション全体を複数のパーティションに分割します。そのうちの 1 つがデスクトップ仮想化パーティションです。

写真右側には総合管理区画もあります。総合管理領域では、AD、ログサービス、DHCP などに加え、対応するネットワーク管理ソフトウェア、パフォーマンス監視ソフトウェアも導入しています。また、運用保守管理サービスも総合管理領域に導入しています。

写真の右下には、先ほど説明したデータのバックアップが表示されています。完全なバックアップを形成するために、DD250 バックアップストレージベース + EMC バックアップスイートを使用します。

災害復旧に関しては、既存のデータセンターの 1 つと既存のストレージおよびコンピューティングユニットを活用し、RP4VM を通じてコア仮想マシンを保護しました。もちろん、すべてのアプリケーションサーバーに災害復旧保護を提供することは不可能です。すべてのアプリケーションを合わせると、クラウド環境自体の 20 台の仮想マシンを含め、60 台を超える仮想マシンが必要になります。購入した RP4VM 災害復旧保護ライセンスが不十分なため、保護できるのは 15 の主要なアプリケーション仮想マシン環境のみです。クラウドデータセンターで問題が発生した場合、バックアップデータセンターが災害復旧センターとなります。ここでは、元のコンピューティングリソースとストレージユニットを再利用し、パフォーマンスを低下させながらビジネスの継続性を保護することができます。

ネットワーク層では、コアスイッチに加え、境界ファイアウォール、2つのデータセンターファイアウォール、インターネット動作管理、無線制御を導入しました。

コアスイッチの下にはフロアスイッチがあり、コアスイッチとフロアスイッチ間でも 10G 相互接続を使用します。また、フロアスイッチを 10G 光ファイバーで相互にカスケード接続します。

先ほど、アーキテクチャから設計、トポロジに至るまで、当社のクラウドプラットフォームの構築についてお話ししました。この図は主に、アプリケーション層が実行された後のクラウドプラットフォームの状態を示しています。

なぜクラウドを構築するのでしょうか?クラウド上でどのようなアプリケーションを実行しますか?

当社は、デザイン入力 -> デザイン出力 -> デジタルアーカイブ、つまり完全な共同デザイン制作プラットフォームであるトップ制作プラットフォームに重点を置いています。

ERP の焦点は、財務、人事、契約管理、つまり収益認識を含むプロジェクト管理など、いくつかのアプリケーションにあります。コスト管理、予算編成、調達など。人事部が整備した基本的な人事情報と組織体制により、グループ全体の入退社契約、収益認識、財務管理など財務・業務統合のプロセスを実現します。もちろん、OAのモバイルアプリケーションも実装しており、それらはすべてこのクラウドプラットフォームをベースとしたグループアプリケーションとして完成しています。

このようなクラウドプラットフォームを基盤として、当社の基幹アプリケーションはすべて、当社グループデータセンター（この部分は当社独自のVPNファイアウォールを介してアクセス）を通じて、各地の支店・子会社の業務をサポートすることができます。パブリッククラウドといえば、私たちは実際に金融とビジネスを統合したERPシステムでパブリッククラウドモバイルプラットフォームであるKingdeeの「Cloud Home」を使用しています。重点は、モバイル処理、承認、および一部の IM 機能の解決にあります。

クラウドに移行している従来の企業としての私の経験では、クラウドと元の仮想化環境の間の最大の変化は次のとおりです。

まず、リソースの統合がより緊密になります。
第二に、資源の管理がより厳格になりました。
3 点目は、リソースの監視がより適切に行われるようになったことです。
4 番目のポイントは、データのセキュリティがより保証されることです。

クラウドプラットフォーム管理は、完全なデータバックアップおよび災害復旧ソリューションを構成するためです。

仮想化の構築を始めた当初は、仮想化環境のバックアップについてよく混乱していました。実際、多くのシナリオでは、VMware ESXi が提供するスナップショットおよびバックアップソリューションでは、仮想化環境自体のデータセキュリティの基本的な問題を解決できません。

なぜクラウドに移行する必要があるのでしょうか?クラウドに移行するメリットは何ですか?それと私たちの本来の伝統的な建築との違いは何でしょうか?

この絵を通してそれを皆さんに伝えたいと思います。

まず、クラウドプラットフォームの構築が私たちの設計にインスピレーションを与え、短期間でアジャイルな自動化と標準化されたクラウドサービス提供機能を実現しました。従来の企業向けのクラウドアプリケーションの場合、必ずしも俊敏性と自動化に重点が置かれているわけではありません。実際、標準化されたクラウドサービス提供機能、インテリジェントな運用および保守機能、そして先ほど述べた完全なセキュリティアーキテクチャに、さらに注目する必要があります。

このため、クラウドプラットフォームが提供するリソースライフサイクル全体の自動管理により、従来のアーキテクチャに比べて人的リソースを大幅に節約できると同時に、IT インフラストラクチャの弾力性が真に向上します。また、先ほど繰り返しましたが、リソースの標準化された供給、全体的な運用効率、インテリジェントな運用および保守機能もあります。

2016年から2年近く経ちましたが、プロジェクトを進める中で、私たちは常に新たな試みを続けてきました。私たちはまだデータベース評価ソフトウェアを使用しています。データベースのパフォーマンス評価を実施した後、2 つのコアデータベースを仮想化し、元々データベースサービスを提供していた 4 つのコンピューティングユニット (4U X86PC サーバー) を元のデータセンターに接続して、既存のクラウドデータセンターのコンピューティングユニットとサービス機能を効果的に拡張しました。

もちろん、データセンターの構築時にはリソーステンプレートは比較的単純なものでしたが、コンピューティングユニット全体が提供する機能を確保するために、クラウドリソーステンプレートが継続的に追加されています。さらに、今後の全国展開のニーズにさらに応えていくために、ハイブリッドクラウドのドッキング問題の解決にも注力していきます。もちろん、先ほど述べたように、EHC には固有の利点があります。それ自体が基本的なハイブリッドクラウドアーキテクチャです。対応する構成と拡張を行うことで、ハイブリッドクラウドの管理機能も実現できます。

先ほど私が皆さんと議論し、共有することに焦点を当てたのは、当社のクラウドデータセンターとクラウドアーキテクチャです。物理アーキテクチャの一番下には、プライベートクラウドデータセンターのコンピュータールームがあります。コンピュータ室の構築プロセスにも、多くの具体的な問題が伴います。簡単に列挙してみます。

下の写真は、弊社クラウドデータセンターのコンピュータ室のレイアウト図です。

[[228586]]

左の写真の中央にある穴あきの床がダウンフロー給気ユニットであることがわかります。右上には、当フロアの光ファイバーアクセススイッチと配電ユニットがあります。右下側にあるのが、ここで話題になっている NAS ストレージです。右側は、当社のコアストレージの 1 つである EMC の VMAX です。

[[228587]]

上の写真では、一番左の小さなキャビネットが UPS で、左の写真の右側にある 2 つが精密エアコンであることがわかります。右の写真は弊社の UPS バッテリーパックです。バッテリーパックの上には排気ユニットと自動スプリンクラーの 1 つがあります。

ご存知かどうかは分かりませんが、データセンターの火災は、バッテリーの動作中に生成される微量の水素によって発生する火花によって発生することがよくあります。これは、データセンターのコンピュータ室での火災の 80 ～ 90% を占めています。そのため、データセンター室の構築時には、バッテリーパックをデータセンター室から物理的に隔離し、外部に放出される可能性のある微量の水素を排出するための排気ユニットを追加する必要があります。

データセンター自体の消火システムはガス消火が一般的だとは承知しておりますが、電池についてはそこまでこだわる必要はないかもしれないので、自動スプリンクラーシステムを採用しております。特に大きな IDC ルームの場合、バッテリーパック消火システムもガス消火を使用しますが、ガス消火のコストは自動スプリンクラーよりもはるかに高くなります。もちろん、お金があれば、意固地になってもいいでしょう。

[[228588]]

この写真は、弊社データセンターのコンピューター室にあるガス消火装置を示しています。右側にはガス消火制御ボックスがあります。ガス消火は、実際にはデータセンターのコンピュータ室の建設における必須基準です。これはやらなければなりません。それをしないと大きな問題が起きるでしょう。しかし、この点で注意する必要があるのは、通常のガス火災の消火は一般的に手動で制御されるということです。自動モードに設定されている場合、煙や温度の誤報が発生してガス消火システムが作動すると、データセンターのコンピュータルームにいる人は逃げることができなくなります。

企業のデータセンターのコンピュータ室の建設において、誰もが常に疑問を抱いています。精密エアコンのコストは比較的高い（1台あたり数万元程度）ということです。代わりに、快適なエアコン、つまりキャビネットエアコンを使用できないのはなぜでしょうか?これら2つのエアコンの最大の違いは何ですか?

コンフォートエアコンは温度は制御できますが、湿度は制御できません。冬場は快適なエアコンも難しいです。さらに、温度要件に加えて、コンピューター室には標準的な湿度要件もあります。湿度は50%程度に管理する必要があります。湿度が高すぎたり低すぎたりすると、電気性能の動作に悪影響を及ぼします。

先ほど述べた側面に加えて、コンピューター室の建設にはもう 1 つの重要な問題があります。それは、建設中にコンピューター室をどこに配置すればよいかということです。 1階ですか、それとも2階ですか?通常のオフィスビルでは、床が特別に補強されていない場合、1平方メートルあたりの耐荷重圧力は200kg〜300kgです。キャビネットが 600 mm x 1000 mm、つまり 0.6 平方メートルの場合、キャビネット内には 100 キログラムを超える機器しか積載できません。ご存知のとおり、フルハードディスク構成のサーバーの重量は 65 ～ 70 kg なので、1 つのキャビネットに 3 台のサーバーしか配置できません。

コンピューター室の一部のキャビネットが完全に装備されていないのはなぜだろうとよく思います。先ほど述べた負荷係数に加えて、もう 1 つの要素は各キャビネットの放熱能力です。通常、キャビネットの電力負荷は 8KW を超えることはできません。 8KWを超える場合は、キャビネットの放熱を確実にするために、キャビネットの底部にADU強制空気供給ユニットを追加することができます。

さらに、コンピュータルームの設計時には、等電位計を配置することを忘れないでください。キャビネットの配線とケーブル管理の明確さを確保するには、幅 80 cm のキャビネットを選択することをお勧めします。追加の 20 cm は、両側に垂直ケーブル管理ラックを配置するために使用されます。この種の垂直ケーブル管理は、幅 60 cm のキャビネットの水平ケーブル管理よりも、キャビネット内の配線の明瞭性と整然とした状態を確保できます。

この著者の他の記事を読むにはここをクリックしてください

<<: 仮想化を学んだとしても、まだ分からないことがあります。

>>: Android仮想マシンを検出するための方法とコード実装