岩手県立大学サービスサーバシステム更新に係る …岩手県立大学...

岩手県立大学

サービスサーバシステム

更新に係る提案仕様書

平成 23 年 4 月

公立大学法人岩手県立大学

1/46

目次

1.はじめに ................................................................. 2

2.提案範囲 ................................................................. 4

3.基本的要件 ............................................................... 5

4.システム要件 ............................................................. 6

4.1認証サービス .......................................................... 6

4.2 ファイル共有サービス ................................................ 11

4.3 メールサービス ...................................................... 16

4.4 DNSサービス ......................................................... 23

4.5 授業支援サービス .................................................... 27

4.6 汎用サービス ........................................................ 31

4.7 管理サービス ........................................................ 34

5.導入・撤去要件 .......................................................... 42

6.ドキュメント要件 ........................................................ 43

7.運用・保守・サポート要件 ................................................ 44

7.1 体制 ................................................................ 44

7.2 運用・保守作業 ...................................................... 44

7.3 障害対応 ............................................................ 45

7.4 サポート ............................................................ 45

7.5 保守費用 ............................................................ 46

2/46

1.はじめに

1.1 本調達の背景

1.1.1 これまでの経緯

平成１０年の開学以来、本学は「実学実践」を中核とした実証研究を進め、「地域

の中核人材育成」と「地域の活力創出」に積極的に取り組んでいるところである。併

せてこれらを支える学内情報システムについては、ＩＣＴ技術の動向や利用者の要望

と利便性に配慮しながら、継続して整備を進めてきている。

平成２０年度から、第３次学内情報システムとしてコンピュータ教室や情報端末、

学内ネットワークなどのシステム更新を進めており、本調達ではサービスサーバ群の

システム更新を行うものである。現在稼働しているサービスサーバ群は、更新から６

年半が経過し、メーカが定める機器保守の期限を迎えるため、安定運用の観点から早

期の更新が望まれている。

1.1.2 学内情報システムの役割

本学の学内情報システムは、滝沢キャンパスを中心として、宮古キャンパス、アイ

ーナキャンパス、地域連携研究センターなどをネットワークで結び、全教職員および

全学生の各種活動を支える基盤としての役割を担っている。

また、本学は情報システム技術者の育成を目的とするソフトウェア情報学部を有し

ており、学内情報システムは、この教育・研究を支える基盤としての役割も担ってい

る。

本学を支える重要な基盤であることから、学内情報システムは、年間を通じて機器

の停止やシステムトラブルが少ない、安定したシステムを目指している。

1.1.3 現状の課題

ＩＣＴ技術の進化とともに、サービスサーバ群に求められる要件も変化し、現在の

システム構成は必ずしも最適なものではなくなっている。新しいサービスサーバ群に

は、要件に合った最適なシステム構成であることが求められる。

3/46

1.2 本調達の目的

1.2.1 システム構成の最適化

後述するシステム要件に対し、過不足のない最適なシステム構成とすること。

1.2.2 安定したサービスの提供

本学ヘルプデスクと密に連携し、的確なシステム運用や保守作業、障害対応作業を

提供すること。加えて適切な可用性を備えたシステム構成とし、結果として機器の停

止やシステムトラブルが少ない、安定したサービスを提供すること。

1.2.3 費用対効果のバランス

なるべく全体費用を抑えながらも、信頼性の高いシステムを構築し運用することを

目指しているので、費用対効果のバランスの良いシステム構成とすること。

1.2.4 確実なシステム移行

業務継続性を担保し、安全かつ確実に移行すること。

4/46

2.提案範囲

A) 以下の項目について提案を求めるものである。

1) システム設計

2) 機器の調達、搬入、設置、据付、配線

3) 一次電源からの各機器への電源配線

4) 既存ネットワーク機器からのネットワーク配線

5) 既存ネットワークの設定変更作業 ※必要であれば

6) システム設定および調整

7) データ移行（既存システムからのデータ抜き出し含む）

8) テスト

9) 本番稼働開始時の立ち会い

10) 本学ヘルプデスクへの教育

11) 各種マニュアル作成

12) 既存機器の撤去（データ削除、取外し、学内指定場所への運搬）

13) 運用設計

14) 6 年間の障害対応、サポート、機器およびソフトウェア保守

15) 上記 1)～14) の附帯作業

以下の項目については依頼範囲外である。

1) 空調工事

2) 一次電源工事

3) システム維持管理の定型作業

4) 障害の一次切り分け

5/46

3.基本的要件

※ 基本的要件は全て必須の要求要件である。

A) 本仕様書の要求要件をどのように満たすか、あるいはどのように実現するかを要求

要件ごとに具体的かつわかりやすく、資料を添付するなどして提案すること。審査

するにあたって提案の根拠が不明確、説明が不十分で技術審査に重大な支障がある

と判断した場合は、要求要件を満たしていないものとみなす。

B) 要求要件について技術審査で満たされていないと判断された場合は、不合格として

審査の対象から除外される。

C) システム導入期間は、契約開始日（2011 年 5 月中旬を予定）の翌日から 2011 年 9

月 23 日（金）までとする。

D) 機器の搬入、本学仕様へのセットアップ、データ移行、運用テストおよびその調整

を行い、それらが全て正常に動作し、稼働可能なことの確認を済ませた上、2011

年 9 月 23 日（金）までに引き渡すこと。

E) 本システムは、2011 年 9 月 24 日（土）より稼働し、システム稼働期間は 6 年間（2017

年 9 月 23 日（土）まで）とする。

F) 契約期間は、契約開始日（2011 年 5 月中旬を予定）から 2011 年 9 月 23 日（金）

までとする。

G) 機器およびソフトウェアの保守契約は、別途本学と協議の上、構築予定者と契約を

取り交わすものとする。

H) 6 年間システムを稼働するためにライセンス等が必要な場合は、2011 年 9 月 24 日

（土）から 2017 年 9 月 23 日（土）まで使用可能なライセンスを、システム導入

時に取得すること。

I) 本件に係る経費としての想定額は以下に示すものである。

想定額内で提案すること。

1) 総期間契約開始日～2017 年 9 月 23 日（土）

328,000 千円（消費税及び地方消費税を含む）

2) 今年度契約開始日～2012 年 3 月 31 日（土）

163,000 千円（消費税及び地方消費税を含む）

なお、この想定額は契約時の予定価格を示すものではなく、想定している最大の規

模を示すものである。

J) 本件にて知り得たすべての事実に関して、契約期間中はもとより、契約前、契約終

了後においても外部に漏らしてはならない。

6/46

4.システム要件

※ 機能要件は全て必須の要求要件である。

※ サービスを提供する機器は、要件を満たすの

であれば、1 つの機器で複数のサービスを提供

しても構わない。

4.1 認証サービス

4.1.1 Active Directory

機能要件

A) WindowsXp/Vista/7 端末(以降Windows 端末という)および

Windows2000/2003/2008/2008R2 サーバ(以降 Windows サーバという)、MacOSX

端末(以降 Mac 端末という)の認証情報、アクセス制限情報を一元管理可能なこと。

B) 学生、教員、職員がWindows 端末および Mac 端末を利用する際、１つのユーザ

ID・パスワードでログオンし利用可能なこと。

C) 教室において、Windows 端末にログオン時、Internet Explorer のブックマークが

Windows 端末間で共有可能なこと。

D) DNS サービスおよび Wins サービスを提供すること。

E) 学外利用者用アカウントが利用可能なこと。

F) 現行プリンタ利用制限システムからのログオン認証が可能なこと。

G) 現行事務管理システムからのログオン認証が可能なこと。

H) 現行証明書発行システムからのログオン認証が可能なこと。

I) 現行パスワード変更システムからパスワードが変更可能なこと。

技術要件

A) Windows 端末の認証システムは、Active Directory が動作すること。

B) 冗長化のためにマルチマスタ構成に対応可能なこと。

セキュリティ要件

7/46

A) ユーザの所属に応じて適切にセキュリティ権限を付与すること。

B) 二重ログインを防止または、二重ログインユーザを特定できる仕組みを提供する

こと。

C) 学外利用者用アカウントの不正利用を防止すること。

D) 認証時にパスワードなどのユーザデータが漏洩しないこと。

E) 学外から直接アクセスできないこと。

F) 提案機器が汎用サーバの際は、OS に対しウィルス対策を行うこと。なお、ウィ

ルス対策ソフトウェアとして本学所有のエフセキュア社製エフセキュアアンチウ

イルスを使用することが望ましいが、提案 OS がエフセキュア社製エフセキュア

アンチウイルスの動作対象外の OS であれば、提案 OS で動作するウィルス対策

ソフトウェアを導入し、稼働期間のウィルスバターンファイルの更新、サポート

等を行うこと。

運用要件

A) Active Directory の学生、教員、職員のユーザアカウントを一括で登録/削除可能な

こと。

B) 学外利用者向けアカウントの有効化/無効化が可能なこと。

C) SNMP に対応し、監視ソフトウェア等で死活監視可能なこと。

性能要件

A) 3,000 人以上の利用に耐えられる性能、構成であること。

耐障害性（可用性）要件

A) システム全体の冗長化を図ること。

B) 電源は機器単体の冗長化を図り、活性交換が可能であること。

C) ハードディスクを必要とする際は、機器単体の冗長化を図り、活性交換が可能で

あること。

D) 1000Base-T のネットワークインターフェースを 2 ポート以上有し、ネットワー

クアダプターはネットワークチーミングに対応していること。

データ移行要件

8/46

A) Active Directory のユーザ情報、権限等を移行すること。なお、現行情報等の移行

が困難または制約等ある場合は、代替案を具体的に提案すること。

B) 学生、教員、職員及び教室のWindows 端末、Mac 端末に対し、極力設定変更が

発生しないこと。

4.1.2 LDAP

機能要件

A) Linux、Solaris 端末からの認証情報・アクセス制限情報を一元管理可能なこと。

B) Linux、Solaris 端末からのログイン認証が可能なこと。

C) １人で複数の Linux、Solaris 端末及び LDAP を使用するシステムを利用する場合

でも、１つのユーザ ID、パスワードでログイン可能なこと。

D) Linux、Solaris 利用者の home 領域を｢4.2.2 Unix ユーザ用ファイルサーバ｣に割

り当て可能なこと。

E) ユーザの home ディレクトリに Quota による容量制限を行えること。

F) メール受信時の認証が可能なこと。

G) ユーザの氏名、メールアドレスが検索可能なこと。

H) 現行図書情報管理システムからのログイン認証が可能なこと。

I) 現行研究者情報管理システムからのログイン認証が可能なこと。

技術要件

A) 冗長化のためにマルチマスタ構成に対応可能なこと。


A) ユーザの所属に応じて適切にセキュリティ権限を付与すること。

B) 認証時にパスワードなどのユーザデータが漏洩しないこと。

C) 学外から直接アクセスできないこと。

D) 提案機器が汎用サーバの場合は、OS に対しウィルス対策を行うこと。なお、ウ

ィルス対策ソフトウェアとして本学所有のエフセキュア社製エフセキュアアンチ

ウイルスを使用することが望ましいが、提案 OS がエフセキュア社製エフセキュ

9/46

アアンチウイルスの動作対象外の OS であれば、提案 OS で動作するウィルス対

策ソフトウェアを導入し、稼働期間のウィルスバターンファイルの更新、サポー

ト等を行うこと。

運用要件

A) 学生、教員、職員のユーザアカウントを一括で登録/削除で可能なこと。

B) SNMP に対応し、監視ソフトウェア等で死活監視可能なこと。

性能要件

A) 3,000 人以上の利用に耐えられる性能、構成であること。また、クライアントか

らの 200 人の同時ログイン認証および 100 人の同時メール認証に 1～2 秒程度で

対応可能な性能を有すること。




C) ハードディスクを必要とする場合は、機器単体の冗長化を図り、活性交換が可能

であること。




A) LDAP のユーザ情報、権限等を移行すること。なお、現行情報等の移行が困難ま

たは制約等ある場合は代替え案を本学に提示し協議すること。

B) 学生、教員、職員及び教室のWindows 端末、Mac 端末に対し、極力設定変更が

発生しないこと。

4.1.3 Radius

機能要件

A) 現行ダイアルアップ接続機器からのログイン認証が可能なこと。

10/46

B) 現行 VPN 接続機器からのログイン認証が可能なこと。


A) 利用可能なユーザのみダイアルアップ接続、VPN 接続を許可可能なこと。

B) 二重ログインを防止または、二重ログインユーザを特定できる仕組みを提供する

こと。

C) 認証時にパスワードなどのユーザデータが漏洩しないこと。

D) 学外から直接アクセスできないこと。

E) 提案機器が汎用サーバの場合は、OS に対しウィルス対策を行うこと。なお、ウ







A) 電源は機器単体の冗長化を図り、活性交換が可能であること。

B) ハードディスクを必要とする場合は、機器単体の冗長化を図り、活性交換が可能

であること。

C) 1000Base-T のネットワークインターフェースを 2 ポート以上有し、ネットワー



A) Radius のユーザ情報、権限等を移行すること。なお、現行情報等の移行が困難ま

たは制約等ある場合は、代替案を具体的に提案すること。

B) ダイアルアップ接続、VPN 接続機器に対し、極力設定変更が発生しないこと。

11/46

4.2 ファイル共有サービス

4.2.1 全学ファイルサーバ

機能要件

A) 学生が使用可能な個人用ネットワークフォルダを提供すること。

B) 教員が使用可能な個人用ネットワークフォルダを提供すること。

C) 職員が使用可能な個人用ネットワークフォルダを提供すること。

D) 各学部が使用可能な共有ネットワークフォルダを提供すること。

E) 教職員が使用可能な共有ネットワークフォルダを提供すること。

F) 滝沢キャンパスの教職員が使用可能な共有ネットワークフォルダを提供すること。

G) 宮古キャンパスの教職員が使用可能な共有ネットワークフォルダを提供すること。

H) 入試担当が使用可能な共有ネットワークフォルダを提供すること。

I) 現行 Web メールサーバのWeb メールの個人設定保存領域を提供すること。

J) ドメイン参加端末へのログオン時に自動的に個人用ネットワークフォルダをマウ

ント可能なこと。

K) 教室において、Internet Explorer のお気に入りファイルを共有フォルダ上に保存

し、参照・更新可能なこと。

技術要件

A) ネットワークフォルダは、Windows 端末、Mac 端末、Solaris、Linux から接続が

可能なこと。

B) 共有フォルダは、Windows 端末、Mac 端末から接続が可能なこと。

C) Active Directory との認証が可能なこと。

D) Linux/ Solaris から NFS で接続が可能なこと。

E) ネットワークフォルダに対し、Active Directory 認証および LDAP 認証を個別及び

同時に提供可能なこと。

F) VLAN に対応しており、VLAN に対しアクセス可能なネットワークフォルダを設

定可能なこと。

12/46

G) スナップショット機能を有し、7 世代以上の保存が可能なこと。


A) 学外から直接アクセスできないこと。

B) ネットワークフォルダ、共有フォルダに対し適切なアクセス権を設定可能なこと。

C) 提案機器が汎用サーバの場合は、OS に対しウィルス対策を行うこと。なお、ウ






運用要件

A) アカウント登録/削除時に一括で個人用のネットワークドライブ用のフォルダ作

成/削除が行えること。

B) アカウント登録/削除時に一括でWeb メールの個人設定保存領域の作成/削除が行

えること。

C) 共有フォルダの管理(フォルダ作成/削除、アクセス権付与など)が行えること。

D) Active Directory と LDAP のユーザ/グループに対しユーザおよびグループ毎に

Disk Quota を設定でき、サービス停止なしで制限を変更可能なこと。

E) ディスクボリューム全体の容量をサービス停止なしで変更可能なこと。

F) SNMP に対応し、監視ソフトウェア等で死活監視可能なこと。

性能要件

A) 個人用ネットワークフォルダとして、学生は、2700 人規模の利用を想定し、1 人

500MB 以上の容量を割り当て可能なこと。

B) 個人用ネットワークフォルダとして、教職員は、500 人規模の利用を想定し、1

人１GB 以上の容量を割り当て可能なこと。

C) 学部の共有フォルダとして、全体で 70GB 以上割り当て可能なこと。

D) 教職員間の共有フォルダとして、全体で 100GB 以上割り当て可能なこと。

E) 入試担当間の共有フォルダとして、全体で 40GB 以上割り当て可能なこと。

13/46

F) 現行 Web メールサーバのWeb メールの個人設定保存領域全体で 50GB 以上割り

当て可能なこと。

G) スナップショットを 7 世代以上保存可能なこと。

H) 個人用ネットワークフォルダに、学生が 500 人以上同時にアクセスしてもパフォ

ーマンスに影響がでないこと。

I) 個人用ネットワークフォルダに、教職員が 50 人以上同時にアクセスしてもパフ

ォーマンスに影響がでないこと。

J) 各学部の共有フォルダに、50 人以上同時にアクセスしてもパフォーマンスに影響

がでないこと。

K) 教職員間の共有フォルダに、50 人以上同時にアクセスしてもパフォーマンスに影

響がでないこと。

L) 現行 Web メールサーバのWeb メールの個人設定保存領域に、50 人以上同時にア

クセスしてもパフォーマンスに影響がでないこと。

M) 個人用ネットワークフォルダ、各学部の共有フォルダ、教職員間の共有フォルダ、

Web メールの個人設定保存領域、入試担当間の共有フォルダに多重の同時アクセ

スがあってもパフォーマンスに影響がでないこと。





であること。




A) 現行の NAS 装置及び統合する現行ファイルサーバから、ユーザデータの移行を行

うこと。移行するデータについては本学からの指示に従うこと。また、移行に際

しては、元のファイルのアクセス権まで移行すること。

14/46

4.2.2 Unixユーザ用ファイルサーバ

機能要件

A) Linux/ Solaris へログインした際にユーザ個人の home 領域を提供可能なこと。

技術要件

A) Linux/ Solaris から NFS で接続が可能であること

B) LDAP 認証に対応していること。


A) ユーザが自分以外のユーザの個人用ネットワークフォルダにアクセスできないこ

と。

B) 提案機器が汎用サーバの場合は、OS に対しウィルス対策を行うこと。なお、ウ






運用要件

A) アカウント登録/削除時に一括で Unix ユーザ用 home ディレクトリの作成/削除が

行えること。

B) SNMP に対応し、監視ソフトウェア等で死活監視等可能なこと。

性能要件

A) 1400 人以上で利用可能とし、1 人 500MB 以上の容量を割り当て可能なこと。

B) クライアントから Unix ユーザ用ファイルサーバ上の NFS サービスへ、250 の同

時アクセスが発生した場合でも 10 秒以内に応答が可能な構成・性能とすること。

C) ユーザおよびグループ毎に Disk Quota を設定でき、サービス停止なしで制限を変

更可能なこと。

15/46





であること。




A) 現行の NAS 上のユーザ個人の home 領域の移行を行うこと。移行するデータにつ

いては本学からの指示に従うこと。移行に際しては、元のファイルのアクセス権

まで移行すること。

16/46

4.3 メールサービス

※現行の学内メール配送サーバ、メールスプールサーバ、Web メールサーバ

は継続利用することから、現行サーバを使用する提案とすること

4.3.1 学外向けメール配送

機能要件

A) 学内から学外へのメールを配送可能なこと。

B) 学外から学内へのメールを配送可能なこと。

技術要件

A) postfix と同等機能の smtp サーバソフトウェアを有すること。


A) オープンリレーを禁止すること。




アアンチウイルスが動作対象外の OS であれば、提案 OS で動作するウィルス対



運用要件

A) SNMP に対応し、監視ソフトウェア等で死活監視可能なこと。

性能要件

A) 750 人以上の利用に耐えられる性能を有すること。


A) プライマリとセカンダリの 2 台構成とし、プライマリかセカンダリのどちらかが

停止してもサービスを継続可能なこと。

17/46


C) ハードディスクを必要とする際は、機器単体の冗長化を図り、活性交換が可能で

あること。




A) 現行の設定情報を移行することが望ましいが、新規にメール配送を構築する場合

は、現行同等の配送を可能とすること。

4.3.2 MXフィルタ

機能要件

A) 学内から学外へのメールを配送可能なこと。

B) 学内から学内へのメールを配送可能なこと。

C) ソフト学部講座、情報システム管理者、メーリングリストにメールが配送可能な

こと。

技術要件

A) postfix と同等機能の smtp サーバソフトウェアを有すること。

B) 現行の学内メール配送サーバは LDAP 配送のみであることから、LDAP に登録さ

れていないメールアドレスを配送するための MX 配送を行うこと。


A) オープンリレーを禁止すること。







18/46

運用要件







であること。




A) 現行の設定情報を移行することが望ましいが、新規にメール配送を構築する場合

は、現行同等の配送を可能とすること。

4.3.3 負荷分散、SSLアクセラレータ

機能要件

A) 現行 Web メールサーバ 2 台の負荷分散を行うこと。

B) 現行 Web メールサーバの SSL 処理を行うこと。

C) 現行事務 Web サーバ 2 台の負荷分散を行うこと。

技術要件

A) SSL アクセラレーション機能を有すること。

B) LDAP、https、http 等アプリケーションレベルでのロードバランスが可能である

こと。

C) レイヤ 3,4,7 でのヘルスチェック機能を有すること。

D) 任意 VLAN に接続されたサーバに対しロードバランスが可能であること。

E) 配下のサーバに対し仮想アドレスを付与可能なこと。

19/46


A) 提案機器が汎用サーバの場合は、OS に対しウィルス対策を行うこと。なお、ウ






運用要件


B) Cisco 製スイッチとの接続の実績があること。

性能要件

A) クライアントからの 1,200 以上の同時アクセスを処理可能な性能を有すること。

B) 10 台以上のリアルサーバ、5 台以上のバーチャルサーバをサポート可能であるこ

と。


A) 2 台以上での冗長化構成としフェイルオーバが可能であること。


A) Web サーバの SSL サーバ証明書を登録すること。

B) 現行の負荷分散、ヘルスチェック等の設定を移行することが望ましい

4.3.4 スパムメール対策

機能要件

A) 学外からの SPAM、ウィルス等迷惑メールを遮断し学内への迷惑メールの流量を

減らすこと。

B) 学内からの SPAM、ウィルス等迷惑メールを遮断可能なことが望ましい。

20/46

技術要件

A) 複数の方法の迷惑メールフィルタリングをサポートし、それらが同時に行える機

能を有すること。

B) ブラックリストの SPAM メールのみ遮断し、ブラックリストに含まれない SPAM

メールは遮断せずにユーザへ配送可能であること。

C) 特定ドメインとの送受信はフィルタリングを行わない設定が可能であること。

D) サブドメイン単位でフィルタリング等のルールが設定可能であること。








運用要件


B) Web ベースの管理ツールを有すること。

性能要件

A) 750 人以上の利用に耐えられる性能を有すること。

B) 1 日 30 万通以上のメールを処理可能なこと。


A) ハードウェア障害およびサービス停止時に、メール配送が停止しないこと。


A) 現行のフィルタリング設定情報等を移行することが望ましい。

21/46

4.3.5 メーリングリスト

機能要件

A) システム管理者のみがメーリングリストを作成可能なこと。

B) メーリングリストの管理を個々のメーリングリスト管理者に委譲可能なこと。

C) Web による管理ツールを有し、管理ツールからメーリングリストの設定が行える

こと。

D) 学生、教員、職員、システム管理者がメーリングリストへメール送信可能なこと。

E) 学生、教員、職員、システム管理者がメーリングリストのメールを受信可能なこ

と。

技術要件

A) Web によるメーリングリストの管理機能を有すること。

B) コマンドによるメーリングリストの管理機能を有すること。

C) 添付可能なファイルサイズを設定可能なこと。

D) メーリングリストに対する SPAM メールをブロック可能なことが望ましい。


A) 他人のメーリングリストの設定ができないこと。

B) 学外から直接アクセスできないこと。







運用要件

A) メーリングリスト開設時の初期設定はシステム管理者が行えること。

B) メンバー変更やメーリングリストの設定変更は、メーリングリスト管理者が管理

ツールから行えること。

22/46

C) SNMP に対応し、監視ソフトウェア等で死活監視可能なこと。

性能要件

A) １時間に 1,000 通以上、１日に 6,000 通以上のメール配送が可能であること。

B) 利用者が 1,000 名以上の環境でメール配送するのに十分な性能を有すること。




であること。




A) 現行のメーリングリストの登録情報を移行すること。

B) 現行のメーリングリストサーバの設定情報を移行可能なことが望ましい。

23/46

4.4 DNS サービス

4.4.1 学外向け DNS

機能要件

A) インターネットから学外公開サーバの DNS 問い合わせを解決可能なこと。

B) 学内からインターネットへの DNS 問い合わせを解決可能なこと。

技術要件

A) bind9 と同等の機能を有する DNS サーバソフトウェアを有すること。








運用要件

A) グローバルアドレスを持つ情報システム管理のホストの情報を登録可能なこと。


性能要件

A) 問い合わせ処理性能が queryperf で 7,500 クエリ/秒以上であること。

B) 750 人以上の利用に耐えられる性能を有すること。


A) 上位 DNS の NS レコードによる冗長化を行うこと。

B) DNS の MX レコードによる冗長化を行うこと。

24/46

C) プライマリとセカンダリの 2 台構成とし、プライマリかセカンダリのどちらかが


D) 電源は機器単体の冗長化を図り、活性交換が可能であること。

E) ハードディスクを必要とする場合は、機器単体の冗長化を図り、活性交換が可能

であること。

F) 1000Base-T のネットワークインターフェースを 2 ポート以上有し、ネットワー



A) 現行の DNS 情報を移行すること。

4.4.2 学内向け DNS

機能要件

A) 学内ネットワークからの DNS 問い合わせを解決可能なこと。

技術要件



A) 学外から直接アクセスができないこと。







運用要件

A) ローカルアドレスを持つ情報システム管理のホストの情報を登録可能なこと。


25/46

性能要件







であること。




A) 現行の DNS 情報を移行すること。

4.4.3 事務 DNS

機能要件

A) 事務ネットワーク内のホストの DNS 解決が可能なこと。

B) 岩手県庁内のホストの DNS 解決が可能なこと。

技術要件



A) 学外から直接アクセスができないこと。

B) 事務ネットワーク以外からアクセスができないこと。




26/46




運用要件


性能要件





であること。




A) 現行の DNS 情報を移行可能なことが望ましい。

27/46

4.5 授業支援サービス

4.5.1 Windows

機能要件

A) 本学の 13 教室に対し、教室単位で使用できるネットワーク共有フォルダを提供

可能なこと。

B) 教室単位のネットワーク共有フォルダ内に任意のネットワーク共有フォルダを提

供可能なこと。

C) 授業用教材を Web で学内公開可能なこと。

D) Web 公開用フォルダへ FTP で書き込みが可能なこと。

技術要件

A) ネットワーク共有フォルダは、Windows 端末、Mac 端末から接続が可能であるこ

と。

B) Active Directory での認証が可能なこと。


A) ネットワーク共有フォルダに任意のアクセス権を付与可能なこと。

B) Web 公開フォルダへの FTP によるアクセスを制限可能なこと。








運用要件

A) ネットワーク共有フォルダの管理(フォルダ作成/削除、アクセス権付与など)が行

える。

28/46


性能要件

A) 教室単位のネットワーク共有フォルダに対し、ハードディスクの容量を 10GB 以

上割り当て可能なこと。

B) 100 人以上が同時にアクセスしてもパフォーマンスに影響がでないこと。




であること。




A) 現行 4 台の授業支援サーバのデータ、Web コンテンツを移行すること。

4.5.2 Unix

機能要件

A) Web ページを公開可能なこと。

B) DB を利用可能なこと。

C) CGI を利用可能なこと。

D) メールを配送可能なこと。

E) ゲストアカウントのメールを保存可能なこと。

F) NFS によりマウントできるディレクトリを提供可能なこと。

技術要件

A) Apache2.0 と同等の機能を有する http サーバソフトウェアを有すること。

29/46

B) postfix と同等の機能を有する smtp サーバソフトウェアを有すること。

C) UW-IMAP と同等の機能を有する POP3/IMAP4 サーバソフトウェアを有すること。

D) postgresql8.0.1 と同等の機能を有すること。

E) net-snmp と同等の機能を有するサーバ監視用ソフトウェアを有すること。

F) tcp-wrappers と同等の機能を有するアクセス制御ソフトウェアを有すること。

G) samba 3.5.7 と同等の機能を有するファイル共有ソフトウェアが動作すること。

H) php 4.3.10 と同等の機能を有すること。

I) perl 5.6.1 と同等の機能を有すること。


A) メールの送受信は、各教室の端末からのみ行うことが可能なこと。

B) Web ページは、ユーザが自分以外のユーザのファイルを編集できないこと。








運用要件


性能要件

A) 100 人以上が同時にアクセスしてもパフォーマンスに影響がでないこと。




であること。

30/46




A) 現行 2 台の授業支援サーバのデータ、Web コンテンツを移行すること。

B) ｢4.5.2 Unix <技術要件>｣記載のソフトウェアを、同等機能を有するソフトウェ

アとした場合は、既存データ、コンテンツが問題無く動作することの確認を取る

こと。

31/46

4.6 汎用サービス

4.6.1 全学 SPSS

機能要件

A) 本学が所有する、日本アイ・ビー・エム株式会社製ソフトウェア「SPSS」(以降

SPSS という)のソフトウェア配布用ネットワーク共有フォルダが提供可能なこ

と。

B) SPSS のライセンス管理が行えること。

技術要件

A) OS は Microsoft Windows Server2008 Standard Edition とすること。

B) Active Directory での認証が可能なこと。


A) ソフトウェア配布用ネットワーク共有フォルダにアクセス権を設定可能なこと。


C) ウィルス対策ソフトウェアとして本学所有のエフセキュア社製エフセキュアアン

チウイルスを使用すること。

運用要件

A) SPSS のライセンス管理ソフトウェアが利用可能なこと。


性能要件

A) 50 人以上が同時にアクセスしても遅延無く処理可能であること。

B) SPSS のライセンス管理ソフトが動作すること。

32/46




であること。




A) 本学所有の SPSS ライセンス管理用ソフトウェアをインストールすること。

B) SPSS 配布用のネットワーク共有フォルダ環境を構築し、現行同等のアクセス権

を設定すること。

4.6.2 多目的汎用

※現在、

1) 実習支援システム(OS: Windows 2000 Server)

2) 社会福祉学部 SPSS (OS:Windows Server 2003)

3) アンケートシステム(OS:Windows Server 2003)

がそれぞれ 1 台のサーバ(計 3 台)でサービスを提供している。これらのシステ

ムは、最新の OS に対応していないことや、今後もサービスを継続するか未確

定であることから、現状のまま使用を継続したいが、ハードウェアの老朽化や

保守が不可能状態であることから、P2V 等により現状のまま新しいハードウェ

アに載せ替えたいと考えている。

そこで、どのようにシステム構築するのが良いかを提案すること。

機能要件

A) 実習支援システム、社会福祉学部 SPSS、アンケートシステムの各サービスが提

供可能なこと。

技術要件

A) OS 及びシステムは現行のままとするが、ハードウェアは更新すること。

33/46


A) ウィルス対策ソフトウェアとして本学所有のエフセキュア社製エフセキュアアン


運用要件





であること。



34/46

4.7 管理サービス

※ 情報システムの運用における検証、監視、サポートを行うための環境。

4.7.1 Windows

機能要件

A) 情報システム管理者の Windows 端末認証用及び学内 Active Directory サーバへの

変更等の適用前の検証用として活用可能なこと。

B) 既存の情報端末、プリンタ等を管理するシステムを使用可能なこと。

C) 情報システム管理者のウィルス対策と学内ウィルス対策サーバへの変更等の適用

前の検証用として活用可能なこと。

D) 学内認証サーバへのユーザ登録で活用可能なこと。

技術要件

A) 学内同様の Active Directory 環境とすること。

B) 学内同様のウィルス対策環境とすること。


A) 管理用ネットワーク以外からアクセスできないこと。

B) ウィルス対策ソフトウェアとして本学所有のエフセキュア社製エフセキュアアン


運用要件


性能要件

A) 30 人以上が同時にアクセスしてもパフォーマンスに影響がでないこと。

35/46




であること。




A) 現行の設定情報を移行することが望ましいが、提案環境に合った環境とすること。

4.7.2 Unix

機能要件

A) 情報システム管理者及びベンダーとの情報共有、問い合わせ、障害対応依頼や機

器等の死活監視メールの受信で活用可能なこと。

B) 情報システム管理者が使用するサーバ等の名前解決及び学内 DNS への変更等の

適用前の検証用として活用可能なこと。

C) 学内情報システム説明 Web ページを学内公開する前に、事前に構築したり確認す

るために活用可能なこと。

D) 既存の情報端末、プリンタ等を管理するためのシステムが使用可能なことと。

E) 提供している業務毎の情報を管理し、求めに応じて作業単位での作業内容、調査

内容等の情報管理で活用可能なこと。

F) 機器、サービスの死活監視で活用可能なこと。

G) 過去のサポート関連や申請関連のサポート宛のメールを Web ブラウザから検索

可能とし、問い合わせ等への対応に活用可能なこと。

H) 作業計画、作業報告を管理するための現行システムで活用可能なこと。

I) ネットワークサービスの監視、サーバのリソース監視を行い、問題発生時にメー

ルによる通知を行うために活用可能なこと。

J) ネットワークの負荷を監視し、グラフによって可視化することにより、ネットワ

ーク異常時の問題箇所の特定等に活用可能なこと。

K) テスト用の OS 環境が構築可能なこと。

36/46

技術要件

A) Windows 端末、Mac 端末、Solaris、Linux から接続可能なネットワーク共有フォ

ルダを有すること。

B) メールサーバソフトは学内環境と同様のものであること。

C) DNS サーバソフトは学内環境と同様のものであること。

D) namazu と同等の機能を有する日本語全文検索ソフトウェアを有すること。

E) nagiosと同等の機能を有するネットワークサービス監視ソフトウェアを有するこ

と。

F) mrtg と同等の機能を有するネットワークトラフィック可視化ソフトウェアを有

すること。

G) テストを行うための一時環境を構築可能なこと。


A) 管理用ネットワーク以外からアクセスできないこと。

B) ウィルス対策ソフトウェアとして本学所有のエフセキュア社製エフセキュアアン


運用要件

A) 学内システムのサービス監視が可能なこと。

B) 学内システムの死活状態が監視可能なこと。

C) 障害時に管理者へメールで通知可能なこと。

D) SNMP に対応し、監視ソフトウェア等で死活監視可能なこと。

性能要件

A) ネットワーク共有フォルダは、合計 300GB 以上を割り当て可能なこと。

B) メールシステムは、30 名以上の利用に耐えられるものであること。

C) 機器、サービスの死活監視を常時行っていても、その他の動作に影響を与えない

こと。

37/46




であること。




A) 現行の設定情報を移行することが望ましいが、提案環境に合った環境とすること。

4.7.3 Syslog

機能要件

A) 学内システムのサーバ、ネットワーク機器のログを収集・保管可能なこと。

技術要件

A) ルーター、スイッチ、Linux サーバ、Windows サーバからログを収集、保存可能

なこと。


A) 保存しているログデータに管理者以外のユーザがアクセスできないこと。

B) 管理用ネットワーク以外からアクセスできないこと。







運用要件

A) ログ収集の対象は、ルーター、スイッチ、Windows サーバ、Linux サーバとする

こと。

38/46


性能要件

A) ログの保存領域として 300GB 以上を確保可能なこと。

B) 100 台以上の機器の Syslog の収集、管理が可能な性能を有すること。

C) ログの取得の際にサービスに影響が出ないこと。




であること。




A) 現行の Syslog データを移行すること。

4.7.4 NTP

機能要件

A) サーバ、端末の時刻同期が可能なこと。

技術要件

A) ntp を利用可能なこと。


A) 学外から直接アクセスできないこと。




39/46




運用要件





であること。



4.7.5 バックアップ

※バックアップ対象は本件で導入するサーバに加え、既設サーバ

1) Red Hat Enterprise Linux5.5 サーバ： 2 台

2) Windows Server 2003R2 サーバ： 8 台

も含むこと。なお、現行のメールスプールのバックアップは含まない。

機能要件

A) 学内システムのバックアップを一括で取得可能なこと。

B) システム稼働中でもバックアップが取得可能なこと。

C) 取得したバックアップデータを復元可能なこと。

技術要件

A) バックアップシステムが、バックアップ対象サーバのファイルシステムに対応し

ていること。

B) バックアップは D2D バックアップが望ましい。


A) 管理者以外がバックアップファイルにアクセスできないこと。

40/46








運用要件

A) ｢4.2.1 全学ファイルサーバ｣は 1 週間前の状態に戻せる世代管理を可能とするこ

と。

B) ｢4.2.1 全学ファイルサーバ｣以外は 2 世代以上管理を可能とすること。

C) ファイルやフォルダ、ディレクトリレベルでのバックアップ、リストアが可能で

あること。

D) バックアップ、リストアの操作が GUI から操作可能であること。また、コマンド

からのバックアップ、リストアが実行可能なこと。

E) バックアップスケジュールの作成が可能であること。

F) バックアップ中であってもバックアップ対象のサービスの提供が可能であること。

G) ネットワークを使用しバックアップ、リストアを行う場合は、既設のバックアッ

プ用 VLAN を使用する事が望ましい。

H) SNMP に対応し、監視ソフトウェア等で死活監視可能なこと。

性能要件

A) バックアップ取得時間は大学の業務時間に被らない以下の時間内で完了するこ

と。

1) 平日 22:00～(明朝)6:00

2) 土日祝 22:00～(明朝)8:00

B) 運用要件を満たすのに十分な性能を有すること。

C) リストアが極力短時間で行える事が望ましい。



41/46


であること。



4.7.6 KVM装置

サーバのコンソール操作は KVM 装置を使用し行う。

各サーバは、本学の用意する既存サーバの KVM スイッチアダプタを流用し既存の

KVM 装置への接続を行うことが望ましい。なお、既存の KVM スイッチアダプタは

PS2 接続のみであることから、キーボード、マウスが USB 接続の場合は、ラリタ

ン・ジャパン製 USB 用コンバーターAPSUSB を構成に含めること。

42/46

5.導入・撤去要件

※機器等の導入・撤去に関する要求要件である。

A) 導入および撤去については、本学の指示に従い協議のうえ行うこと。

B) 機器は、滝沢キャンパスメディアセンターA 棟サーバ室の既設 19 インチラックに搭

載すること。

C) 既存機器の撤去（取外しと学内指定場所への運搬）を行うこと。また、撤去機器の

データ削除も行い、削除の記録を本学へ提出すること。

D) 障害テストやバックアップ復元テスト等の各種テストを十分に行い、本システムが

正常に動作することを確認すること。またテストの記録は本学へ提出すること。

E) 各サーバのハードディスクの完全バックアップを行い、バックアップイメージが保

存された媒体を納品すること。

F) 本学が用意した一次側電源設備から各機器への配線は提案に含めること。なお、提

案の際は、一次側電源容量に考慮して提案すること。

G) 通信設備は既存のネットワークを使用すること。なお、既存ネットワークの設定変

更が発生する場合は提案に含めること。

H) 本学調達品の搬入および機器の設置等に際しては、本学の業務に支障を来さないよ

う配慮し、本学施設に損害を与えないよう十分注意すること。また、機器等の納入、

設置時には必ず立ち会うこと。

I) 本学が指示した管理番号シールを作成し、納入する機器への貼り付けを行うこと。

J) 設置に際して発生した段ボール等の梱包材、緩衝材、その他不要物の処分を行うこ

と。

43/46

6.ドキュメント要件

※提出を要求する成果ドキュメントの要求要件である。

A) 導入される全てのハードウェア・ソフトウェアに対する日本語または英語のマニュ

アルを、印刷物あるいは電子記録媒体にて各 1 部以上提供すること。マニュアルに

加えて、システムに関する構成、設定、設定値を記述したドキュメントを 1 部以上

提出すること。

B) ハードウェアおよびソフトウェアに付属する取扱い説明書とは別に、各システムの

運用手順，ならびに想定される障害状況ごとに障害検出・復旧処置・連絡手順など

を記載した障害対処のドキュメントを作成し、管理者研修会までに提出すること。

C) 納品ドキュメント

①設計書

②導入計画書（移行手順書含む）

③運用手順書

④マニュアル

⑤既存機器データ削除記録およびテスト記録

D) 上記に示した納品ドキュメント以外にも必要に応じたドキュメントの提出を求める

場合がある。

44/46

7.運用・保守・サポート要件

※ 運用・保守・サポート要件は全て必須の要求要件である。

7.1 体制

A) ハードウェアおよびソフトウェアの運用、保守、障害時の修復、サービスの復旧

などに対応可能な体制を契約終了まで維持すること。

B) 対応時間は、平日（国民の祝日に関する法律第 3 条に規定する休日及び 12 月

29 日から 1 月 3 日の年末年始を除く月曜から金曜）の午前 9 時から午後 5 時

とすること。

C) 障害発生時が対応時間内である場合は、障害発生の通知後 1 時間以内に本学で復

旧のための作業を開始できる体制を有すること。

D) 対応時間外であっても、連絡の取れる体制であること。

E) 対応窓口責任者を配置し、対応を一元的に管理し、各作業要員を統率して作業を

行う事。

F) 連絡窓口は一本化し、電話、FAX、および電子メールによる問い合わせに応じる

こと。

G) 導入する機器、システム、ソフトウェアの一部または全てを他社製品で満たして

いる場合でも、受注者が責任を持ってそれらの保守およびサポートを担うこと。

H) 対応窓口責任者、作業要員、連絡先等（対応時間内および対応時間外）を記載し

た資料を提出すること。

I) 安定した運用を維持するため、受注者と本学との間の定期的連絡・調整・協議体

として「システム定例会」を、原則として毎月、岩手県立大学を会場として開催

し、作業の履歴や内容等を報告すること。

J) システムを構成する機器に他社製品が含まれる場合には、必要に応じて当該製品

ベンダーの技術者を「システム定例会」に参加させること。

7.2 運用・保守作業

※環境を維持管理するための定型作業は本学のヘルプデスクが行う。

A) システムを維持するために必要な定型作業について、その内容、頻度、スケジュ

ール等について提案すること。

45/46

B) システム導入時には、定型作業手順の概要を本学へ提出すること。

C) システム稼働時には、定型作業についての具体的な手順書を本学へ提出すること。

7.3 障害対応

※障害発生時の一次切り分けは本学のヘルプデスクが行う。

A) 障害が発生した場合、速やかに応急措置および、ハードウェア、ソフトウェア、

サービスの復旧作業を行うこと。

B) 障害発生の事実を知った時点から起算して 1 時間以内に本学で初期対応を行う

こと。

C) 障害復旧に必要な情報や手順については、適時に本学へ提供すること。

D) 障害に対応する場合の、本学ヘルプデスクとの連携方法を提案すること。

E) 本学から指示があれば、ログ等の分析を行い、障害原因および対策についての報

告書を提出すること。

F) 現地で障害対応を行う場合の旅費や宿泊費等も、本提案に含み、別途請求するこ

となく対応すること。

7.4 サポート

A) 本システムを運用していく上で必要な情報の提供に努め、問い合わせ等には速や

かに対応すること。

B) システムの稼働トラブル、利用方法、改善等の技術的な問い合わせや調査依頼に

対応すること。

C) システムに影響を及ぼす可能性のあるセキュリティ情報は速やかに提供すること。

セキュリティホールが見つかった場合は本学へ速やかに連絡し、セキュリティパ

ッチの可否情報およびセキュリティパッチの提供も行うこと。

D) 現地でサポート等を行う場合の旅費や宿泊費等も、本提案に含み、別途請求する

ことなく対応すること。

46/46

7.5 保守費用

A) 以下の保守に伴う 6 年間の費用を本提案に含むこと

1) 機器故障に伴う部品調達と修理作業費

2) ソフトウェア保守（使用権、アップデート権、問い合わせ対応）

岩手県立大学サービスサーバシステム更新に係る …岩手県立大学...

Documents

Transcript of 岩手県立大学サービスサーバシステム更新に係る …岩手県立大学...

岩手県立大学 サービスサーバシステム 更新に係る …岩手県立大学...

Documents

Transcript of 岩手県立大学 サービスサーバシステム 更新に係る …岩手県立大学...

岩手県立大学サービスサーバシステム更新に係る …岩手県立大学...

Transcript of 岩手県立大学サービスサーバシステム更新に係る …岩手県立大学...