1．はじめに

大学における情報ネットワーク環境は教育・研究・教職員の日常的な事務処理や情報伝達への利用にとどまらず，学生の学修・就職や生活に関する支援，主に受験生を対象とした学外への情報発信など，あらゆる活動の基盤となるものである．近年ではポートフォリオやルーブリックといった学務情報の可視化要求や，サイバーセキュリティへの対策も必須となってきている．このように情報システムに対する要求項目は年々増加している．これらのサービスを安定的かつ継続的に提供するため，サービスを提供する機器，特にサーバ類は定期的な更改が必要である．一般的なサーバ機器のハードウェア保守期限が5年程度であることや，性能の陳腐化，サーバOSやソフトウェアのセキュリティ対策の必要性から5年程度でサーバシステムの更改を行う場合が多い．

一方，18歳人口は1992年の205万人をピークに年々減少しており，2015年には120万人である[1]．さらに国立大学の予算削減，私立大学助成金の抑制政策などにより，大学の予算規模は縮小しており，当然ながら情報システム関連予算も削減の傾向にある．

つまり大学の情報システムに対する要求項目は増加しているが予算は削減されつつあるという問題を抱えている．これはどの大学でも共通した問題であろうと思われる．情報システムの日常的な維持管理についてはある程度手法が確立すれば対応可能であるが，サーバシステムの更改を行う際には大きな問題となる．

京都女子大学（以下本学という）では2013年度から4年間にわたって学内に仮想化基盤を構築した．そしてこの仮想化基盤上に2005年度から運用してきた基幹サーバ群の移行を中心に，ほかの学内システムの移行や新たなサービスの構築を行ってきた．本稿では，この一連のシステムを導入した際の検討事項，システムの構成，運用状況などを例にして，サーバシステムを更改する際に検討すべき事項について得られた知見をまとめる．

2．サーバシステム更改における検討事項

ここでは，大学においてサーバシステムを更改する際に取り得る大まかな方針と，それを決定するために検討するべき事項について説明する．

2.1　システム更改の方針

サーバシステム更改においては次の2つの観点から大まかな方針を決定する．まずはサーバシステムの設置場所という観点から以下の2つに分類される．

• 学内　学内にサーバを設置して運用するオンプレミスと呼ばれる形態
• 学外　学外のデータセンタやクラウドを利用するアウトソーシングと呼ばれる形態

次に，個々のシステムの提供形態という観点から以下の2つに分類される．

• 物理　サービスごとに物理サーバを構築する形態
• 仮想　1台の物理サーバ上に複数の仮想化サーバを構築してサービス提供を行う形態

従来であれば学内のサーバルームに物理サーバをサービスごとに設置する「学内＋物理」の組合せがほとんどであった．しかし2010年ころから状況は変化してきている．

設置場所についてはクラウド技術の普及や災害対策を目的として，広島市立大学におけるクラウド環境を利用したネットワーク情報システムの更改[2]のように「学外」の形態を利用する例もみられる．特に2011年の東日本大震災以降，BCP (Business Continuity Plan，事業継続計画)の観点からも利用する大学が増えてきている．

提供形態についてはサーバ仮想化技術の進歩により，大阪大学[3]，北陸先端科学技術大学院大学[4]，武蔵大学[5]での仮想化基盤構築やプライベートクラウド構築のように「仮想」の手法をとる大学も増加してきている．

これらの組合せはサービスごとに選択することも可能であり，たとえば山梨大学でのGmail導入[6]はメールのみ「学外＋仮想」の組合せを採用した例である．

2.2　検討事項

前節で述べた方針のうちどの組合せで実現するかについては，大学ごとに異なるが，決定する際におおむね共通して検討すべき項目を以下に挙げる．
（1）予算規模
（2）構築工数
（3）更改後の体制

（1）については，大学の規模や構成する学部，国公立か私立かなどの要因で異なってくる．また，第1章で述べたようにどの大学においても予算規模が縮小傾向にあることは自明であるため，更改するシステムの絞り込みが必要になる場合がある．情報システムに対する設計思想や運用思想もさまざまであり，それが予算に反映されることもある．また，導入を検討しているシステムを何年先まで利用するかを含め，さらに次の更改時期やそのときの予算状況も考慮する必要がある．

（2）については，システム移行の際のサービス停止時間をできるだけ短くすべきである．そこで実際の構築作業に伴うさまざまな作業をあらかじめ見積もっておく必要がある．特にユーザデータの移行を伴う場合，その移行時間を十分考慮し，余裕を持ったスケジュールを組むことが望ましい．また，「学内」で構築する際にはサーバルームの空き状況・空調や電源設備も考慮する必要がある．

（3）については，サーバOSやソフトウェアが更改前と異なる場合，管理者が新しい環境下での運用を円滑に開始できるようトレーニング期間を設けることが必要な場合がある．これは管理者の技術レベルや導入しようとするOSやソフトウェアなどの導入実績をもとに検討する必要がある．特にアプライアンス製品などのWeb インタフェースは製品ごとに異なるため，なるべく単一の環境や操作性で管理できることが望ましい．また，使い勝手が大きく変化したり，ユーザ側での設定変更が必要になるサービスがある場合，ユーザへの周知や旧システムとの並行稼働期間をどの程度設けるかを検討する必要がある．

3．本学におけるサーバ更改に関する方針

ここでは，本学のサーバシステムについて，2013年度から4年間にわたるサーバ更改に至る簡単な経緯と，方針の決定方法について，第2章で挙げた方針，検討事項に則して説明する．

3.1　サーバシステム更改に至る経緯と問題点

本学の情報ネットワーク環境は，2000年度のKWIINS（Kyoto Women's university Integrated Information Network System）と呼ばれる全学的な情報システムの整備に始まった．その後2005年度にサーバ群の更改[7]，2007年度にネットワーク機器群の更新[8]，2010年度にコンピュータ教室のNetBoot化[9]と数年ごとに機器の更改を繰り返して環境整備を行ってきた．

Web，DNS (Domain Name Service)，メール，認証などの情報システムの基幹となるサービスについては2005年に導入されたMac OS X Serverによるサーバ群で長らく運用してきた．しかしながら運用開始から10年近く経過し，保守部品の供給やOSの更改，保守が終了してからハードウェア故障やソフトウェアに問題が発生した際の対応が非常に困難な状況が続いていた．実際に2012年以降，メモリや電源ユニットの不良によるサービス停止が頻発し，そのたびにサーバの再起動や予備機の部品を利用するなどして辛うじてサービスを維持してきた状況であった．また，当然ながら消費電力・発熱量が現行の機器に比べて大きいという問題点も抱えていた．

また，教務系のデータベースや履修登録システム，学習管理システム，教員の業績管理データベースなど，学内の各部署が提供するサービスのためのサーバが毎年のようにサーバルームに設置されており，2012年8月の時点では図1に示すような構成となっていた．これらのサーバは全学の情報システムを管理している情報システムセンターですら詳細を把握できないままに導入・設置されることも少なくなかった．そのためサーバルームの空きスペースや消費電力，空調の管理，システムごとにアクセス方法が異なるなど，情報システムの維持・管理の面で不安視される要素が増加してきていた．さらに，これらのサーバの実質的な運用に携わっているのは業務委託のSE3名と教員2名のみであり，物理サーバの増加は管理上の大きな負担となっていた．

そこで，以下の3点を解決すべき課題としてサーバシステム更改に取り組んだ．

• （1）安定したサービス提供を継続するため，既存のMacOS X Serverサーバ機器の更改
• （2）逼迫するサーバルームの整理
• （3）サーバ管理運営を円滑に行うため，サーバ監視や異常通知方法の一元化やサーバへのアクセス方法の簡素化

3.2　方針決定のための検討

前節で述べた問題点を解決するために，2.1節で挙げたどの方針が適切であるかを2.2 節で述べた検討事項に基づいて検討した．

まず「予算規模」を把握するため，更改対象となるサーバすべてを「学内＋物理」，「学外＋仮想」，「学内＋仮想」の3 つの方針で更改した場合を想定し試算した．するとどの組合せもほぼ同じくらいの費用がかかることが判明した．同時に，本学の情報システム関連予算の規模では，単年度ですべてのサーバ更改は困難であることも判明した．

次に，「学内」と「学外」どちらの方針にするかを検討した．「学外」の方針を選択した場合，サーバの物理的な存在位置や問題が発生した際にどの国の法律に従うかなどといった学外に設置されていることに起因する問題を解決する必要がある．しかしこれらの問題について学内で意思決定がされていなかった．また，この更改の検討を始めた2012年の時点ではシステムすべてを「学外」の方針で更改した他大学の事例はほとんどなかった．前例がないシステムの導入は，導入したこと自体が対外的なアピールになる．そのため，たとえば工学系の学部・研究科がある大学では積極的に取り入れるところもあるが，予期せぬバグやトラブルが起きる可能性もある．円滑なサーバ運営を更改の目標としていたため，「管理後の体制」の観点では「学外」の方針は不安が大きかった．これらの理由により「学内」の方針で更改することが適切であると判断した．

「物理」と「仮想」の方針については，今回の更改で解決すべき問題の1つとしてサーバルームの整理が挙げられていた．この問題を解決するにはサーバ自体の数を減らす必要がある．また，サーバルームの空きスペースがほとんどなかったため「構築工数」の観点からも「仮想」の方針によりサーバの絶対数を減らすことが適切であると判断した．

結論として，今回の更改は「学内＋仮想」を基本方針とした．ただし，予算の観点から単年度ではなく，複数年度で段階的に更改することにした．段階的に行う順序はハードウェア保守期限を迎える時期やユーザのデータの安全性確保を考慮して決定した．具体的な計画は以下のとおりである．

第0段階（2013年度）の計画は，ユーザのデータを保管しており，故障などで停止してしまうとデータが失われたり代替機の準備を待つ余裕がないサーバを対象として更改した．これらを収容するための最小限の仮想化基盤を構築して移行することとした．

第1段階（2015年度）の計画としては，仮想化基盤を構築して2005年に導入したMac OS X Serverで提供しているサービスの仮想化によるサーバ更改を中心に行うこととした．また，同じく2005年度に導入されたファイアウォールやロードバランサなどのアプライアンス製品も老朽化してきたことから，可能なものについては仮想化して基盤上に構築することとした．これにより，物理サーバとストレージなど合計20数台にわたる機器（19インチラックで約4本分）を集約し，省スペース化と省電力化を目指した．

第2段階（2016年度）の計画は，第1段階で構築した仮想化基盤上に学生や教職員に関する情報，シラバスなどの教務関連情報，学生指導や就職活動に関する情報などを一元管理するための統合データベースやそれを利用したポートフォリオシステムの構築，図書館システムの更改を行うこととした．そのため，第1段階における仮想化基盤はこれらのシステムが受け入れ可能なように拡張可能な仕様とした．また，基幹ネットワーク機器の更改や無線LAN環境の全学への拡充を行うこととした．

以降，第0，第1段階で実施したサーバ更改について第4章で移行を検討したサービス，第5章で導入したハードウェアおよびソフトウェアや導入スケジュールについてそれぞれ詳しく説明する．

4．仮想化基盤上に構築したシステムおよびサービス

ここでは今回の導入で更改対象となった機器とサービスについて述べる．図1に仮想化基盤導入前の本学の基幹サーバ群の構成図を示す．LMS（Learning Management System），語学学習Web，sastik^☆1の3 サービスがLinuxサーバで，教務システムWeb，Windows Netboot，Windows AD（Active Directory），授業収録，プリント課金，ウイルス対策，教員業績Webの各サービスはWindowsサーバで，その他のサービスはMac OS X Serverで提供している．

4.1　第0段階で移行したサービス

第0段階では，3.2節で述べたように故障などにより停止してしまうとデータが失われたり，代替機の準備を待つ余裕がないものである．以下のサービスが対象となった．

ファイルサーバ

本学では情報教育関連科目の授業や学生の自習のためのコンピュータ教室を10室提供している．1教室のクライアント数は60台であり，9教室がWindows，残り1教室がMac OS Xである．ファイルサーバはこれらコンピュータ教室におけるユーザのホームフォルダを提供するものである．1人あたり1GBのフォルダを約6,000人分提供している．

認証サーバ

Open Directoryを用いた認証サーバで，ユーザのパスワードや，コンピュータ教室のドメイン認証などを行っている．3台のサーバをロードバランサにより負荷分散して運用していた．

外部メールサーバ

学外からのメールを受信するSMTPサーバである．学外からのメールはこのサーバからDAOUTECH 社のSpamWatcherによるスパム・ウイルスチェックを経て内部メールサーバに送信される．

内部メールサーバ

ユーザがメール送受信に使用するSMTP，POP3，IMAPサーバおよびメールスプールを提供している．学外からのメール利用は後述するSSL-VPN^☆2による利用とし，学外ネットワークからは直接アクセスできないようにしている．

4.2　第1段階で移行を検討したサービス

第1段階の計画では，Mac OS X Serverの置き換えを中心にハードウェア保守期限が超過している機器やサービスについて仮想化基盤上への移行を検討した．

4.2.1　Mac OS X Server

Mac OS X Serverで提供しているサービスについては次のとおりとした．

Active!mailサーバ

TransWARE社（現QUALITIA）のActive!mail2003によるWebメールシステムを提供しているが，サポートが終了していたため更改の必要があった．Gmailを利用した山梨大学[6]や岡山大学[10]など，多くの大学で導入されているクラウドメールシステムへの移行や学内で別のWebメールシステムの導入を検討した．しかし別サービスの選定には至らず，2016年9月にWebメールのサービスを終了し，その後はユーザが各自のメールクライアントを用いてメールの送受信を行うこととした．

その際，学内ネットワークに加えて学外ネットワークからもメールの送受信が可能になるようサービス拡充を行った．セキュリティレベル向上や，スマートフォンの標準メールクライアントへ対応するため，メールサーバとの通信をSSL/TLS により暗号化したSMTPs（s はover SSL/TLSを指す，以下同様），POP3s，IMAP4sによるメールサーバを構築することとした^☆3．

DHCP（Dynamic Host Conguration Protocol）・RADIUS（Remote Authentication Dial In User Service），内部DNS・学内Web，外部DNSサーバ

これらのサービスは引き続き提供が必要なため，仮想化基盤上へ移行することとした．

また，本学の公式Webサーバは2015年春に学外のクラウドサービスへ移行したが，一部のコンテンツをリバースプロキシにより学内Webサーバで公開していた．これらのコンテンツについても学外への移行を検討したが，コンテンツの量が少ないことや，移行後の運用コストや移行作業にかかるコストを考慮して，引き続きリバースプロキシにより仮想化基盤上で提供することになった．

Webプロキシサーバ

Webプロキシサーバは主にコンピュータ教室の端末で利用していた．しかし，2010年に教室端末を更改した後は利用されておらず，ほかの学内ユーザからもほぼ利用されていないと思われるため，廃止することとした．

ライセンスサーバ

コンピュータ教室のうち，Mac教室で提供しているソフトウェアVectorworksのライセンスサーバが稼働していた．この機能は，2011年度にコンピュータ教室のMac教室をNetBoot化した際に導入したMac miniサーバへ移行することとした．

Mac OS X管理サーバ

Mac OS X Server群を管理するために2台のサーバを運用していたが，移行対象とはせず，廃止することとした．

バックアップサーバ

第1段階で導入する仮想基盤上にバックアップを取得する機能があるため廃止とした．

4.2.2　Windows サーバおよびアプライアンス機器

Windowsサーバおよびアプライアンス機器のうち，仮想化基盤上へ移行することになったものは以下のとおりである．

プリント課金サーバ

コンピュータ教室での印刷枚数をカウントするプリントサーバ（Fuji Xerox社DocuHouse）である．OS がWindows Server 2003であり，OS保守期限を迎えるため移行対象とした．

ロードバランサ

F5社BIG-IP1500 で，3台のLDAP(認証) サーバ，2台のプロキシサーバ，4台のWebメールサーバを負荷分散していた．サーバを仮想化基盤上に構築した後も必要となるが，保守期限を迎えていたため後継機種に移行することにした．

SSL-VPN サーバ

F5社FirePass4100で，学外からの学内限定WebへのトンネルサービスおよびVPN接続を提供していた．同時接続数100という制限があり，ユーザからは改善の要望が挙がっていた．そこで，同時接続数に制限のない後継機種へ移行することとした．

高中小FW（ファイアウォール）

本学は学校法人京都女子学園が経営しており，学園は大学のほかに京都女子大学附属小学校，京都女子中学・高等学校，京都幼稚園を経営している．

本学の情報システムセンターは，大学のネットワークのみならず上記の各学校の情報システムの運用管理も行っている．中学・高等学校および附属小学校のネットワークは大学のネットワークを経由してインターネットへ接続されており，このファイアウォールにより通信を制限している．Juniper社Netscreen-25を設置していた．

5．導入システムの概要

5.1　仮想化基盤ハードウェア

ここではまず，一連の仮想化基盤構築において導入したハードウェアについて説明する．検討時においてプライベートクラウドによる仮想化の導入実績が多かったCisco Systems社のUCSとVMwareの組合せにより実現した[11][12]．図2に導入した仮想化基盤とその周辺の物理ネットワーク構成を示す．

5.1.1　第0段階導入ハードウェア

2013年に導入した第0段階の導入では，Cisco Systems社UCS C220 M3（CPU：Xeon E5-2690x2 (16 コア)，メモリ128GB）2台で構成した．仮想化のハイパーバイザにはVMWare社vSphere ver5.1を採用した．ストレージはNetApp社のFAS2220Aを用いて構築し，その実効容量は8.4TBである．

5.1.2　第1段階導入ハードウェア

2015年に導入した仮想化基盤にはCisco Systems社UCS5108ブレードサーバシャーシにブレードサーバUCSB200 M3サーバを4台設置した構成とし，仮想化のハイパーバイザにはVMware社vSphere ver6.0を採用した．ストレージにはNetApp社FAS8020 を採用し，実効容量は30TBである．

これらの機器をCisco Systems 社Nexus3524×2台の冗長構成の下に接続し，そこから既存のコアスイッチ（Cisco Systems 社Catalyst6504×2）に接続した．仮想化基盤およびストレージとNexus3524の間はそれぞれ10GB-SX×4，10GB-SX×2で接続しており，Nexus3524と既存のコアスイッチの間は1GB-SXで接続している．また，Cisco Systems社Catalyst2960×2台の冗長構成とし，第0段階で導入した仮想化基盤を収容することとした．

5.2　構築した仮想サーバ

次に，構築した仮想化サーバ類について説明する．図3に仮想化基盤導入後のサーバ構成図を，表1に構築した仮想サーバに割り当てたリソースの一覧を示す．

5.2.1　旧環境から移行したサービス

まず，旧環境から移行したサーバについて説明する．旧環境でMac OS X Serverで運用していたサービスのサーバOSについては次のように決定した．2.2節の（3）で述べた更改後の体制を考えると，サーバOSは変更しないほうがよいが，Mac OS X Serverは仮想化のゲストOSに対応していない．そこで同じUNIX系のOSであるRHEL（RedHatEnterprise Linux）とCentOSを検討した．費用の問題や，本学のサーバ管理者がUNIX系OSに精通していることから，CentOSを採用した．vCPUは2coreで共通であるが，メモリはサーバの用途により2GBもしくは4GBを割り当てている．ストレージについてもサーバの用途により80GB〜2TB を割り当てており，特にファイルサーバ・内部メールサーバについては旧環境での使用状況から見積もって割り当てている．

アプライアンス機器については負荷分散装置にはF5社のLocal Traffic Managrer Virtual Edition，SSL-VPN装置には同時接続数に制限のないFortinet社のFortiGate-VM01，高中小FWにはFortinet社のFortiGate-VM02を導入した．なお，仮想化基盤内にファイアウォールを設置することになるため，コアスイッチおよび仮想化基盤を収容しているスイッチに高中小ネットワークのVLAN（Virtual LAN）を設定している．また，プリント課金サーバはWindows2012 Serverの仮想サーバとして構築した．

なお，第1段階の構築時に第0段階時に構築した内部メールサーバをVMware vSphereのライブマイグレーション機能を用いて移行した．これは第0段階で導入したストレージの実行容量が8.4TBであり，ファイルサーバとメールスプールで80%を使用していたためである．また，メールサービスについては4.2.1項で述べたようにWebメールの終了に対応するため，SMTPs，POP3s，IMAP4sサーバの設定を行った．

5.2.2　新規に構築したサービス

ここでは，仮想化基盤構築に併せて新たに構築したサービスについて説明する．

科研費Webサーバ

第0段階の構築時に科学研究費補助金管理システム“科研費プロ”サーバをWindows 2012 Server上に構築した．

監視サーバ

第1段階の構築時に各種サーバやネットワーク機器の監視，異常発生時の通知やネットワーク機器のログを集約するサーバとしてCentOS7上でzabbix[13]による可視化を行っている．

統合データベースなどのサーバ

第1段階では，第2段階で導入する学生データ統合データベースと，それを利用したポートフォリオシステムのためのサーバとして，RHEL7の仮想サーバを合計7台構築した．

認証サーバ

第1段階では以下のような背景から認証システムについて検討し，学内利用者への新規サービスとして新たに認証サーバを構築した．まず既存の認証方式と問題点について 無線LANと有線LANに分けて説明する．

無線LAN

無線LANは2011年度よりAruba Networks（以下，Aruba社．現在はHewlett Packard Enterprise）のアクセスポイントとコントローラにより提供されている．校舎の新築や建て替え，耐震工事に合わせて順次無線基地局が整備されてきている．2015年夏の時点では約150台のアクセスポイントが稼働している．ユーザ認証にはAruba社のコントローラによるWeb認証システムを用いており，利用者数も増加してきている[14]．

しかし，学生からスマートフォンやタブレット端末を利用して無線LANを利用する際，利用のたびに認証作業を行うのは面倒である，という不満の声が挙がっていた．また，今後無線LAN設備がない校舎や学生寮への提供エリア拡充や，先に述べたポートフォリオシステムの導入も予定しており，学生が無線LANに手軽にアクセスできる環境整備が必要であった．

有線LAN

有線LANについてはRADIUSによるMACアドレス認証^☆4とWeb認証を併用している．このWeb認証は認証ページへリダイレクトされるのではなく，利用者自身がhttp://1.1.1.1/にアクセスして認証するもので，利用者から不満の声が挙がっていた．

また，無線と有線に共通して，学会などで訪れたゲストユーザに対する一時アカウントについての問題があった．現在は一時アカウントの発行は可能であるが，学内ユーザが認証を肩代わりして利用している場合が多い．そのため，ゲストユーザにより手軽にネットワークを利用してもらえるようにしたいとの要望もあった．

これらを考慮して認証サーバに対する要求項目は以下の通りとし，日立電線ネットワークス社のAccount@Adapter+を導入することとなった．

• （1）IEEE802.1Xに対応した認証機能を有すること
• （2）RADIUS Proxyを使用してeduroam環境[15]が利用可能であること
• （3）学生数が約6,000名，教職員が約500名であることから，約7,000名が認証可能であること．また，ゲストユーザの利用を想定して1日平均10,000デバイスが認証可能であること
• （4）学内のLDAP サーバと連携して，学内外における認証機能が提供可能であること

その結果有線・無線はそれぞれ次のような認証環境となった．

無線LAN

無線LANには表2に示す4つのSSID^☆5を追加した．この結果，学内ユーザ向けの認証としてこれまでのWeb 認証に加えてIEEE802.1XとMACアドレス認証が追加された．MACアドレス認証は無線対応のプリンタなど，PC以外の機器の利用に使用することとした．ゲストユーザ用のSSIDにより，ネットワーク管理者の作業なしに一時利用が可能となった．しかし，利用手続きや規定などについての詳細が決まっていないため，運用は開始してない．また，既存のWeb認証は時期を見て運用を停止する予定である．

有線LAN

本学の各建物のフロアスイッチは日立電線ネットワークス社（現，APRESIA Systems（株））のApresiaシリーズで統一されている．しかし導入時期が異なるため同一ポートで複数の認証方式が設定できる機種とそうではない機種が混在している．そこでまず，接続先の端末および情報コンセントの種類に応じた適切な認証方式を検討した．その結果表3のようになったため，各端末が接続されているスイッチおよびポートを調査して，表3を満たすようにフロアスイッチの移設や設定変更を行った．

5.3　導入スケジュール

第0段階の構築は予算措置の都合上2013年度中にサービスが開始できるような日程を組む必要があった．ファイルサーバおよびメールスプールを移行するため，サービス停止を伴う更改作業となった．そのため，工事日程としては夏季休業期間か年度末が候補となったが，年度末は入試と合格発表，新入生の受け入れ準備と退職者のアカウント整理などがあり，サービス停止を伴う更改作業は困難と思われた．さらにデータ移行にかかる時間を見積もったところ，少なくとも24時間はかかると思われた．2.2節の（2）でも述べたようにサービス停止時間をなるべく短くするため，夏季休業期間とシルバーウィークにサービス停止を伴う更改作業を予定し，そこから逆算して日程を組んだ．

実際には2012年10月から更改対象のサーバの絞り込みと第1段階以降の更改計画についての検討を開始した．2013年5月までに詳細仕様書の策定と入札，2013年6月に業者を決定し，夏季休業期間までの2カ月で詳細設計な設計打合せを行った．2013年9月上旬の週末およびシルバーウィークに仮想化基盤の機器搬入とデータの移行を行った．

第1段階の構築についても同様に2015年の夏季休業期間に構築作業を行うため，2014年10月から更改対象となるサーバの選択と第2段階で予定されている新規システムの規模の見積もりの開始，2015年3月に基本的なプランの決定と基本仕様書の作成，2015年5月に詳細仕様書の策定と入札を行い，2015年6月に業者を決定した．そして2015年8月のお盆期間中にラックを設置した．また，電源容量の不足も予想されたため，同時に電源の増設工事も行った．2015年8月末から9月にかけて認証サーバ導入のためのフロアスイッチ移設を行い，仮想化基盤の機器搬入とネットワーク切り替え作業は2015年9月のシルバーウィークに実施した． その後メールサービスについては2016年1月から9月までの約半年をかけてActive!mailによるWebメールから各自のクライアントを利用する環境へと移行した[16]．

6．構築した仮想化基盤に関する評価

ここでは，構築した仮想化基盤が当初の目的をどの程度達成できたかについて述べる．

まず，3.1節でまとめた課題の1つ目であるMax OS X Serverなど保守期限を迎えたハードウェアについてはすべて運用を終了することができ，これについては目標を完全に達成できたといえる．次に，課題の2つ目であったサーバルームの空きスペースについては，物理サーバの仮想化による集約で，19インチラック5台ほどのサーバ類をラック2台に集約することができた．

また，3つ目の課題として挙げたサーバ管理運用の面については，仮想化の利点を生かして大幅に改善された．たとえば毎年行われる法定点検による停電時，これまでは30台以上の物理サーバすべてについて1台ずつKVMスイッチ^☆6で切り替えながらシャットダウンや再起動の確認を行っていたため，作業に数時間を要していた．しかし仮想サーバの管理コンソールから一括でシャットダウンや再起動が可能となり，この作業が数十分で完了できるようになった．

一連の更改前には統一したサーバ管理システムは導入しておらず，トラブル報告のたびに管理者がログの集計を行うなどで対応していた．そこで今回の更改でサーバ監視用の仮想サーバを構築し，zabbixによる監視を行っている．しかし，管理者のzabbixに関する知識が十分ではなく，監視や通知のためのパラメータを試行錯誤して設定している状況である．これは今後適切な設定ができるよう，管理者のトレーニングが必要である．

7．おわりに

本稿では，大学のサーバシステム更改を行う際に取り得る方向性と，それを決定するための検討事項を整理した．そして実践例として京都女子大学で2012年から行ってきたサーバ仮想化基盤構築の計画の決定プロセスや2013，2015年度に行った具体的な構築作業の工程について述べた．本文で詳細は触れていないが2016年度に行った構築作業と合わせた一連の仮想化基盤構築導入により，2005年から稼働してきた30数台のMax OS X Server，数台のアプライアンス機器と10数台のWindowsサーバの運用を終了できた．

今後は新規サービスを構築する際の仮想化基盤利用規定の整備，一部のサービスを「学外」での運用に切り替える可能性の検討を行う予定である．サーバの仮想化によりトラフィック集中が予想される基幹ネットワークの機器を更改し，より広帯域への対応も予定している．また，災害対策として2つの仮想化基盤の片方をバックアップサーバとして「学外」に設置することも検討している．

一方，仮想化による集約をした結果，仮想化基盤の故障時の影響が大きくなってしまっている．そのため，将来的には第0段階と第1段階で導入した2つの仮想化基盤を増強し，故障時には負荷に余裕があるサーバ上でサービスを継続させることも検討が必要と思われる．

サーバシステム運用形態が学内から学外へ過渡期にある現在，本学における実践例がサーバシステムの仮想化やクラウドサービス利用に関する検討の一助となることを期待する．