Scientific Linux のミラー始めました
日常がどれだけ回線を利用しているのか
ニコニコアニメチャンネルの「日常」が配信停止されたわけだけど、その理由の憶測がいろんなところで飛び交ってますね。やれBD売れないからとか。
でまあ色々と記事に目を通して、id:kai_kuchikiさんの ニコ厨落ち着け、「日常」の配信制限はBDが売れないからじゃない を読んで、ああなるほどなあと。
計算してみる
じゃあとりあえず「日常」がどれくらいデータをおくっているかというと、第一話で見た場合
337MB(1ファイルの容量)*688000(再生数)= 231.85TB
なわけですね。あとこれが配信開始から1週間でどれくらい再生数が入っているかというと、「日常」1〜6話 再生数・コメ数推移グラフによると、約45万再生。話数による偏りは特になさそうです。
ということは単純に計算しても、
337MB*450000/7/24/60/60 = 250(MB/s)
一日あたりに21.6TB、SSDと同じくらいの転送速度。回線速度にすると実に2Gbpsにもなる。インフラ関連やってる人だとすぐに分かると思うけど、2Gbpsも帯域を持っていくコンテンツなんて正直なところ扱いにくい。
2Gbpsを配信期間の間持って行かれる(しかも各話による差が少ない)ので配信終了、つまり2クールの間帯域をずっと持っていかれるわけ。
純粋に2Gbpsのトランジットを購入したとして、メガ単価5000円で試算したとしても
5000円*2000(Mbps) = 1000万円/月
というわけで簡単に計算してもこれくらいの費用が必要。ひと月あたり4話配信できるので、1話あたりの通信費がざっくり250万円(もちろんこれ以外に通信施設の維持費とかニコニコ動画の配信サーバの費用などが加わってくる)になる。
ニコニコ動画がアニメ製作委員会からいくら貰っているかは知るよしもないのだけども、1話250万じゃ商売上がったりである。24話放送したら6000万円もかかってしまう。
じゃあどうするの
じゃあどうするかというとやはり今回みたいな方法しかできないんだろうなと。すでに先のブログでも言われていますけど、これ以外の方法はあまり無さそうですね。
ユーザができることとすれば、一旦ローカルに保存して何回か楽しむというくらいしかできません。週あたり45万再生のうちのリピータ率が知りたいところですね。
自宅ストレージ装置考察
最近扱うデータ量が増えてきたのでデータを大量に入れておく箱がとにかく欲しくなってきました。HDDは消耗品なので冗長性も確保しつついい方法がないかなと色々と調べていたのを簡単にまとめようかなと。
前準備
というわけで、大容量のストレージを調達するに当たってどの辺を抑える必要があるかを簡単にリストアップしたのがこれ。
目的 | データの長期保存 |
容量 | 10TB程度以上 |
冗長性 | 最低でもRAID5以上。可能ならRAID6もしくは同程度のもの |
速度 | そこそこ使えればいいくらい。ただし場合によっては高速なアクセスが必要になる。 |
インターフェース | 手軽さを取るならUSB3.0系。速度を取るならeSATAかSAS。共有するならNAS |
管理 | 簡単なものが良い。専用ソフトなどがあると使いやすい。 |
速度の面が今現在の希望と今後の需要があってくるかが不透明な部分があるので要考慮。用途が映像編集などになっているので、速度が必要になる面はどうしても出てくる可能性がある(内蔵HDDに任せてしまうのも手だけど)。インタフェースはシステムへの依存度が問題。USBやFW、NASなどを使えばマシン依存なく便利だけども速度が遅い。一方でeSATAやSASは速度がずば抜けるもののRAIDカードとセットで考える必要がある。iSCSIは依存度は低いものの高価なので今回は選考の対象外。
というわけでインタフェースごとの特徴を比較したのがこれ。
インタフェース名 | 価格 | 速度 | 備考 |
USB2.0 | ◎ | × | どの端末でも使える。お手軽 |
USB3.0 | △ | ◯ | USB3.0ボードさえあれば使える。そこそこ速い |
FW800 | ◯ | △ | Macとの相性がいい |
NAS(GbE) | △ | △ | 複数台の端末で共有可能 |
eSATA | △ | ◯ | 内蔵ポートを外出しすることが可能。マルチレーン接続は要ボード増設。RAIDをするにはさらに板が必要 |
SAS | × | ◎ | 何よりも早い。しかし板が高い。RAID6が出来る製品多数 |
製品リスト
DroboS3
DroboS3 http://www.drobo.com/products/drobo-s.php
とりあえず一番最初に探して見つかったのがこれ。USB3.0対応でHDD5台搭載可能。BeyondRAIDと呼ばれる謎の技術により、似非RAID6みたいなことが可能。HDDを容量の大きい物に変更することでアレイのサイズを拡大することができる。Windows向けのソフトが充実しているので管理が楽。
一方で速度が遅い。シーケンシャルアクセスで80MB/S程度(http://ottoserver.com/pcserver1/wp/archives/205#more-205 参照のこと)でるものの2chのスレ(http://hibari.2ch.net/test/read.cgi/hard/1287464180/)では使用すればするほど遅くなる報告も。またBeyondRAIDの信頼性が不明。エンクロージャが壊れてもRAID構成情報はHDD側に保存されているので同様の製品化上位互換性品を用意することでRAIDの復旧が可能。
本体価格10万円。
areca ARC-4030ML + ARC-1210ML or ARC-1220ML
areca ARC-4030ML http://www.kingtech.co.jp/products/removable/arc-4030ml.html
ARC-1210ML or ARC-1220ML http://www.kingtech.co.jp/products/raidcard/arc-12x0ml.html
速度面重視で探してたどり着いたのがこれ。SAS(SFF-8088)接続が可能。RAIDレベルは0, 1, 1E, 3, 5, 6が可能。areca ARC-4030MLは基本的にHDDを入れるだけの箱と考えて問題なし。RAIDの性能は組み合わせるRAIDカードに完全依存。RAID板が壊れてもRAID構成情報がHDDにあるため復旧可能。ホットスペアに対応。
ARC-1210ML or ARC-1220ML のチョイスは外付けSASインタフェースの本数が1本か2本かの違い。今後箱だけ増やすことを考えるなら外付け2本の1220MLがあり。
システムへの依存度はDroboS3に比べて上がってしまう。RAIDカードを付けるための PCI Express X8スロットが必須(組み合わせるRAIDカード次第)。
本体価格6+3+1万円(最安、ARC-1210MLと接続ケーブル)
本体価格6+6+1万円(最安、ARC-1220MLと接続ケーブル)
まとめ
どちらも電源が外付けで存在するあたりは非常にお手軽。価格もほぼ変わらないのでareca ARC-4030ML + ARC-1210MLの方を買ってみようかなと考えてます。
Netscreen500でのIPv6の扱い
なにやら紆余曲折会って、Netscreen500を利用することになったので仕込んでました。その際ScreenOSがVersion5でIPv6に対応しているとのことで、IPv6を有効にして色々と検証してました。(ScreenOS:5.4.0r19.0)
IPv6を扱うために
Netscreen500はデフォルトではIPv6が有効になっていません。そこでまずIPv6を有効にしてあげます。
set enver ipv6=yes save reset
ちなみに無効化するには
unset enver ipv6=no save reset
このコマンドを入れることでIPv6が有効になります。具体的な機能については以下を参照。
NetScreen IPv6 Reference Guide
http://www.juniper.net/techpubs/software/screenos/screenos5x/screenos5xipv6/IPv6_ref.pdf
Transparent Modeでの問題
NS500でIPv6を有効にするとIFやPolicyでIPv6が扱えるようになります。というわけで早速Transparent Modeで透過FWにしようとしたところ色々と問題が。
・DenyしてもRAが飛んで来る
Transparent Modeにした後、V1-TrustとV1-Untrustを利用してルータと端末を分断、後以下のようなPolicyをいれたところ問題が。
set policy id 0 name "any-any Logging" from "V1-Trust" to "V1-Untrust" "Any-IPv6" "Any-IPv6" "ANY" deny log set policy id 1 name "any-any Logging" from "V1-Untrust" to "V1-Trust" "Any-IPv6" "Any-IPv6" "ANY" deny log
とりあえずDenyして隔離しようとしたところ何故かRAが端末に届く。色々と調べたところ、V1-UntrustからV1-Trustに向かってパケットが流れてしまっている始末。なにやら不穏そうなのでいろいろ調べたところ、こういうオチが。
Solution: Upgrade to ScreenOS 6.2 for the following new feature: Transparent Mode for IPv6―ScreenOS now supports IPv6 addressing and functionality on security devices in transparent mode. This feature adds support for three new kinds of VPNs: IPv4 over IPv6 IPsec, IPv6 over IPv4 IPsec and IPv6 over IPv6 IPsec. Device management is also permitted in IPv6 mode. Also, refer to the Release Notes for ScreenOS 6.2: www.juniper.net/techpubs/software/screenos/screenos6.2.0
Is IPv6 supported on ScreenOS in transparent mode?
http://kb.juniper.net/InfoCenter/index?page=content&id=KB13443
というわけで、ScreenOSが6.2以降にならないとTransparent ModeでIPv6をフィルターできません。ちなみに5.4でトラフィックを流しこんでも、PolicyをいれていなければDropされます。残念。
ちょっとした小技
NAT/Router mode で稼動しているとき、すべてのIPv6インタフェースルーティングをすることができるので、ethernet I/F以外でどういう挙動をするか試したところ、mgt/ha1/ha2でもルーティングできました。
なんというか、想定した用途以外の使い方な気もする。
まとめ
結局色々試したところ、ScreenOS5系のIPv6機能はまだまだといった感じです。NAT/Router modeでは一応フィルターとかも動くので使い方によっては十分だと思いますが、若干物足りない感じでした。
Public mirror Serverやってます
なんだかんだで、http://ftp.tsukuba.wide.ad.jp/ を運用し始めたのが3月なのでそろそろ9ヶ月目を迎えようとしています。そういえばPublic mirrorを建てたという記事を書いてなかったのでちょうどいいので今回まとめてみようと思います。
構成
Public mirrorはアクセスがちょっと特殊で、すべてのトラフィックがReadであるということです。これに注意したうえで構成を以下のように組んでみました。
server | 役割 | filesystem | OS | CPU | mem | boot hdd | shared hdd |
ftp-manager | 管理用端末 | ext3 + gfs | CentOS 5.5 | Xeon2.4Ghz*2 | 2GB | 200GB | 8TB(shared) |
ftp1 | web-server 01 | ext3 + gfs | CentOS 5.5 | Xeon2.4Ghz*2 | 2GB | 200GB | 8TB(shared) |
ftp2 | web-server 02 | ext3 + gfs | CentOS 5.5 | Xeon3.6Ghz*2 | 2GB | 200GB | 8TB(shared) |
ftp3 | web-server 03 | ext3 + gfs | CentOS 5.5 | Pentium4 3Ghz | 2GB | 200GB | 8TB(shared) |
ftp4 | web-server 04 | ext3 + gfs | CentOS 5.5 | Pentium4 3Ghz | 2GB | 200GB | 8TB(shared) |
管理用端末を1台用意し、その部分で他のサイトで運用されているミラーサーバと同期をとるような構成になっています。FTP1-4のサーバはソフトウェア的には同じ構成にしています。HWについては手持ちで余っていたx86なマシンをつなぎ合わせて使っています。
メンテナンス性を考えてHDDはすべてFC-SAN上で管理しています。OS boot用の領域をFC-SANの上にLUNを別々に用意し、ミラーデータのある共有領域を1つのLUNにまとめた構成になっています。共有ディスクを利用するので、ミラーデータのある領域のファイルシステムとしてGFS(Global File System)を利用しています。
アクセス数
というわけで寄せ集め寄せ集めで出来上がってる当ミラーですが、9ヶ月ほどたってようやくアクセス数も安定してきました。現在は以下のものをミラーしており、今後順に増やしていく予定です。
アクセス数
ミラー内容
やりたいこと
今のところパフォーマンスについてはおおむね問題はないのですが、アクセス数がこのまま伸びていくとDiskI/Oがちょっと心配になってくるかなと思っています。そのあたりはRAM上にキャッシュを作ってそこに乗せたりとかそういう運用ができそうです。
また、HWもサーバがばらばらなので動的に追加したいなと思った時に入れれないなどの問題があるのでやっていきたいですね。
あとサーバに乗せるネタをもっと増やしたいなと。BSD系は現在準備中です。sorceforgeとかもできたらいいな。
さくらVPSでIPv6を使う
はじめに
新サービス「さくらのVPS」(正式版)お申し込み受付開始のお知らせ
というわけで、国内ホスティング大手のさくらさんからVPS(Virtual private server)のサービスがリリースされたのでさっそく使って遊んでみました。今まで専用サーバでしか使えなかったrootが使えるので、今まで以上に遊べそうです。
提供されるサービスは以下のような感じになっています。
さくらVPS | |
料金 | 月額980円 |
試用期間 | 2週間 |
CPU | Intel(R) Xeon(R) CPU ? @ 2.40GHz |
MEM | 512MB |
HDD | 20GB |
帯域 | UP:1Gbps, Down:100Mbps |
NIC | Intel(R) PRO/1000 Network Connection |
IPv4 | グローバルアドレス1個 |
IPv6 | 無し |
OS | CentOS 5.5 x86_64 |
他のサービスとの比較は、格安VPSの比較「ServersMan@VPS」と「さくらのVPS」(2010/9/1時点) « R2.agによくまとまっている感じです。気になる速度測定の結果は、さくらのVPS 正式版 - masa23のメモによくまとまっています。
IPv6を使いたい
そこそこ高性能な占有サーバを安価に利用できるなら、IPv6も使いたいところです。IPv6対応のホスティングサービスはまだあまり多くないので、VPSを利用してIPv6サーバを作ってみました。
さくらVPSでIPv6を使うにはいくつか方法があります。表にまとめました
手段 | トンネル方式 | 長所 | 短所 | 説明 |
6to4 | v6 over v4 | 比較的すぐ使える | IPv4アドレスが変わるとIPv6アドレスが変更になる 戻りの経路についてはクライアント依存 | IPv4グローバルアドレスが利用できるので6to4が利用可能。さくらVPSからリレールータまでの距離が近い(サーバからクライアント方向) |
teredo | v6 over v4 | 比較的すぐ使える | リレールータまでの距離が遠く遅延大 | teredoルータを経由することでIPv6 over IPv4を実現する |
PacketiX公開実験 | Ether over v4 | 固定Prefixが利用可能 | 専用のサーバが必要 | グローバル・固定 IPv6 アドレス割当型トンネル接続実験サービスを利用して接続する |
というわけで、今回はグローバル・固定 IPv6 アドレス割当型トンネル接続実験サービスを利用してさくらVPSにIPv6のコネクティビティを実現してみました。
PacketiX VPN Clientのインストール
というわけで、早速サーバの仕込みです。手順としてはVPN Clientをインストールして実験サービスに接続するだけです。今回はPacketiX VPN Client3.0を利用します。最新版はSoftetherのWEBからダウンロードしてください。
# 依存モジュールをインストール yum -y install openssl-devel zlib-devel readline-devel ncurses-devel # 適当なディレクトリで # PacketiX VPN Client3.0をダウンロード wget http://uploader.softether.co.jp/vpn3/v3.00-6890-rtm-2010.03.15/VPN/Japanese/Linux/PacketiX%20VPN%20Client%203.0/64bit%20-%20Intel%20x64%20or%20AMD64/vpnclient-v3.00-6890-rtm-2010.03.15-ja-linux-x64-64bit.tar.gz # 展開 tar zxvf vpnclient-v3.00-6890-rtm-2010.03.15-ja-linux-x64-64bit.tar.gz # install.shでインストール cd vpnclient sh .install.sh -------------------------------------------------------------------- PacketiX VPN Client 3.0 (Ver 3.00, Build 6890, Japanese, Intel x64 / AMD64) for Linux Install Utility Copyright (C) 2004-2010 SoftEther Corporation. All Rights Reserved. -------------------------------------------------------------------- Do you want to read the License Agreement for this software ? 1. Yes 2. No Please choose one of above number: 1 ==規約文章につき省略== Did you read and understand the License Agreement ? (If you couldn't read above text, Please read 'ReadMeFirst_License_UTF8.txt' file with any text editor.) 1. Yes 2. No Please choose one of above number: 1 Did you agree the License Agreement ? 1. Agree 2. Do Not Agree Please choose one of above number: 1 Preparing PacketiX VPN Client 3.0... ranlib lib/libcharset.a ranlib lib/libcrypto.a ranlib lib/libedit.a ranlib lib/libiconv.a ranlib lib/libncurses.a ranlib lib/libssl.a ranlib lib/libz.a ranlib code/vpnclient.a gcc code/vpnclient.a -O2 -fsigned-char -pthread -m64 -lm -ldl -lrt -lpthread -L./ lib/libssl.a lib/libcrypto.a lib/libiconv.a lib/libcharset.a lib/libedit.a lib/libncurses.a lib/libz.a -o vpnclient ranlib code/vpncmd.a gcc code/vpncmd.a -O2 -fsigned-char -pthread -m64 -lm -ldl -lrt -lpthread -L./ lib/libssl.a lib/libcrypto.a lib/libiconv.a lib/libcharset.a lib/libedit.a lib/libncurses.a lib/libz.a -o vpncmd -------------------------------------------------------------------- The preparation was completed. Please execute './vpnclient start' to run PacketiX VPN Client 3.0 Background Service. And please execute './vpncmd' to run PacketiX VPN Command-Line Utility to configure PacketiX VPN Client 3.0. --------------------------------------------------------------------
これでPacketiX VPN Client3.0のインストールが完了です。このあとに仮想LANカードの作成をします。仮想LANカードを作るには、VPNコマンドユーティリティ(vpncmd)を利用します。
[root@www1027u vpnclient]# ./vpncmd vpncmd コマンド - PacketiX VPN コマンドライン管理ユーティリティ PacketiX VPN コマンドライン管理ユーティリティ (vpncmd コマンド) Version 3.00 Build 6890 (Japanese) Compiled 2010/03/15 05:56:28 by yagi at pc25 Copyright (C) 2004-2010 SoftEther Corporation. All Rights Reserved. vpncmd プログラムを使って以下のことができます。 1. VPN Server または VPN Bridge の管理 2. VPN Client の管理 3. VPN Tools コマンドの使用 (証明書作成や通信速度測定) 1 - 3 を選択: 2 接続先の VPN Client が動作しているコンピュータの IP アドレスまたはホスト名を指定してください。 何も入力せずに Enter を押すと、localhost (このコンピュータ) に接続します。 接続先を入力: VPN Client "localhost" に接続しました。 VPN Client>
vpncmdの操作が可能になりました。まず仮想LANカードを作ります。仮想LANカード名を「IPv6」としました。
VPN Client>NicCreate NicCreate コマンド - 新規仮想 LAN カードの作成 仮想 LAN カードの名前: IPv6 コマンドは正常に終了しました。
仮想LANカードを作成すると、OSから見えるようになります。OSからは「vpn_ipv6」というNICに見えます。
[root@www****u ~]# ifconfig vpn_ipv6 vpn_ipv6 Link encap:Ethernet HWaddr 00:AC:D3:51:B6:7F inet6 addr: fe80::2ac:d3ff:fe51:b67f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
仮想LANカードを作成したら、次に公開実験サービスに接続する設定をします。公開実験サービス用のアカウントはあらかじめHPから取得しておいてください。
VPN Client>accountcreate AccountCreate コマンド - 新しい接続設定の作成 接続設定の名前: IPv6 接続先 VPN Server のホスト名とポート番号: v6ip.tsukuba.wide.ad.jp:443 接続先仮想 HUB 名: ACVPN 接続するユーザー名: 登録したユーザ名 使用する仮想 LAN カード名: IPv6 コマンドは正常に終了しました。
アカウントに対して仮想LANカードを設定します。先ほど作成した仮想LANカードを設定してください。
最後にアカウントのパスワードを設定します。これはユーザ登録すると送られてくるパスワードです。
VPN Client>accountpasswordset AccountPasswordSet コマンド - 接続設定のユーザー認証の種類をパスワード認証に設定 接続設定の名前: IPv6 パスワードを入力してください。キャンセルするには Ctrl+D キーを押してください。 パスワード: ******** 確認入力 : ******** standard または radius の指定: standard コマンドは正常に終了しました。
これでアカウントの設定は完了です。最後に接続処理をします。
VPN Client>accountconnect AccountConnect コマンド - 接続設定を使用して VPN Server へ接続を開始 接続設定の名前: IPv6 コマンドは正常に終了しました。 VPN Client>accountlist AccountList コマンド - 接続設定一覧の取得 項目 |値 -------------------+---------------------------------------------- 接続設定名 |IPv6 状態 |接続完了 接続先 VPN サーバー|v6ip.tsukuba.wide.ad.jp:443 (直接 TCP/IP 接続) 仮想 HUB 名 |ACVPN 仮想 LAN カード名 |IPv6 コマンドは正常に終了しました。
これで接続完了です。最後に確認してみましょう。
[root@www****u ~]# ifconfig vpn_ipv6 vpn_ipv6 Link encap:Ethernet HWaddr 00:AC:D3:51:B6:7F inet6 addr: 2001:200:1c8:a:2ac:d3ff:fe51:b67f/64 Scope:Global inet6 addr: fe80::2ac:d3ff:fe51:b67f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:57 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:4080 (3.9 KiB) TX bytes:546 (546.0 b) [root@www1027u ~]# ping6 www.kame.net PING www.kame.net(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=0 ttl=58 time=20.8 ms 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=1 ttl=58 time=21.2 ms 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=2 ttl=58 time=21.0 ms 64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=3 ttl=58 time=21.8 ms --- www.kame.net ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 20.865/21.253/21.899/0.435 ms, pipe 2
これで完了です。疎通確認もできました。
Windows7 DNS resolverの問い合わせ先DNSサーバの優先度付けについて
問い合わせ先DNSサーバの選択
前回の項目3においてAとAAAAの両方が観測された件についてさらに調べて、ようやくWindows7 DNS resolverの問い合わせ優先度がわかってきました。
まず、基本的なこととして、以下の項目に着目します。
- IPv4とIPv6両方のDNSサーバが存在するとき、IPv4を優先
- IPv4DNSサーバに問い合わせた時、応答がなければIPv6DNSサーバに問い合わせる
- AAAAレコードより先にAレコードで問い合わせをする
- このとき、NXDOMAINであった場合はAAAAレコードを抑制する
- 端末にIPv4アドレスのみが割り当てられているときは、AAAAレコードを抑制する
そこで、これらの挙動に沿ってシチュエーションごとに挙動を分けてみました。ここでは、eth1にはIPv4のみを、eth2にはIPv6のみを割り当てています。ここは前回の記事と同じです。
IPv4IF eth1 | IPv6IF eth2 | IPv4DNSサーバへの問い合わせ | IPv6DNSサーバへの問い合わせ |
UP | UP | A | IPv4DNSサーバへの問い合わせ結果がNXDOMAINもしくは応答がないとき、Aを先行し、応答があればAAAAを問い合わせる |
UP | DOWN | A | × |
DOWN | UP | × | Aを先行し、応答があればAAAAを問い合わせる |
といった感じになります。もちろんDualStackのIFがあればこのようなことは特に心配する必要がないのですが、IPv4とIPv6のネットワークを分けている場合には注意が必要です。
このような挙動から既知の問題点としては、「eth1にIPv4、eth2にIPv6」を割り当てた時に、www.kame.netなどのIPv4とIPv6の両方に対応したWEBサイトにアクセスすると、IPv4でアクセスしてしまうということです。これはIPv4でAを問い合わせた時に応答があり、そこで名前解決が終了してしまうためです。
また、このような特殊環境下において、IPv6トランスポートを優先できないかといろいろ試しましたが、Windows7の内部実装に依存しつつまたnetshなどでpolicyを変更することができなかったため残念ながらできませんでした。
こういった挙動はIPv6が浸透せず、IPv4がまだ大半で用いられている情勢では良い実装だと思うのですが、IPv6優位になってきたときには、AレコードからAAAAレコードへのフォールバックが問題になってくると考えられます。
いずれにせよ、IPv6優位になってきたときにパッチか何かで変更されることを期待するしかないですね。