質問
こんにちはです。
弊社では、システムごとにSQLサーバーのライセンスを購入しており、「これって無駄じゃない?」と言われています。
確かにこれは別の意味で無駄かと思います。
例えばSQLServer2005が導入されているシステムが3つ存在し、100人でそのシステムを利用する場合などは、100×3=300CALではなく、ユーザCAL又はデバイスCALを100購入すれば問題無いと思います。
ユーザCALは社員に、デバイスCALは端末に付与するイメージですので、SQLServer2005のシステムが追加になっても
接続する数量が変化しない場合は、CALを購入する必要はありません。
但し40CALぐらいを超えるとCPUライセンス(接続無制限)の方が安くなってくるので、接続人数又はデバイス数で異なります。
あとライセンスは下位互換ですので、SQLServer2005ライセンスで上位バージョンのSQLServer2008の接続は出来ません。
現在販売中のCALはSQLServer2008R2で、これが一番の上位となります。
よってSQLServer2008R2のCALを購入すると下位のSQLServer2008・SQLServer2005も接続可能となります。
SQLServerライセンス形態もWindowsServerと大体同じようです。
#的外れでしたら、ご容赦を・・・
アプリケーションの開発や保守をしていた側からのコメントです。
参考程度に読んでください。
想像ですが、以下のような点を注意すればいいのではないでしょうか。
【サーバとアプリケーション】
・サーバOSに対する独自設定の有無(相反する設定がないか)
・CPU、メモリの通常時とピーク時の使用量
※ハードウェアが分散されていたのを1台または数台にするのでCPUやメモリの増設が必要になる可能性がないか確認するため。
【ネットワーク】
・ネットワークに掛かる通常時とピーク時の負荷(サーバ別に必要な場合はサーバ別に調査)
※ハードウェアが分散されていたのを1台または数台にするためネットワークアクセスが集中するので、ネットワーク機器の増設やネットワーク仮想化が必要となるケースが想定されるため。
※展示会に行った時、サーバ仮想化製品より出店数は少なかったですが、ネットワーク仮想化の製品も数社出店してました。
他に作業とは別で、以下の点について注意が必要かと思います。
【保守契約】
・利用されなくなったサーバ機器の保守について
一般的に1年更新のため、契約途中で解約した場合でも保守料が返却され
ない可能性があります。
・利用中のアプリケーションについて
市販されているアプリケーションの場合、問題はないのですが、
オーダーメイドまたはカスタマイズを自社独自で入れているアプリ
ケーション場合、アプリケーション開発元との保守・サポート契約が
無効になる可能性があります。
※対策としては、統合作業にコンサルタントとして入ってもらう方法
がいいのではないかと思います。費用は発生してしまいますが、
継続して保守・サポートを受けることができると思います。
10年ほど前ですが、お客さん先でDBサーバの統合プロジェクトをやっていました(私自身は別プロジェクトでしたが)。実運用に入って月末月初のレスポンス(反応速度)が悪くて、大変な状況になったのを覚えています。今と違って、ギガビット・イーサネットやネットワーク仮想化の製品もない頃だったので・・・最終的にはサーバを増設して対応したと記憶しています。
こんにちは
皆さんの回答に付け加えて、補足的にコメントします。
①ネットワーク集中することによる負荷の高まりがあるのと同様に
ディスクへのIO集中による負荷も意識しないといけないと思います。
ディスクそのものの負荷もそうですが、コントローラー性能も
少し意識したほうが好ましいです。(勉強にもなると思います)
②同じ筐体のハードに入れた場合、今まで別々の筐体で
動いていたけどひとつで動くことになるので、故障があった際には
何もしないで標準的な構成だと全システム一斉に止まる可能性が
あります。
重要度にもよりますが、あらゆる部分で二重化などの措置をするか、
そういう構成のハードを導入したほうがいいと思います。
一般的なハードメーカー以外にもこういうハードもあります。
(値段は確か高いですがその分安全性は高かったはずです・・・)
http://www.stratus.co.jp/technology/index.html
特にDBについて言いますと
③そもそもどのような構成でサーバーを立てるのかを考えたほうがいいと
思います。
ずいぶん触ってないのでうる覚えですが、SQLserverの場合
インスタンス → サーバー → データベース → テーブル
の順で作成され、
インスタンス=物理サーバーだったような気がします。
元々の構成は
複数物理サーバー=複数インスタンス→サーバー名→DB名→テーブル名
になっていると思いますが、統合する場合、
ひとつの物理サーバーにインスタンス、SQLサーバーをひとつづ作り
その中に複数のDBを作るのか・・・・
(とにかく一個のSQLサーバーにまとめてしまう)
それとも、物理サーバーひとつに対し、複数のSQLサーバーを作り
その中にそれぞれ移行するのか・・・・・
(元々存在した物理サーバーの数だけ、SQLサーバーが論理的に存在)
前者はアプリケーション修正の可能性が高まります。
後者はうまくやればアプリ修正なく出来そうな気がします。
※IP変更かかる場合は名前解決でうまくやる必要があります。
このあたりを気にしたほうがいいのではないかと思います。
VM使う場合には全く違いますが・・・・
私もあまり詳しくないので、実際には詳しい方に聞いていただくか
してくださいませ。
こんな感じで検討の思考を広げてみてはいかがでしょうか?
質問
弊社では、システムごとにSQLサーバーのライセンスを購入しており、「これって無駄じゃない?」と言われています。
折しも仮想化・サーバー統合ブームですので、こういったDBも統合して、尚且つ仮想化もしてサーバーもライセンス購入も減らそう!という意見が出てきています。
ですが、私はDBに関しては殆ど見識も経験も無い為、どういったことに注視して、どのように統合計画を作成すればいいのか、殆ど見当がつかない状態です。
そこで情シスの皆様にお伺いしたいのですが、SQLサーバーを統合された経験のある方、もしくはその旨の見識のある方がおられましたら、どういったことに注視しながら計画を立てればよいか、ご教示願えませんでしょうか?
ちなみに、当方仮想化についてはセミナー等で勉強しておりますので、その点については知識があります。問題は、DBをどう扱っていいのか、分かっていない、という点です。
【弊社のDBの環境】
SQL server 2000〜2008が5台程度
…今後、増えていく可能性あり。
全てのDBが、個々のシステムのAPと同居する形で利用されています。
以上、よろしくお願い致します。