![[PukiWiki]](/MuseWiki/wiki_baner.png "[PukiWiki]")
#author("2017-11-30T10:26:20+00:00","","") #author("2017-11-30T10:28:37+00:00","","") *サーバ環境 [#ff720e00] -富士通 PRIMERGY TX1310 M3 HYPER-V仮想環境にて使用 --CPU:Xeon E3-1225v6(2C割り当て) --Mem:6GB(割り当て) --HDD:100GB+200GB+100GB(割り当て) #ref(DSC_0198 1.jpg,,TX1310M3) *旧サーバ環境 [#efbb91ce] -DELL PowerEgde T110 --CPU:CeleronG1101(2.27GHz/2C) --Mem:4GB --HDD:320GB+4TB+2TB+3TB #ref(DSC_0022 1.jpg,,PowerEgde T110) -WindowsServer2008R2Foundation --IIS7.5 *ネットワーク環境 [#d4f43f04] thn光200Mbps契約 東京-静岡間にRTX810とFWX120の間でIPsec-VPNあり。VPNでの実効転送速度約50Mbps #ref(DSC_0004 1.jpg,,FWX120) FWX120(静岡サイド) #ref(DSC_0100 1.jpg,,RTX810) RTX810(東京サイド) MuseWikiを支えるルータはYAMAHA製♪ *バックアップについて [#qafc7734] 毎日0時にIPsec-VPN経由で東京に差分バックアップを実施。 #ref(SNAG-000180.jpg) *SSL/TLS通信について [#eee5fccf] 昨今の、Web環境を鑑み、SSL/TLS通信を必須とするようにしている。&br; すでに、GoogleChromeにおいては非暗号化通信は非推奨のステータスにある。&br; また、今後の課題としてあげているサーバの更新をしたときにはHTTP/2による通信が行われるようになりこれまで、HTTP/1.1ではTCPセッションが2つまでしか張られなかったものが格段に多いセッション数で同時並行的に画像などがダウンロードされ結果的に高速化に寄与するものと思われる。&br; また、暗号化通信する際に考慮すべき点はサーバへの負荷だが、現在のアクセス数では同時アクセスされることはほぼなく影響は軽微と考えられる。 #ref(SNAG-000227.jpg) SSL/TLS通信に必要なサーバ証明書はLet's Encryptのものを使用している。&br; 有効期間が3ヶ月と短いので頻繁な更新が必要な反面、無償で使うことができる。&br; &br; 運用をしくじったらすみません。&br; #ref(SNAG-000228.jpg) musewiki.dip.jpドメインの他、予備としてtomokusaba.aa0.netvolante.jpでもアクセス可能。&br; musewiki.dip.jpドメインはサーバ側でDDNS更新&br; tomokusaba.aa0.netvolante.jpドメインはルータ(FWX120)でDDNS更新している。&br; *今後の課題 [#ec3ccaf3] -PHPのアップデート&br; →そのためにはPukiWikiのバージョンアップが必要&br; →そのためにはデータコンバートが必要&br; →そのためには一時サービス停止が必要かな？ pukiwikiを1.5.1に更新。&br; PHPを5.6.30に更新。&br; 2017/2/26 -サーバの更新&br; 現状のサーバの運用は5年を超えておりそろそろサーバの更新を検討すべき時期。&br; WindowsServer2008R2のサポート期限は2020年1月まで。WindowsServer2016への更新を検討したい。&br; -まれに再起動時にBIOS起動に失敗する&br; そもそも、サーバ機はBIOS起動に非常に時間がかかる。基本的に再起動がない運用にしたい。&br; しかし、Windowsには月一程度の再起動はつきもの。&br; 対策としてはESXiなどで仮想化した上に、WindowsServerを構築する。&br; ESXiならホスト側の設定はSSH等で可能。ある程度はiDRACやiLO等のハードウエアのGUIコンソールの代わりにもなる。 #ref(SNAG-000224.jpg) -添付ファイルの多いページの表示が遅い ページ表示時のMD5とMIMEのルーチンをコメントアウトして改善された。あとは、サーバ更新かな？（ぱわーーー） *新サーバ設計 [#w7ff602b] #ref(SNAG-0004.png) **ストレージ設計 [#s174b85f] バックアップ運用を考えたとき、システムバックアップの容易さを考慮しhyper-vの採用を決めた。&br; ディスク障害について以下のような方針を定めた。 +ディスク1本の障害についてはデータを失わないor障害発生時点から1日以内の状態に復帰できるようにすること。 +ダウンタイムはやむを得ない ++ディスク交換までのダウンタイムを許容しないと、エントリークラスのサーバでは内蔵できるディスク本数が足りない。ミッドレンジ以上は、電力的にもお財布的にも許容しがたい。 というわけで、おおよそ、次のような構成を考えている。 |容量|内容|h |500GB*1(RAID0)|物理OS起動ディスク| |4TB*2(RAID1)|仮想OSディスク領域| |4TB*1(RAID0)|仮想OSバックアップ領域| させるディスクは4本まで。 このうち、物理OS起動ディスクに障害発生時にはディスク入れ替えのちにOSインストール作業が発生する。よって、長期ダウンとなるケース。 これ以外の、ディスク障害が起きても1本であればデータを失うこともないし、運用が止まることがない。 物理OS起動ディスクをRAID1とすることも検討したがその場合仮想OSバックアップ領域をUSBHDDとしなければならない。この場合は、WindowsServerBackupの単発バックアップのスクリプトをタスクスケジューラに組み込むことになるが、最大4TBのバックアップが毎日走るなどということはしたくない。リムーバブルディスク扱いのディスクは差分のバックアップが取れないので最大優先度のバックアップという点で損なわれてしまう。 ***物理サーバ [#c0818a59] |ドライブ|容量|ファイルシステム|内容|h |C|500GB|NTFS|システムドライブ| |D|4TB|ReFS|仮想ディスク領域| |E|4TB|NTFS|バックアップ領域| 物理サーバのドライブ割り当てとしては、LUNそのままの割り当てとしている。 特筆すべきなのは仮想ディスク領域として新しいファイルシステムであるReFSを採用予定としている。仮想ディスクと相性がよくパフォーマンスが出やすいとのことですのでReFSとしました。バックアップ領域に関してはReFSも検討したのですが、重複排除がいまのところNTFSのみの機能になっているのでNTFSのほうが良いと判断しました。 ***Webサーバ [#rd53dfb3] もっとも重要なMuseWikiを担うWebサーバ部分です。 |ドライブ|容量|ファイルシステム|内容|h |C|100GB|NTFS|システムドライブ| |D|200GB|NTFS|IISコンテンツ| |E|100GB|NTFS|Perl,PHP,DDNSツールなどプログラム領域,IISログなど| バックアップに関しては物理サーバの方からWindowsServerBackupを毎晩実施する予定。これとは別にIISコンテンツに関してはファイル単位でミラーリングにて遠隔バックアップを実施。 ***ファイルサーバ [#x6d63420] |ドライブ|容量|ファイルシステム|内容|h |C|100GB|NTFS|システムドライブ| |D|3TB|NTFS|ファイルサーバ| 非公開のファイルサーバです。 **CPU [#z02fa998] 4Core/3GHz以上 Xeon E3を想定 **メモリ [#b31e1b65] 16GB以上。 うち、Webサーバへの割り当ては6GB *経過報告 [#wb36544a] **2017/10/14 [#m93a54f3] サーバー発注しました。 スペックは下記の通りです。 -富士通 PRIMERGY TX1310 M3 -CPU XEON E3-1225v6(3.3GHz) -メモリ PC4-19200 ECC 16GB -HDD 4TB SATA×2 -WindowsServer2016Std DSP 2017/10/22（日）東京到着予定。 到着し次第、HDDなど増設の上設定を進めていきます。 2017/11/23までに静岡に移送します。 それ以降、リモートにてデータ移行作業を進めて年末までのタイミングでサーバを切り替えます。その際、数時間の停止時間を設ける予定です。 **2017/11/23 [#hb418143] 新サーバへ切り替え完了しました。
