JP2023532947A - データ転送方法、プロキシサーバ、記憶媒体及び電子デバイス - Google Patents

Abstract

本開示の実施例は、データ転送方法、プロキシサーバ、記憶媒体及び電子デバイスを提供する。上記方法は、プロキシサーバがクライアントから送信された目標要求を受信するステップと、目標要求が閲覧要求の場合、プロキシサーバが目標ファイルの目標属性情報を保存された属性情報副本から取得し、クライアントに返信するステップと、目標要求が転送要求の場合、プロキシサーバが目標要求をデータサーバ内の目標サーバに送信するステップであって、データサーバは、２層スタック型のＦＴＰＳｅｒｖｅｒマルチインスタンス分散型クラスタサーバであり、複数の第１サーバを含み、プロキシサーバには各第１サーバから報告されたＦＴＰユーザ処理範囲が記録されているステップと、を含む。

Description

(関連出願の相互参照)
本開示は、２０２０年７月１日に提出された、発明の名称が「データ転送方法、プロキシサーバ、記憶媒体及び電子デバイス」の中国特許出願ＣＮ２０２０１０６２１９３８.０に基づき、この特許出願についての優先権を主張し、参照によりその開示された内容を全て本開示に組み込む。

本開示の実施例は、５Ｇインテリジェントネットワークでのファイル転送技術分野に関し、具体的には、データ転送方法、プロキシサーバ、記憶媒体及び電子デバイスに関する。

ＦＴＰファイル転送をサポートする既存方法には、主に次の種類がある。

高効率シングルインスタンスＦＴＰサーバ、シングルＦＴＰサーバは、ローカルファイルシステム、ＮＩＯなどの方式により、ＦＴＰファイル転送を効率的にサポートする。

ＦＴＰ分散型サーバは、規模に応じて複数のＦＴＰサーバインスタンスをスケーリングし、より大きな規模をサポートすることができる。マルチＦＴＰサーバインスタンス間でのファイル共有方法には、主に以下の３種類がある。

(１)ファイル共有をしない
(２)ファイルコピーによるファイル共有
(３)ＮＦＳ、ＣＥＰＨなどの分散型ファイルシステムによるファイル共有

通常、ＦＴＰリバースプロキシによってネットワーク接続性の問題を解決し、ＦＴＰクライアントと直接接続しないＦＴＰサーバとの間のファイル転送を確保する。

しかし、上記方法において、シングルインスタンスＦＴＰサービスは、１つのＦＴＰサーバインスタンスのみがあるため、サポート能力の上限がシングルインスタンスの処理能力に制限され、大規模な複数接続シナリオを満たすことができず、マルチインスタンスＦＴＰサーバの既存の実装では高い同時接続シナリオにおける効率の問題をうまく解決することができない。

つまり、従来技術におけるデータ転送過程において、ファイル転送効率が低いという問題が存在する。

本開示の実施例は、関連技術においてファイル転送効率が低いという問題を少なくとも解決するデータ転送方法及びプロキシサーバ、記憶媒体並びに電子デバイスを提供する。

本開示の一実施例によれば、プロキシサーバがクライアントから送信された目標要求を受信するステップであって、前記目標要求は、データサーバ内の目標ファイルの目標属性情報の閲覧を要求するために用いられる閲覧要求、又は、目標ファイルを前記データサーバに転送すること又は前記データサーバから取得することを要求するために用いられる転送要求であるステップと、前記目標要求が閲覧要求の場合、前記プロキシサーバが前記目標ファイルの前記目標属性情報を保存された属性情報副本から取得し、前記クライアントに返信するステップであって、前記属性情報副本には、前記目標ファイルの目標ファイル識別子と前記目標属性情報との対応関係が記録されているステップと、前記目標要求が転送要求の場合、前記プロキシサーバが前記目標要求を前記データサーバ内の目標サーバに送信するステップであって、前記データサーバは、２層スタック型のＦＴＰＳｅｒｖｅｒマルチインスタンス分散型クラスタサーバであり、複数の第１サーバを含み、前記プロキシサーバには各前記第１サーバから報告されたＦＴＰユーザ処理範囲が記録されているステップと、を含むデータ転送方法を提供する。

本開示の他の実施例によれば、クライアントから送信された目標要求を受信するように構成される受信ユニットであって、前記目標要求は、データサーバ内の目標ファイルの目標属性情報の閲覧を要求するために用いられる閲覧要求、又は、目標ファイルを前記データサーバに転送すること又は前記データサーバから取得することを要求するために用いられる転送要求である受信ユニットと、前記目標要求が閲覧要求の場合、前記目標ファイルの前記目標属性情報を保存された属性情報副本から取得し、前記クライアントに返信するように構成される第１取得ユニットであって、前記属性情報副本には、前記目標ファイルの目標ファイル識別子と前記目標属性情報との対応関係が記録されている第１取得ユニットと、前記目標要求が転送要求の場合、前記目標要求を前記データサーバ内の目標サーバに送信するように構成される第１送信ユニットであって、前記データサーバは、２層スタック型のＦＴＰＳｅｒｖｅｒマルチインスタンス分散型クラスタサーバであり、複数の第１サーバを含み、前記プロキシサーバには各前記第１サーバから報告されたＦＴＰユーザ処理範囲が記録されている第１送信ユニットと、を含むプロキシサーバを提供する。

本開示の別の実施例によれば、コンピュータプログラムが記憶されているコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは実行される時に上記いずれか１項の方法の実施例におけるステップを実現するように構成されるコンピュータ読み取り可能な記憶媒体をさらに提供する。

本開示の別の実施例によれば、コンピュータプログラムが記憶されているメモリと、前記コンピュータプログラムを実行して上記いずれか１項の方法の実施例におけるステップを実現するように構成されるプロセッサとを含む電子デバイスをさらに提供する。

本開示の実施例に係るデータ転送方法のモバイル端末のハードウェア構成を示すブロック図である。 本開示の実施例に係るデータ転送方法のフローチャートである。 本開示の実施例に係るデータ転送方法のアーキテクチャ及びフローを示す図である。 本開示の実施例に係るデータ転送方法のオフローディング及びアドレッシングのフローチャートである。 本開示の実施例に係るデータ転送方法の分散協調アルゴリズムのフローチャートである。 本開示の実施例に係るデータ転送方法の分散型ＦＴＰクラスタアフィニティ及びＨＡを示す図である。 本開示の実施例に係るプロキシサーバの構成を示すブロック図である。

以下、図面を参照しながら、実施例を踏まえて本開示の実施例を詳しく説明する。

なお、本開示の明細書、特許請求の範囲及び上記図面における用語「第１」、「第２」などは、類似の対象を区別するためのものであり、必ずしも特定の順序又は前後順序を説明するために使用されることはない。

ファイル転送
ファイル転送は汎用技術であり、５Ｇインテリジェントネットワークのシナリオでは、ファイル転送はユビキタスである。例えば、サウスバウンドの帯域外ネットワーク要素では、５Ｇの多数のアクセス特性により、アクセスネットワーク要素の数が大幅に増加し、また、ファイル転送はネットワーク要素の性能管理、バージョン管理における一般的な技術であり、アクセスネットワーク要素の物理ネットワークからセキュリティを保障できるため、簡単で効率的なファイル転送プロトコルＦＴＰサーバがファイル転送の適切な選択となり、多数にアクセスされたネットワーク要素により、大量のＦＴＰ同時接続要求が発生する。そして、５Ｇの低遅延インテリジェントネットワークでは、ＦＴＰが多数の接続をサポートしながら、ファイル転送の高効率化を実現することがさらに求められる。

分散型クラスタ
分散型とは、複数のシステムが協力して１つの特定のタスクを完了することを指す。分散型は、集中管理の問題を解決するためのものとして、全てのタスクを１つのノードに重ねて処理するには遅すぎるため、１つの大きな問題を複数の小さな問題に分割し、個別に解決し、最終的に互いに協力する。分散型の主な作業は、タスクの分解と機能の分割である。クラスタの主な適用シナリオは、要求の負荷を分散するためであり、いくつかのサーバに同じアプリケーションを配置することで、クライアント要求を分散することである。

ＦＴＰリバースプロキシ
ネットワーク環境の制約から、イントラネット(エクストラネットに直接接続されない)から外部のＦＴＰにファイルをアップロード、ダウンロードする必要があり、ゲートウェイサーバにＦＴＰリバースプロキシを設置するしかなく、これにより、ゲートウェイサーバは同時にエクストラネットとイントラネットに接続でき、イントラネットのＦＴＰユーザはＦＴＰプロキシに接続し、それにより外部のリアルＦＴＰサーバにアクセスする。

本開示の実施例で提供される方法の実施例は、モバイル端末、コンピュータ端末、又は同様のコンピューティングデバイスで実行され得る。モバイル端末での実行を例とし、図１は本開示の実施例に係るデータ転送方法のモバイル端末のハードウェア構成を示すブロック図である。図１に示すように、モバイル端末は１つ又は複数(図１では１つのみが示されている)のプロセッサ１０２(プロセッサ１０２はマイクロプロセッサＭＣＵ又はプログラマブルロジックデバイスＦＰＧＡなどの処理装置を含み得るがこれらに限定されない)と、データを記憶するように構成されるメモリ１０４とを含んでもよい。

ここで、上記モバイル端末は、通信機能として設定される伝送装置１０６及び入出力装置１０８をさらに含んでもよい。当業者であれば、図１に示す構造は例示的なものに過ぎず、上記モバイル端末の構造を限定するものではないことを理解できる。例えば、モバイル端末は、図１に示されたものより多い又は少ない構成要素をさらに含んでもよく、又は図１に示されたものと異なる構成を有してもよい。

メモリ１０４は、コンピュータプログラム、例えば、本開示の実施例に係るデータ転送方法に対応するコンピュータプログラムといったアプリケーションソフトウェアのソフトウェアプログラム及びモジュールを記憶するように構成されてもよく、プロセッサ１０２は、メモリ１０４内に記憶されたコンピュータプログラムを実行することで、様々な機能活用及びデータ処理を実行し、即ち、上記のデータ転送方法を実現する。メモリ１０４は高速ランダムメモリを含んでもよく、さらに１つ又は複数の磁気記憶装置、フラッシュメモリ、又は他の不揮発性ソリッドステートメモリなどの不揮発性メモリを含んでもよい。

いくつかの実例では、メモリ１０４はさらにプロセッサ１０２に対して遠隔設定されるメモリを含んでもよく、これらの遠隔メモリはネットワークを介してモバイル端末に接続することができる。上記ネットワークの実例としては、インターネット、イントラネット、ローカルエリアネットワーク、移動体通信ネットワーク及びそれらの組み合わせを含むが、これらに限定されない。

伝送装置１０６はネットワークを介してデータを受送信するように構成される。上記ネットワークの具体的な実例としては、モバイル端末の通信事業者から提供される無線ネットワークを含んでもよい。一実例では、伝送装置１０６は、ネットワークインターフェースコントローラ(Network Interface Controller、ＮＩＣと略称する)を含み、インターネットと通信できるように、基地局を介して他のネットワークデバイスに接続することができる。一実例では、伝送装置１０６は、無線周波数(Radio Frequency、ＲＦと略称する)モジュールであってもよく、無線方式によってインターネットと通信するように構成される。

本実施例ではデータ転送方法を提供し、図２は本開示の実施例に係るデータ転送方法のフローチャートである、図２に示すように、このフローは以下のステップＳ２０２、Ｓ２０４、Ｓ２０６を含む。

ステップＳ２０２では、プロキシサーバがクライアントから送信された目標要求を受信する。ここで、前記目標要求は、データサーバ内の目標ファイルの目標属性情報の閲覧を要求するために用いられる閲覧要求、又は、目標ファイルを前記データサーバに転送すること又は前記データサーバから取得することを要求するために用いられる転送要求である。

ステップＳ２０４では、前記目標要求が閲覧要求の場合、前記プロキシサーバが保存された属性情報副本から前記目標ファイルの前記目標属性情報を取得し、前記クライアントに返信する。ここで、前記属性情報副本には、前記目標ファイルの目標ファイル識別子と前記目標属性情報との対応関係が記憶されている。

ステップＳ２０６では、前記目標要求が転送要求の場合、前記プロキシサーバが前記目標要求を前記データサーバ内の目標サーバに送信する。前記データサーバは、２層スタック型のＦＴＰＳｅｒｖｅｒマルチインスタンス分散型クラスタサーバであり、複数の第１サーバを含み、前記プロキシサーバには各前記第１サーバから報告されたＦＴＰユーザ処理範囲が記録されている。

ここで、前記方法は、前記プロキシサーバが前記クライアントから送信された前記目標要求を受信するステップの前に、前記データサーバ内の全てのファイルのファイル識別子と全てのファイルの属性情報を取得するステップと、前記データサーバ内の全てのファイルのファイル識別子と全てのファイルの属性情報を前記属性情報副本に保存するステップと、をさらに含む。

ここで、前記方法は、前記プロキシサーバが前記クライアントから送信された前記目標要求を受信するステップの前に、ユーザ識別子と前記第１サーバとの対応関係を取得するステップであって、異なる前記ユーザ識別子は異なる前記第１サーバに対応付けられるステップと、前記対応関係を内部メモリに保存するステップと、をさらに含む。

ここで、前記目標要求が閲覧要求の場合、前記目標ファイルの前記目標属性情報を前記プロキシサーバに保存された属性情報副本から取得し、前記クライアントに返信する前記ステップは、前記目標要求内の前記目標ファイルの前記目標ファイル識別子を取得するステップと、前記目標ファイル識別子に対応する前記目標属性情報を前記属性情報副本から取得するステップと、前記目標属性情報を前記クライアントに返信するステップと、を含む。

ここで、前記方法は、前記目標要求が転送要求の場合、前記目標要求を前記データサーバ内の前記目標サーバに送信するステップの前に、前記クライアントの目標ユーザ識別子を取得するステップと、内部メモリ内の、前記目標ユーザ識別子に対応する前記目標サーバを検索するステップと、をさらに含む。

ここで、内部メモリ内の、前記目標ユーザ識別子に対応する前記目標サーバを検索する前記ステップは、前記目標ユーザ識別子に対応する複数のサーバを検索した場合、前記複数のサーバから負荷バランスの最も低いサーバを前記目標サーバとして選択するか、又はポーリングアルゴリズムを利用して前記複数のサーバから前記目標サーバを決定するステップと、を含む。

ここで、前記方法は、前記目標要求が転送要求の場合、前記目標要求を前記データサーバ内の前記目標サーバに送信するステップの後に、前記クライアントと前記目標サーバとの間にデータ転送チャネルを確立するステップと、前記データ転送チャネルを介して、前記クライアントと前記目標サーバとの間で前記目標ファイルを転送するステップと、をさらに含む。

ここで、前記方法は、前記プロキシサーバがクライアントから送信された目標要求を受信するステップの前に、前記属性情報副本のファイルサイズが所定閾値未満である場合、前記属性情報副本を内部メモリに保存するステップと、前記属性情報副本のファイルサイズが所定閾値以上である場合、前記属性情報副本をメモリに保存するステップと、をさらに含む。

ここで、前記方法は、前記目標要求が転送要求の場合、前記プロキシサーバが前記目標要求を前記データサーバ内の前記目標サーバに送信するステップの前に、同一の前記第１サーバに位置する複数のＦＴＰＳｅｒｖｅｒインスタンスを利用して１層スタック構造を形成するステップと、複数の前記第１サーバを利用して２層スタック構造を形成し、前記データサーバを得るステップと、をさらに含む。

ここで、前記方法は、複数の前記第１サーバを利用して２層スタック構造を形成し、前記データサーバを得るステップの後に、同一の前記第１サーバにおける複数の前記ＦＴＰＳｅｒｖｅｒインスタンスを同じディスクアレイＬＵＮ高速ストレージにマウントするステップをさらに含む。

本開示の実施例によれば、ファイル転送過程において、プロキシサーバを介してファイルのスケジューリングを行うことができ、閲覧要求はプロキシサーバを介して目標属性情報を直接返信することができ、転送要求は異なる目標サーバに送信して処理することができるため、ファイル転送効率が低いという問題を解決し、ファイル転送効率の向上効果を達成することができる。

以下、具体的な例示と組み合わせて本開示を説明する。

本開示の実施例におけるプロキシサーバはｆｔｐリバースプロキシサーバであってもよい。第１サーバはサーバノードであってもよく、サーバノードでＦＴＰＳＥＲＶＥＲインスタンス(ＦＴＰＳｅｒｖｅｒマイクロサービス)が実行される。複数の第１サーバで２層スタック構造を形成し、データサーバを構成する。

ＦＴＰリバースプロキシＦＴＰＰｒｏｘｙオフローディング・アドレッシング
ＦＴＰＰｒｏｘｙリバースプロキシは、ＦＴＰプロトコルのメタ言語レイヤーを実現するものとして、クライアントにとって標準のＦＴＰサーバであるが、多くの実際のファイル操作要求はそれによってバックエンドＦＴＰＳｅｒｖｅｒマイクロサービスクラスタに伝達されて処理される。本開示の実施例におけるＦＴＰＰｒｏｘｙリバースプロキシは、ローカルオフローディングとＦＴＰＳｅｒｖｅｒ２層スタックのアドレッシングと連動した設計に重点を置く。

まず、リバースプロキシについて説明する。リバースプロキシは、バックエンドの複数のＦＴＰＳｅｒｖｅｒ分散型インスタンスによる差異からクライアントを保護し、かつオフローディング・アドレッシングと連動するためのものとして、ＦＴＰクライアントはＦＴＰＳｅｒｖｅｒインスタンスがいくつあるか、それぞれどのサーバノードで実行されるか、それぞれのインスタンスのアドレスが何か、あるインスタンスが停止しているかといった細かいことに注意を払う必要がない。

ＦＴＰクライアントは、ＦＴＰＳｅｒｖｅｒマイクロサービスを直接要求するのではなく、ＦＴＰＰｒｏｘｙに接続し、それがＦＴＰＳｅｒｖｅｒのプロキシとしてＦＴＰプロトコル機能を提供する。ＦＴＰＰｒｏｘｙは、監視コンソールを提供し、ＦＴＰＰｒｏｘｙ自体のステータス、現在の全てのＦＴＰ接続情報、バックエンドの全てのＳｅｒｖｅｒＮｏｄｅ及びＦＴＰＳｅｒｖｅｒインスタンスの情報及びステータスを閲覧することができる。

ｆｔｐリバースプロキシはＦＴＰ要求を分析することで、ＦＴＰ要求を２種類に分けることができる。

閲覧要求:ＬＩＳＴ、ＮＬＳＴ、ＰＷＤ、ＳＴＡＴなどのファイル閲覧類要求である。この種類の要求は、主にファイルシステムレベルでのファイル情報を閲覧することである。

転送要求:ＲＥＴＲ、ＳＴＯＲ、ＤＥＬＥ、ＣＷＤ、ＲＮＴＯなどのファイル操作及びファイル転送類要求のような、閲覧類要求以外のその他の要求である。ファイル転送類要求と総称する。

ＦＴＰＳｅｒｖｅｒの負荷を軽減し、ファイル閲覧類要求の応答効率を向上させるために、リバースプロキシサーバＦＴＰＰｒｏｘｙでオフローディング能力を提供することができる。

ＦＴＰＰｒｏｘｙは、クライアントの要求を受信した後に、要求タイプを判断し、ファイル閲覧類要求の場合、バックエンドのＦＴＰＳｅｒｖｅｒに伝達することなく、ローカルで直接処理する。ファイル閲覧類要求のＦＴＰＰｒｏｘｙでの処理をサポートするためには、ＦＴＰＰｒｏｘｙでバックエンドのＦＴＰＳｅｒｖｅｒファイルディレクトリツリーと属性情報副本を保持する必要がある。バックエンドの各ＦＴＰＳｅｒｖｅｒの位置するシングルサーバノードは、ローカルファイルシステムを共有するため、同一のサーバノードにとって、このファイルツリー情報をＦＴＰＰｒｏｘｙでマージする必要がない。

各サーバノードのローカルファイルシステムは共有されず、各自独立しているため、ＦＴＰＰｒｏｘｙは全てのＦＴＰＳｅｒｖｅｒの位置するサーバノードに対してサーバノード単位でディレクトリツリーを保持しなければならない。後続のＦＴＰの動作に伴い、ＦＴＰＳｅｒｖｅｒのファイルシステムの内容が変化し、ＦＴＰＰｒｏｘｙのローカルキャッシュを同期更新する必要があり、全てのＦＴＰ要求はＦＴＰＰｒｏｘｙリバースプロキシを通して行われるため、これらの変化はＦＴＰＰｒｏｘｙによって保持されるディレクトリツリーで同時に行い、バックエンドのＦＴＰＳｅｒｖｅｒファイルシステムの内容との一貫性を保つことができる。

効率を向上させるために、ＦＴＰＰｒｏｘｙで保持されるディレクトリツリー情報は内部メモリに保存されてもよく、バックエンドのＦＴＰＳｅｒｖｅｒで保有されるファイルが多すぎる場合、この部分の情報をストレージに永続化し、内部メモリの負荷を軽減することができる。

ファイル転送類要求について、プロキシに到達すると、後続はクライアントとＦＴＰＳｅｒｖｅｒインスタンスが直接ファイル転送チャネルを確立し、プロキシによるファイル転送をせず、直接接続して直接転送し、ＦＴＰＰｒｏｘｙによる一回の転送を減らし、ＦＴＰＰｒｏｘｙがボトルネックになることを防止し、効率をさらに向上させる。

ＦＴＰＰｒｏｘｙは、ＦＴＰ要求をバックエンドの複数のＦＴＰＳｅｒｖｅｒマイクロサービスインスタンスに配信する。ＦＴＰＳｅｒｖｅｒ２層スタックに応じて設計され、各ＦＴＰＳｅｒｖｅｒインスタンスでサポート可能なＦＴＰユーザは一定の範囲のものであるため、ＦＴＰＰｒｏｘｙは、現在接続してログインしたＦＴＰユーザに応じてバックエンドのどのＦＴＰＳｅｒｖｅｒインスタンスにアドレッシングするかを決定し、勿論、このようなインスタンスは複数存在する可能性があり、この場合、さらにＦＴＰＳｅｒｖｅｒの負荷状況に応じて要求をバランス良く割り当て、効率の最大化を達成してもよく、Ｒｏｕｎｄ－Ｒｏｂｉｎポーリングアルゴリズムを用いてもよく、簡単かつ効率的である。

５Ｇインテリジェントネットワークとクラウドネットワークが融合していく潮流の中で、運用保守管理、ネットワーク管理などのほとんどはマイクロサービスアーキテクチャを用いており、マルチインスタンススケーリングは、分散型、高い同時実行性・大規模、及びデュアルクラスタシステムＨＡをより良くサポートするために、クラウドネイティブの各サービスコンポーネントに対する基本要件になっている。従って、本方案のＦＴＰＳｅｒｖｅｒはファイル転送サービスコンポーネントとして、マイクロサービスコンテナの方式を用いて実現し、マルチインスタンスの実行をサポートする。

また、ファイル転送効率を向上させるために、同じサーバノードＦＴＰＳｅｒｖｅｒインスタンスは、ローカルの高速ストレージ論理ユニット番号(ＬＵＮ)を共有し、マルチサーバノードをスタックしてＦＴＰ分散型クラスタシステムの全体を形成し、高い同時実行性で効率的なファイル転送要求を達成する。

シングルインスタンスＦＴＰＳｅｒｖｅｒがサポート可能なＦＴＰ同時接続数は限られており、その容量はリソースの垂直スケーリングに伴って上限なしに上がることができず、シングルインスタンス内部のスレッドスケジューリング、ロック待ちなどにより処理能力に上限があり、一般的には同時接続数が１０００程度で上限に達し、スケーリングリソースをそれ以上割り当てても改善することができない。従って、より多くの同時接続をサポートするためには、ＦＴＰサーバクラスタを実現しなければならない。

本開示の実施例は、ＦＴＰＳｅｒｖｅｒがコンテナの方式で実行し、クラウドネイティブの要件を満たし、マルチインスタンススケーリングをサポートし、弾性スケーリングをサポートするように設計され、接続数、接続アクティビティ、ＣＰＵや内部メモリの使用状況などの構成、負荷に基づいて複数のインスタンスをポップアップ表示して実行することができる。１つのサーバノードで複数のＦＴＰＳｅｒｖｅｒインスタンスを実行することができ、複数のサーバノードを配置することができる。このように複数のＦＴＰＳｅｒｖｅｒインスタンスで１つのＦＴＰ分散型クラスタを構成し、Ｋ８ｓといったコンテナ管理システムでそのライフサイクルを管理し、弾性スケーリング的なスケジューリングやＨＡを実現する。

ここで、同じサーバノードＦＴＰＳｅｒｖｅｒインスタンスは、ローカルストレージにマウントされたディスクアレイＬＵＮを共有する。

ＦＴＰサーバクラスタにおいて解決すべき最大の問題は、ファイルシステムの一貫性である。ファイルアップロード・ダウンロード、ファイル操作業務の正しさを確保できるように、複数のＦＴＰＳｅｒｖｅｒインスタンスに完全に一貫したファイルビューを見せる必要がある。この一貫性を保証するために、ファイルコピー方式でも分散型ファイルシステム方式でも、効率問題は最も際立った問題であり、クラスタ内部で増加したＩＯや競合により、ファイル転送効率を大きく低下させる。本開示の実施例は、この問題を解決する。

ファイルシステムの一貫性を解決するために、同じサーバのＦＴＰＳｅｒｖｅｒインスタンスがローカルストレージにマウントされたディスクアレイＬＵＮを共有し、分散協調メカニズムでファイルアクセス競合を解決するように設計され、このようにすると、同じサーバのＦＴＰＳｅｒｖｅｒインスタンスから見えるのは統一したファイルシステムビューである。

この方法は、ディスクアレイＬＵＮの効率的なＩＯを利用して効率的なファイル転送をサポートする。勿論、これは対応するＦＴＰＳｅｒｖｅｒインスタンスが同じサーバノードで実行し、サーバノードのリソースの高構成でＦＴＰＳｅｒｖｅｒマルチインスタンスをサポートする必要がある。例えば、シングルＦＴＰＳｅｒｖｅｒインスタンスの容量上限時のリソース要件は１Ｃ２Ｇ(１コアＣＰＵ、２Ｇ内部メモリ)で、現在の高構成サーバは基本的に１００Ｃ３００Ｇ構成に達することができ、つまり、同じサーバノードは１００のＦＴＰＳｅｒｖｅｒインスタンスの水平スケーリングをサポートし、１０万ＦＴＰの同時接続をサポートする容量に達することができる。

シングルサーバノードで実行されるＦＴＰＳｅｒｖｅｒマルチインスタンスは１つのＦＴＰサーバクラスタを構成するが、サーバノードの構成によって制限され、このクラスタの処理能力にも上限があり、分散型ＦＴＰサーバクラスタのサポート規模をある程度制限する。従って、シングルサーバノードの制限を破り、複数のサーバノードを利用する必要がある。しかし、ローカルストレージのディスクアレイＬＵＮは複数のサーバノードに跨って効率的にアクセスすることができず、そうでないと、ＮＦＳのような分散型ファイルシステムを構築しなければならず、効率問題が出てしまう。

ＦＴＰの業務特徴を踏まえて、ある具体的なＦＴＰユーザのホームワーキングディレクトリは決定されており、異なるホームワーキングディレクトリでのファイルはクロスオーバーせず、つまり、ファイルに対するＦＴＰの操作は常にこのユーザのホームワーキングディレクトリに制限されるため、あるＦＴＰユーザのホームワーキングディレクトリをある固定したサーバノードにバインドし、別のＦＴＰユーザの異なるホームワーキングディレクトリをその他のサーバノードにバインドすることができる。

このように、異なるサーバノードは異なるホームワーキングディレクトリを処理し、これにより複数のサーバノード間でファイル共有ビューを必要としない。異なるＦＴＰユーザは同じワーキングディレクトリを指すことができるため、ここでの分割根拠はＦＴＰユーザではなく、ＦＴＰユーザのホームワーキングディレクトリである。最終的な効果としては、ある具体的なワーキングディレクトリが特定のサーバノードにのみ存在する。

あるサーバノードにどのワーキングディレクトリが含まれるかという各ＦＴＰユーザのホームワーキングディレクトリとサーバノードとの対応関係を事前に分割することで、対応するＦＴＰユーザのファイル転送要求を処理し、最終的にサーバノードとＦＴＰユーザとの関係を形成することができる。あるＦＴＰユーザの全ての要求は１つの固定したサーバノード(のマルチＦＴＰＳｅｒｖｅｒインスタンス)で処理されるため、ローカルストレージにマウントされたディスクアレイＬＵＮを引き続き利用することができ、また、このサーバノードで実行される複数のＦＴＰＳｅｒｖｅｒインスタンスを利用してこのユーザのためにクラスタリング機能をサポートすることができる。

このように、ＦＴＰＳｅｒｖｅｒは複数のタイプに分けられ、あるタイプのＦＴＰＳｅｒｖｅｒ(複数のインスタンス)で処理されるＦＴＰユーザディレクトリは決定され、かつその他のタイプのＦＴＰＳｅｒｖｅｒとクロスオーバーせず、固定したサーバノードで実行される。

これまでのリソース推定によると、シングルサーバノードで実行されるシングルユーザは１０万の同時接続という桁数の容量に達することができ、また、異なる業務では通常、異なるＦＴＰユーザを使用するため、本方案におけるマルチサーバノードスケーリングと組み合わせて、システム全体でより高い桁の同時サポート能力を提供することができる。

本開示の実施例において、異なるサーバノードのＦＴＰＳｅｒｖｅｒによって処理可能なＦＴＰユーザ範囲は異なり、ある具体的なＦＴＰＳｅｒｖｅｒインスタンスは特定のサーバノードでのみ実行し、かつそのノードで弾性スケーリングすることができる。そのためには、コンテナ管理システムＫ８ｓのラベル付けメカニズムを利用する必要があり、それはラベル付けによってＦＴＰＳｅｒｖｅｒインスタンスが実行されるサーバノードをスケジューリングすることができる。

各サーバノードにラベルを付けるとともに、あるタイプのＦＴＰＳｅｒｖｅｒのラベルを構成することにより、そのインスタンスが対応するラベルのサーバノードで実行されるように制御する。異なるワーキングディレクトリ範囲のその他のタイプのＦＴＰＳｅｒｖｅｒにその他のラベルを構成し、そのインスタンスが対応するラベルのその他のサーバノードで実行されるように制御する。

本開示の実施例で言及される方案によれば、ローカルストレージのディスクアレイＬＵＮを利用するために、あるタイプのＦＴＰＳｅｒｖｅｒインスタンスを実行可能なラベルに対応するサーバノードは１つのみでなければならない。しかし、そのサーバノードが失効すると、ＨＡが保証できなくなるため、あるラベルに対応するサーバノード数は１より大きいものでなければならない。

しかし、同じタイプのＦＴＰＳｅｒｖｅｒインスタンスは全て同じサーバノードのみにスケジューリングすることを確保するためには、コンテナ管理システムＫ８ｓのアフィニティポリシーを利用する必要があり、アフィニティとは、あるタイプのＦＴＰＳｅｒｖｅｒの１番目のインスタンスがラベル付けルールに従ってあるサーバノードにスケジューリングされた場合、同じラベルの複数のサーバノードが存在しても、後続のそのタイプのＦＴＰＳｅｒｖｅｒのその他のインスタンスも同じサーバノードにスケジューリングされる。

このようにすると、同じタイプのＦＴＰＳｅｒｖｅｒインスタンスが全て同一のサーバノードで実行されることを確保し、ローカルストレージのディスクアレイＬＵＮを共有するとともに、ＨＡを保証することができ、あるサーバノードがオフラインした場合、このサーバノードの全てのＦＴＰＳｅｒｖｅｒインスタンスは全体的にラベル付けルールに合致するその他のあるサーバノードに切り替えられ、ディスクアレイＬＵＮも新しいサーバノードにマウントされる。

同一のサーバノード上のＦＴＰＳｅｒｖｅｒインスタンスは全て同一のディスクアレイＬＵＮを読み書くため、これらのＦＴＰＳｅｒｖｅｒインスタンスのＩＯ操作が互いに競合しないように協調する分散協調メカニズムが必要となる。主に同一のファイルに対する読み書きが競合せず、それとともに、同一のファイルに対して書き込み操作を行うＦＴＰＳｅｒｖｅｒインスタンスは１つのみでなければならず、書き込む際に読み込むことができず、他の制限がない。同一のＦＴＰＳｅｒｖｅｒインスタンス内部のマルチスレッドは、分散協調することなく、内部メモリロックで制御される。

コンテナ間の分散ロックによって、ファイルを書き込む時に、ファイル名に基づいて対応するロックを生成し、書き込んだ後に解放し、その他の読み書き動作の際にもこのロックが存在するか否かを確認し、存在する場合、このファイルに対する他の読み書き動作は許可されないような分散協調メカニズムを実現する。

本分散協調は、一時ファイル及びファイルソートに基づいて実現される分散ロックであり、このロックは再進入不可能である。ロックの申請時に、ロックごとに１つの一時ディレクトリを生成し、読み書きを協調すべき具体的なファイルに対応付け、ロックを申請すべき各ＦＴＰＳｅｒｖｅｒインスタンスはこのディレクトリ下で自身のコンテナＩＤに基づいて一時ファイルを生成してロックし、ロック前後にも判定を行い、複数のコンテナが同時に申請する状況がある(つまり、複数の一時ファイルがある)場合、ファイル名ソートの固定アルゴリズムに基づいてロックに成功したコンテナを選択する。最終的に１つのコンテナのみがこのロックを取得するという目的を達成し、分散協調を実現する。

本開示の実施例に係る方法を用いると、従来技術に比べ、ファイル閲覧類の操作に対する応答がより速く、多数のＦＴＰ同時接続をサポートすることができ、また、多数のＦＴＰ接続の場合、ファイルコピー又はネットワークファイルシステムがないため、ＦＴＰサーバクラスタ内部のＩＯを効果的に低下させ、ファイル転送効率を向上させる。

ＦＴＰＰｒｏｘｙリバースプロキシを介してバックエンドのマルチＦＴＰＳｅｒｖｅｒインスタンスをオフローディング・アドレッシングし、ファイル転送類要求はプロキシをスキップして直接接続して直接転送し、ファイル転送効率を向上させる。ＦＴＰ業務特徴を踏まえて、２層スタック型のＦＴＰＳｅｒｖｅｒマルチインスタンス分散型クラスタ(データサーバ)を設計し、アフィニティポリシー及び分散協調を利用して同じタイプのＦＴＰＳｅｒｖｅｒインスタンスがローカルのディスクアレイＬＵＮ高速ストレージを共有可能にし、さらにファイルアップロード・ダウンロード効率を向上させる。

図３に示すように、図３は本開示の方法のアーキテクチャ及びフローを示す図である。ＦＴＰＰｒｏｘｙはゲートウェイに配置され、リバースプロキシとして、バックエンドのＦＴＰＳｅｒｖｅｒインスタンスのアドレッシングと連動することができる。各ＳｅｒｖｅｒＮｏｄｅで最初に生成されたＦＴＰＳｅｒｖｅｒインスタンスは、起動時にローカルＬＵＮ内のワーキングディレクトリツリー情報をＦＴＰＰｒｏｘｙに伝達してキャッシュし、ファイル閲覧類要求に素早く応答できる。

ＦＴＰＰｒｏｘｙに全てのＬＵＮのワーキングディレクトリツリーが保持され、後続のＦＴＰ操作によって動的に更新される。また、ＦＴＰＰｒｏｘｙは監視コンソールを提供し、ＦＴＰ分散型クラスタシステムの様々な情報及びステータスを収集する。それはＦＴＰＰｒｏｘｙ自体のステータス、現在の全てのＦＴＰ接続情報、バックエンドの全てのＳｅｒｖｅｒＮｏｄｅ及びＦＴＰＳｅｒｖｅｒインスタンスの情報及びステータスを閲覧することができる。

クライアントＦＴＰＣｌｉｅｎｔは、まずＦＴＰＰｒｏｘｙに接続してＦＴＰユーザ認証を行い、ＦＴＰＰｒｏｘｙは各ＦＴＰ接続に対応するＦＴＰユーザ情報を記録する。後続のファイル転送類要求が開始されると、このユーザに対応するＦＴＰＳｅｒｖｅｒインスタンスにアドレッシングし、ＦＴＰＣｌｉｅｎｔとＦＴＰＳｅｒｖｅｒがファイル転送チャネルを直接確立し、後続のファイル転送を行う。

ＦＴＰＳｅｒｖｅｒ分散型クラスタを構成する各インスタンスはラベル付けルールに従って対応するＳｅｒｖｅｒＮｏｄｅ(サーバノード)で実行し、このサーバノードには対応するディスクアレイＬＵＮをマウントし、そのワーキングディレクトリ範囲はサービス可能なＦＴＰユーザ範囲を決定する。同一のＳｅｒｖｅｒＮｏｄｅ上のＦＴＰＳｅｒｖｅｒインスタンスは１層スタックを形成し、複数のＳｅｒｖｅｒＮｏｄｅは２層スタックを形成することにより、全体のＦＴＰＳｅｒｖｅｒ分散型クラスタを構成する。複数のＦＴＰユーザの高い同時接続にサービスを提供することができる。

ＦＴＰＳｅｒｖｅｒインスタンスは、コンテナ形態のマイクロサービスで、ＳｅｒｖｅｒＮｏｄｅ上で実行し、同一のＳｅｒｖｅｒＮｏｄｅ上の全てのＦＴＰＳｅｒｖｅｒコンテナには同じディスクアレイＬＵＮ高速ストレージをマウントし、分散協調によりアクセスを共有し、効率的なＩＯを利用してファイル転送効率を向上させる。これにより、本開示の高い同時実行性・高効率の設計目的を達成する。

図４に示すように、図４はＦＴＰＰｒｏｘｙのオフローディング及びアドレッシングのフローチャートである。

Ｓ４０１では、ＦＴＰ要求がＦＴＰＰｒｏｘｙに到達する。

Ｓ４０２では、ＦＴＰＰｒｏｘｙがＦＴＰＲＦＣプロトコル規格に従って要求を解析する。

Ｓ４０３では、ファイル転送類要求であるかを判断し、そうであれば、ステップＳ４０５に進み、そうでなければＳ４０４に進み、ローカルキャッシュ情報によって直接応答する。

Ｓ４０５では、現在のＦＴＰユーザ情報に基づいて対応するＦＴＰＳｅｒｖｅｒインスタンスを検索し、ＦＴＰＳｅｒｖｅｒインスタンスが複数存在する場合には、負荷分散アルゴリズム又はＲｏｕｎｄ－Ｒｏｂｉｎポーリングアルゴリズムに基づいて適切なＦＴＰＳｅｒｖｅｒインスタンスにアドレッシングすることができる。

Ｓ４０６では、ＦＴＰＣｌｉｅｎｔとＦＴＰＳｅｒｖｅｒインスタンスの間で直接ファイル転送チャネルを確立する。

Ｓ４０７では、ファイル転送(アップロード又はダウンロード)を行う。

図５に示すように、図５は分散協調アルゴリズムのフローチャートである。

同じサーバノード上のマルチＦＴＰＳｅｒｖｅｒコンテナインスタンスは、同一のファイルに対する読み書きが競合しないことを実現し、それとともに、同一のファイルに対して書き込み操作を行うＦＴＰＳｅｒｖｅｒインスタンスは１つのみでなければならず、書き込む際に同時に読み込むことができず、これはコンテナ間の分散ロックによって実現され、具体的な分散ロックアルゴリズムは以下の通りである。

前置条件:
同じサーバノードのＦＴＰＳｅｒｖｅｒコンテナは同一のディレクトリｃｌｕｓｔｅｒｌｏｃｋｓを分散ロックの一時ディレクトリとして用いる。

全ての分散ロックは１つのキーワード(又はファイルパス)を提供し、キーワードを１６進コードで表示し、各ロックはｃｌｕｓｔｅｒｌｏｃｋｓ下でこのキーワードを利用して一意のディレクトリを作成し、ディレクトリ下でロックを申請するコンテナＩＤに基づいて１つのファイルを作成し、このようにすると、コンテナごとにロックを申請する時に一意の一時ファイルｃｌｕｓｔｅｒｌｏｃｋｓ/＜ロックキーワード＞/＜コンテナＩＤ＞が生成される。

ロックの申請ができたコンテナが異常終了するのを防止するために、各ロックに６０秒の有効期限が設定される(ファイルの最終修正時刻に基づいて有効期限が切れているか否かを確認する)。

分散ロックの申請プロセスは以下の通りである。

１、ファイルロックに対応するディレクトリを取得する。

２、ロックディレクトリ(ｃｌｕｓｔｅｒｌｏｃｋｓ/＜ロックキーワード＞)にｌｏｃｋｅｄで始まるファイルが存在するか否かを検査し、存在しない場合にはステップ４に進む。存在しかつｌｏｃｋｅｄファイルの有効期限が切れていない場合には、ロックが既に取得されたことを示し、ロック取得に失敗する。

３、ｌｏｃｋｅｄファイルの有効期限が切れている場合には、ｌｏｃｋｅｄファイルを削除する。

４、ディレクトリにファイルが１つのみか否かを判断し、そうであればステップ５に進む。そうでなければ、複数のファイルをソートし、１番目のファイル名が本コンテナＩＤであるか否かを判断し、そうでなければロック取得に失敗し、そうであればステップ６に進む。

５、このファイルのファイル名が本コンテナＩＤであるか否かを判断し、そうでなければロック取得に失敗し、そうであれば続ける。

６、ファイル名にｌｏｃｋｅｄのプレフィクスを付ける。

７、１０ｍｓだけスリープし、一意のｌｏｃｋｅｄファイルであるか否かを再確認し、そうでなければステップ８に進み、そうであれば、ロックファイル名がｌｏｃｋｅｄ＋本コンテナＩＤ名であるか否かを再確認し、そうであればロック取得に成功し、そうでなければロック取得に失敗する。

８、複数のｌｏｃｋｅｄファイルが存在する場合には、再ソートし、１番目のファイル名に対応するコンテナがロックを取得し、残りのコンテナはロック取得に失敗し、自分で生成されたファイルをクリーンアップする。

９、プロセスが終了する。

上記過程において、プログラムが分散ロックを取得した後、使用時間が長すぎて６０秒を超える場合には、使用過程においてロックファイルの最終変更時刻を更新する必要がある。

以下の表１に示すように、１つの分散型ＦＴＰＳｅｒｖｅｒクラスタをインスタンス化する。

システムに、ＳｅｒｖｅｒＮｏｄｅ－Ａ、ＳｅｒｖｅｒＮｏｄｅ－Ｂ、ＳｅｒｖｅｒＮｏｄｅ－Ｃの３つのサーバノードが存在する。

ここで、ＳｅｒｖｅｒＮｏｄｅ－Ａにラベル「ＦＴＰ－Ａ」、「ＦＴＰ－Ｃ」を付け、それが「ＦＴＰ－Ａ」、「ＦＴＰ－Ｃ」の２つのタイプのＦＴＰＳｅｒｖｅｒインスタンスを実行できることを示し、ＳｅｒｖｅｒＮｏｄｅ－Ｂに「ＦＴＰ－Ａ」、「ＦＴＰ－Ｂ」を付け、ＳｅｒｖｅｒＮｏｄｅ－Ｃに「ＦＴＰ－Ｂ」、「ＦＴＰ－Ｃ」を付ける。

ＦＴＰＳｅｒｖｅｒインスタンスには、ＦＴＰ－Ａ、ＦＴＰ－Ｂ、ＦＴＰ－Ｃの３つのタイプがある。ここで、ＦＴＰ－ＡはＦＴＰユーザｕｓｅｒ－Ａｌ、ｕｓｅｒ－Ａ２、ｕｓｅｒ－Ａ３にサービスを提供することができ、その対応するワーキングディレクトリの位置するディスクアレイＬＵＮはＬＵＮ－Ａである。

ＦＴＰ－ＡにＦＴＰＳｅｒｖｅｒ－Ａ－１、ＦＴＰＳｅｒｖｅｒ－Ａ－２、ＦＴＰＳｅｒｖｅｒ－Ａ－３の３つの実行インスタンスが配置される。ＦＴＰ－Ａは「ＦＴＰ－Ａ」ラベルが付けられたサーバノード、即ちＳｅｒｖｅｒＮｏｄｅ－Ａ又はＳｅｒｖｅｒＮｏｄｅ－Ｂでのみ実行することができる。

図６は、好ましい分散型ＦＴＰクラスタアフィニティ及びＨＡを示す図である。

アフィニティの原則により、次のようになる。

ＦＴＰＳｅｒｖｅｒ－Ａ－１、ＦＴＰＳｅｒｖｅｒ－Ａ－２、ＦＴＰＳｅｒｖｅｒ－Ａ－３などのＦＴＰ－ＡタイプのＦＴＰＳｅｒｖｅｒインスタンスは全て「ＦＴＰ－Ａ」ラベルが付けられたＳｅｒｖｅｒＮｏｄｅ－Ａで実行され、また、対応するディスクアレイＬＵＮ－ＡもＳｅｒｖｅｒＮｏｄｅ－Ａにマウントされる。

ＦＴＰＳｅｒｖｅｒ－Ｂ－１、ＦＴＰＳｅｒｖｅｒ－Ｂ－２などのＦＴＰ－ＢタイプのＦＴＰＳｅｒｖｅｒインスタンスは全て「ＦＴＰ－Ｂ」ラベルが付けられたＳｅｒｖｅｒＮｏｄｅ－Ｂで実行され、また、対応するディスクアレイＬＵＮ－ＢもＳｅｒｖｅｒＮｏｄｅ－Ｂにマウントされる。

ＦＴＰＳｅｒｖｅｒ－Ｃ－１、ＦＴＰＳｅｒｖｅｒ－Ｃ－２、ＦＴＰＳｅｒｖｅｒ－Ｃ－３などのＦＴＰ－ＣタイプのＦＴＰＳｅｒｖｅｒインスタンスは全て「ＦＴＰ－Ｃ」ラベルが付けられたＳｅｒｖｅｒＮｏｄｅ－Ｃで実行され、また、対応するディスクアレイＬＵＮ－ＣもＳｅｒｖｅｒＮｏｄｅ－Ｃにマウントされる。

この時、システムに異常が発生し、ＳｅｒｖｅｒＮｏｄｅ－Ａが停止したと仮定すると、クラスタ管理システムは、ＳｅｒｖｅｒＮｏｄｅ－ＡでＦＴＰＳｅｒｖｅｒ－Ａ－１、ＦＴＰＳｅｒｖｅｒ－Ａ－２、ＦＴＰＳｅｒｖｅｒ－Ａ－３というＦＴＰ－ＡタイプのＦＴＰＳｅｒｖｅｒインスタンスの全てが実行されていることを確認できる。

ラベル付けルールに従い、ＦＴＰ－Ａタイプのインスタンスを実行できるサーバノードＳｅｒｖｅｒＮｏｄｅ－Ｂ(ラベル「ＦＴＰ－Ｂ」が付けられたため)を検索し、続いて、まず対応するディスクアレイＬＵＮ－ＡをＳｅｒｖｅｒＮｏｄｅ－Ｂにマウントしてから、全体的にＦＴＰＳｅｒｖｅｒ－Ａ－１、ＦＴＰＳｅｒｖｅｒ－Ａ－２、ＦＴＰＳｅｒｖｅｒ－Ａ－３というＦＴＰ－Ａタイプのインスタンスの全てをＳｅｒｖｅｒＮｏｄｅ－Ｂに切り替えて実行する。この場合、ＳｅｒｖｅｒＮｏｄｅ－ＢはＦＴＰ－ＢとＦＴＰ－Ａの２つのタイプのＦＴＰＳｅｒｖｅｒインスタンスを同時に実行し、ＬＵＮ－Ｂ、ＬＵＮ－Ａを同時にマウントする。

このように、切り替えられた実行形態は、ラベル付けとアフィニティポリシーを満たし、対応するローカルディスクアレイＬＵＮを使用でき、また、異常発生時のＨＡを実現することができる。

図６に示すように、ＳｅｒｖｅｒＮｏｄｅ－Ａノードがオフラインした後、ＦＴＰＳｅｒｖｅｒ－Ａ－１、ＦＴＰＳｅｒｖｅｒ－Ａ－２、ＦＴＰＳｅｒｖｅｒ－Ａ－３インスタンスは全体的にＳｅｒｖｅｒＮｏｄｅ－Ｂノードに移行して実行し、クラスタ移行時にＬｕｎ－ＡをＳｅｒｖｅｒＮｏｄｅ－Ｂノードにマウントする。

ここで、File Transfer Protocol(ＦＴＰ)はネットワーク上でファイル転送を行うための標準プロトコルであり、論理ユニット番号(Logical Unit Number、ＬＵＮ)はサーバに直接認識され得る独立したストレージユニットである。

以上の実施形態の説明から、当業者であれば、上記実施例の方法に従ってソフトウェアと必要な汎用ハードウェアプラットフォームの方式によって実現することができ、勿論、ハードウェアを介して実現できるが、多くの場合、前者がより好ましい実施形態であることを明白に理解できる。

このような理解に基づいて、本開示の技術方案の本質又は従来技術に寄与する部分は、ソフトウェア製品の形で具現化することができ、このコンピュータソフトウェア製品は記憶媒体(例えば、ＲＯＭ/ＲＡＭ、磁気ディスク、光ディスク)に記憶され、１台の端末デバイス(携帯電話、サーバ又はネットワークデバイスなどであってもよい)に本開示の各実施例に記載の方法を実行させるための複数の命令を含む。

本実施例ではデータ転送装置をさらに提供し、この装置は上記実施例及び好ましい実施形態を実現するために使用され、既に説明した内容は説明を省略する。以下で使用されるように、用語「モジュール」は所定機能のソフトウェア及び/又はハードウェアの組み合わせを実現することができる。以下の実施例で説明される装置は、好ましくはソフトウェアで実現されるが、ハードウェア、又はソフトウェアとハードウェアの組み合わせの実現も可能であり、想定される。

図７は本開示の実施例に係るプロキシサーバの構成を示すブロック図であり、図７に示すように、このプロキシサーバは、
クライアントから送信された目標要求を受信するように構成されるユニットであって、前記目標要求は、データサーバ内の目標ファイルの目標属性情報の閲覧を要求するために用いられる閲覧要求、又は、目標ファイルを前記データサーバに転送すること又は前記データサーバから取得することを要求するために用いられる転送要求である受信ユニット７０２と、
前記目標要求が閲覧要求の場合、前記目標ファイルの前記目標属性情報を保存された属性情報副本から取得し、前記クライアントに返信するように構成されるユニットであって、前記属性情報副本には、前記目標ファイルの目標ファイル識別子と前記目標属性情報との対応関係が記録されている第１取得ユニット７０４と、
前記目標要求が転送要求の場合、前記目標要求を前記データサーバ内の目標サーバに送信するユニットであって、前記データサーバは、２層スタック型のＦＴＰＳｅｒｖｅｒマルチインスタンス分散型クラスタサーバであり、複数の第１サーバを含み、前記プロキシサーバには各前記第１サーバから報告されたＦＴＰユーザ処理範囲が記録されている第１送信ユニット７０６と、を含む。

上記プロキシサーバにより、ファイル転送過程において、プロキシサーバを介してファイルのスケジューリングを行うことができ、閲覧要求はプロキシサーバを介して目標属性情報を直接返信することができ、転送要求は異なる目標サーバに送信して処理することができるため、ファイル転送効率が低いという問題を解決し、ファイル転送効率の向上効果を達成することができる。

本開示の実施例はコンピュータ読み取り可能な記憶媒体をさらに提供する。このコンピュータ読み取り可能な記憶媒体には、実行されると上記いずれか１項の方法の実施例におけるステップを実現するように構成されるコンピュータプログラムが記憶されている。

一例示的な実施例では、上記コンピュータ読み取り可能な記憶媒体は、Ｕディスク、読み取り専用メモリ(Read-Only Memory、ＲＯＭと略称する)、ランダムアクセスメモリ(Random Access Memory、ＲＡＭと略称する)、リムーバブルハードディスク、磁気ディスク又は光学ディスクなどコンピュータプログラムを記憶できる様々な媒体を含み得るが、これらに限定されない。

本開示の実施例は、コンピュータプログラムが記憶されているメモリと、コンピュータプログラムを実行して上記いずれか１項の方法の実施例におけるステップを実現するように構成されるプロセッサとを含む電子デバイスをさらに提供する。

一例示的な実施例では、上記電子デバイスは、上記プロセッサに接続される伝送装置及び上記プロセッサに接続される入出力装置をさらに含んでもよい。

本実施例の具体的な例は上記実施例及び代替的な実施形態で説明される例示を参照することができるが、本実施例では説明を省略する。

明らかに、当業者であれば、上記の本開示の各モジュール又は各ステップは汎用のコンピューティングデバイスで実現することができ、それらは個別のコンピューティングデバイスに集中し、又は複数のコンピューティングデバイスからなるネットワークに分散することができ、それらはコンピューティングデバイスの実行可能なプログラムコードで実現することができ、従って、それらを記憶装置に記憶してコンピューティングデバイスで実行することができ、かつ場合によっては、ここの順序と異なるもので図示又は記載されたステップを実行し、又はそれらを各集積回路モジュールとしてそれぞれ作製し、それらの複数のモジュール又はステップを個別の集積回路モジュールとして作製することで実現することができることが分かるであろう。このように、本開示はいかなる特定のハードウェアとソフトウェアの特定の組み合わせに限定されない。

以上の記載は本開示の好ましい実施例に過ぎず、本開示を限定するものではなく、当業者であれば、本開示に様々な修正及び変更を行うことができる。本開示の原則内で行われる任意の修正、均等な置換、改良等は、いずれも本開示の保護範囲内に含まれるべきである。

Claims (13)

1. プロキシサーバがクライアントから送信された目標要求を受信するステップであって、前記目標要求は、データサーバ内の目標ファイルの目標属性情報の閲覧を要求するために用いられる閲覧要求、又は、目標ファイルを前記データサーバに転送すること又は前記データサーバから取得することを要求するために用いられる転送要求であるステップと、
   前記目標要求が閲覧要求の場合、前記プロキシサーバが前記目標ファイルの前記目標属性情報を保存された属性情報副本から取得し、前記クライアントに返信するステップであって、前記属性情報副本には、前記目標ファイルの目標ファイル識別子と前記目標属性情報との対応関係が記録されているステップと、
   前記目標要求が転送要求の場合、前記プロキシサーバが前記目標要求を前記データサーバ内の目標サーバに送信するステップであって、前記データサーバは、２層スタック型のＦＴＰＳｅｒｖｅｒマルチインスタンス分散型クラスタサーバであり、複数の第１サーバを含み、前記プロキシサーバには各前記第１サーバから報告されたＦＴＰユーザ処理範囲が記録されているステップと、を含む、
   データ転送方法。
2. 前記プロキシサーバが前記クライアントから送信された前記目標要求を受信する前記ステップの前に、
   前記データサーバ内の全てのファイルのファイル識別子と全てのファイルの属性情報を取得するステップと、
   前記データサーバ内の全てのファイルのファイル識別子と全てのファイルの属性情報を前記属性情報副本に保存するステップと、をさらに含む、
   請求項１に記載のデータ転送方法。
3. 前記プロキシサーバが前記クライアントから送信された前記目標要求を受信する前記ステップの前に、
   ユーザ識別子と前記第１サーバとの対応関係を取得するステップであって、異なる前記ユーザ識別子は異なる前記第１サーバに対応付けられるステップと、
   前記対応関係を内部メモリに保存するステップと、をさらに含む、
   請求項１に記載のデータ転送方法。
4. 前記目標要求が閲覧要求の場合、前記目標ファイルの前記目標属性情報を前記プロキシサーバに保存された属性情報副本から取得し、前記クライアントに返信する前記ステップは、
   前記目標要求内の前記目標ファイルの前記目標ファイル識別子を取得するステップと、
   前記目標ファイル識別子に対応する前記目標属性情報を前記属性情報副本から取得するステップと、
   前記目標属性情報を前記クライアントに返信するステップと、を含む、
   請求項１に記載のデータ転送方法。
5. 前記目標要求が転送要求の場合、前記目標要求を前記データサーバ内の前記目標サーバに送信する前記ステップの前に、
   前記クライアントの目標ユーザ識別子を取得するステップと、
   内部メモリのうち、前記目標ユーザ識別子に対応する前記目標サーバを検索するステップと、
   前記転送要求を前記目標サーバに送信するステップと、をさらに含む、
   請求項１に記載のデータ転送方法。
6. 内部メモリのうち、前記目標ユーザ識別子に対応する前記目標サーバを検索する前記ステップは、
   前記目標ユーザ識別子に対応する複数のサーバを検索した場合、前記複数のサーバから負荷バランスの最も低いサーバを前記目標サーバとして選択するか、又は、ポーリングアルゴリズムを利用して前記複数のサーバから前記目標サーバを決定するステップを含む、
   請求項５に記載のデータ転送方法。
7. 前記目標要求が転送要求の場合、前記目標要求を前記データサーバ内の前記目標サーバに送信する前記ステップの後に、
   前記クライアントと前記目標サーバとの間にデータ転送チャネルを確立するステップと、
   前記データ転送チャネルを介して、前記クライアントと前記目標サーバとの間で前記目標ファイルを転送するステップと、をさらに含む、
   請求項５に記載のデータ転送方法。
8. 前記プロキシサーバがクライアントから送信された目標要求を受信する前記ステップの前に、
   前記属性情報副本のファイルサイズが所定閾値未満である場合、前記属性情報副本を内部メモリに保存するステップと、
   前記属性情報副本のファイルサイズが所定閾値以上である場合、前記属性情報副本をメモリに保存するステップと、をさらに含む、
   請求項１に記載のデータ転送方法。
9. 前記目標要求が転送要求の場合、前記プロキシサーバが前記目標要求を前記データサーバ内の前記目標サーバに送信する前記ステップの前に、
   同一の前記第１サーバに位置する複数のＦＴＰＳｅｒｖｅｒインスタンスを利用して１層スタック構造を形成するステップと、
   複数の前記第１サーバを利用して２層スタック構造を形成し、前記データサーバを得るステップと、をさらに含む、
   請求項１に記載のデータ転送方法。
10. 複数の前記第１サーバを利用して２層スタック構造を形成し、前記データサーバを得る前記ステップの後に、
    同一の前記第１サーバにおける複数の前記ＦＴＰＳｅｒｖｅｒインスタンスを同じディスクアレイＬＵＮ高速ストレージにマウントするステップをさらに含む、
    請求項９に記載のデータ転送方法。
11. クライアントから送信された目標要求を受信するように構成される受信ユニットであって、前記目標要求は、データサーバ内の目標ファイルの目標属性情報の閲覧を要求するために用いられる閲覧要求、又は、目標ファイルを前記データサーバに転送すること又は前記データサーバから取得することを要求するために用いられる転送要求である受信ユニットと、
    前記目標要求が閲覧要求の場合、前記目標ファイルの前記目標属性情報を保存された属性情報副本から取得し、前記クライアントに返信するように構成される第１取得ユニットであって、前記属性情報副本には、前記目標ファイルの目標ファイル識別子と前記目標属性情報との対応関係が記録されている第１取得ユニットと、
    前記目標要求が転送要求の場合、前記目標要求を前記データサーバ内の目標サーバに送信するように構成される第１送信ユニットであって、前記データサーバは、２層スタック型のＦＴＰＳｅｒｖｅｒマルチインスタンス分散型クラスタサーバであり、複数の第１サーバを含み、前記プロキシサーバには各前記第１サーバから報告されたＦＴＰユーザ処理範囲が記録されている第１送信ユニットと、を含む、
    プロキシサーバ。
12. コンピュータプログラムが記憶されているコンピュータ読み取り可能な記憶媒体であって、
    前記コンピュータプログラムは実行される時に請求項１～１０のいずれか１項に記載のデータ転送方法を実現するように構成される、
    コンピュータ読み取り可能な記憶媒体。
13. コンピュータプログラムが記憶されているメモリと、前記コンピュータプログラムを実行して請求項１～１０のいずれか１項に記載のデータ転送方法を実現するように構成されるプロセッサと、を含む、
    電子デバイス。

Images