ワイドエリアネットワーク(WAN)利用時の検討事項

この記事では、WANネットワーク上にPaperCutを設置する場合の検討事項について記載します。
1つのサイトにプライマリ・サーバを設置し、他のサイトにはローカル・プリント・サーバを設置する想定です。

オプション1 – PaperCutサイト・サーバの展開

PaperCutサイト・サーバは、最も堅牢なマルチ・サイトPaperCut展開モデルを提供します。
多くのPaperCutの導入では、中央にプライマリ・サーバを設置し、
多数のローカル・プリント・サーバがWANリンクを経由してプライマリ・サイトに通信するように設計されています。
利点は次の通りです。

　● ログの一元化

　● 管理の一元化

　● 1つのサイトだけでバックアップが可能

　● システム管理の軽減

　● ユーザは単一のアカウントと設定を保持したまま「ローミング」可能

しかし、このソリューションはプライマリ・サイトとセカンダリ・サイト間のWANの可用性に依存します。
PaperCutサイト・サーバは、プライマリ・サーバが利用できなくなった場合に備えて、各リモート・サイトに導入することができ、
集中型のインストールの機能はすべて維持されます。ネットワークが停止しても印刷やコピーのサービスは継続して利用できます。
システム管理者は次の事項を考慮する必要があります。

　● 既存のプリント・プロバイダは、簡単にサイト・サーバにアップグレードすることができます。サーバ・インフラを効率的に利用可能です。

　● 設定データはサイト間で複製されるため、多少のトラフィック・オーバーヘッドが発生します。
　　一方でサイト・サーバは、エンベデッド・デバイスからのWANトラフィックを削減します。
　　正確なトラフィック量は、ソリューションのユーザ数と各サイトのエンベデッド・デバイスの数によって異なります。

　● クライアント・サーバ間の通信(オプション2を参照)は、WANリンクを通過するため、帯域幅消費の影響は軽微です。

オプション2 – 1つのサイトがプライマリ・サーバをホストしリモート・サイト(複数)は
プライマリ・サーバにレポートするローカル・プリント・サーバをホストする

サイト間の信頼性の高い高品質なWANリンクがある環境では、PaperCutサイト・サーバを使用せずにマルチサイトソリューションを導入することができます。
システム管理者は次の落とし穴があることを考慮する必要があります。

　● ネットワーク接続の障害やダウンによってログが喪失する可能性があります。
　　デフォルトでPaperCutはフェイルオープン設計になっており、障害時に印刷が中断されることはありません。
　　しかし故障モードに「新規プリント・ジョブの印刷を許可(再接続後に記録)」が選択されていない場合、
　　障害期間中の一部のログ・データが失われる可能性があります。
　　後者のモードの場合、接続が再会された時に、ジョブ・ログのデータがサーバに再送信されます。

　● サーバ - サーバ間、クライアント – サーバ間の通信でもある程度の帯域を消費します。
　　しかし、標準的な接続に伴うトラフィックは非常に小さいです。
　　通信に使用するプロトコルは、HTTPをベースとしたXML Webサービス(XML-RPC) で、
　　帯域幅の効率がよく、高遅延のWANリンクでも動作するように設計されています。
　　予想されるトラフィックは次の通りです。

　　　　・ サーバ – サーバ間の通信: 1つのプリント・ジョブ当たり500バイト(0.5KB)

　　　　・ クライアント – サーバ間の通信(静的負荷): 1分間に役200バイト(0.2KB)

オプション3 – 1つのサイトがセントラル・レポート・サーバをホストし、
リモート・サイトがそれぞれのプライマリ・プリント・サーバをホストしてレポーティング・サーバにレポートする

分散方式でPaperCutをインストールするためには、各サイトに独立してインストールする必要があります(各サイトがプライマリ・サーバをホストします)。
自律したいくつかのサイトがある場合、この方法がより適切な構成となります。
この場合、各サイトにPaperCutプライマリ・サーバを設置することができます。
この構成はPaperCutの「セントラル・レポート」機能を利用しています。
これにより、各サイトのデータベースが1つの中央のロケーションに接続され、データが統合されて簡単にレポート生成できるようになります。
レポートの整合性を保ちつつ、各サイトはWANに依存しないという大きなメリットがあります。
PaperCutはブラウザ・ベースの管理コンソールがあるため、管理者はリモートのPaperCutサーバを集中管理したり、
サイトごとに分離してローカル管理したり、必要に応じて両方を組み合わせたりすることができます。

一元化されたセットアップでのクライアント展開に関する特別な注意事項

クライアントのゼロインストール展開はは最も簡単な展開方法です。
WANタイプの環境でこの方法のそのまま使用すると、起動時にクライアントのバイナリや関連ファイルが中央のサーバから取り込まれてしまうという欠点があります。
これは高速なローカルネットでは問題になりませんが、WANネットワークからクライアントをプルダウンする場合に問題になる可能性があります。
そのため、リモート・サイト(PaperCutのプライマリ・サーバが設置されているサイト以外)では、次の代替え方法を推奨します。

　① クライアント・ソフトウェアをローカル・インストールするか、「pc-client-local-cache.exe」を使用することを検討してください。

　② より良い方法は、リモート・サイトのクライアントをローカル共有でホストすることです。
　　 これには、リモート・サイトのサーバ上にメインサーバ上のPCClientの共有をミラーリングする共有を作成する必要があります。
　　 サーバ上にフォルダを作成し、プライマリ・サーバのPCClientとして共有し、
　　 プライマリ・サーバのPCClientの共有からすべてのファイルをコピーするだけです。
　　 リモート・サイトのクライアントがローカルコピーを起動するように設定します。
　　 注記: 将来プライマリ・サーバをアップグレードする場合、このリモートのシェアポイントのクライアントもアップグレードするようにしてください。

　③ 専門のシステム管理者がいる大規模な組織では、Microsoft DFS(ファイル分散システム) や他のプラットフォームの同党の技術を利用することにより、
　　 オプション2を向上することができます。これによりクライアントの共有にアクセスする際に「ローカルなトランスペアレント」が確保されます。
　　 また、クライアントを起動すると、サーバに接続されることにも注意が必要です。
　　 しかし、標準的な接続に伴うトラフィックは非常に小さいです。
　　 このプロトコルはHTTPをベースとしたXML Webサービスで、帯域幅の効率が良く、高遅延のWANリンクでも動作するように設計されています。

-------------------------

https://www.papercut.com/kb/Main/WideAreaNetworkConsiderations