OpeItcLoc03/admin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
86c44c3db90a07dff1015d2f655022395208469e
admin/.wiki/entities/snolla-recovery-vm.md
vitya d25c0577c8 import: .wiki/entities/ from MoreThenCms via subtree-split 
git-subtree-dir: .wiki/entities
git-subtree-mainline: 6d8d75474d
git-subtree-split: 24661c10fb
2026-05-21 13:46:38 +03:00

8.4 KiB
Raw Blame History

title, type, tags, sources, updated
title type tags sources updated
Snolla Recovery VM (VirtualBox) — savestate'нута 2026-05-21 после 36h успешного soak entity
vm
virtualbox
windows
iis
cms
recovery
savestate
../sources/nas-recovery-session-2026-05-18.md
../sources/iis-host-migration-2026-05-19.md
../concepts/iis-migration-2026-05-19-postmortem.md
2026-05-21

Snolla Recovery VM

VirtualBox-VM на windows-recovery-host, в которой работает CMS-стек (IIS + .NET + код CMS). Импортирован из OVA-снапшота 2024-10-27, который лежал в Hyper Backup репо.

Статус (2026-05-21 05:13 MSK): VM savestate'нута после ~36h soak attempt 2 миграции (VBoxManage controlvm snolla-recovery savestate, 45.6s, VMState=saved). Savestate file: Snapshots\2026-05-21T05-12-43-636491200Z.sav = 1.73 GB (compressed RAM). VBoxHeadless процессы исчезли — освобождено ~4 GB private memory. Disk usage +1.7 GB.

Resume в любой момент через VBoxManage startvm snolla-recovery --type headless (~30 сек). После соак ещё одной недели — unregistervm --delete (освободит ~95 GB на C: — snolla-disk1.vmdk 95.8 GB + .sav).

Предыстория: все 11 cms hosts мигрированы на host-IIS:8089 (iis-host-migration-2026-05-19 Phase 10), 36h soak passed без rollbacks (Phase 11), 8/8 наших sites зеленые через full traefik HTTPS chain. VM держалась как parallel fallback (recipe-D из iis-migration-2026-05-19-postmortem) — fallback не понадобился.

История: утром 2026-05-19 attempt 1 миграции сломал prod (Docker NAT loop), был revert на VM. Через тот же вечер — attempt 2 по recipe (backend port :8089 вместо :80, smoke -MaximumRedirection 0, phone-test не-LAN) — succeeded. Подробности обеих попыток в iis-host-migration-2026-05-19 Phases 1-10.

Параметры

  • VBox name: snolla-recovery
  • UUID: 66aac8bb-fe70-4ced-87f6-2291cd0e8b74
  • Расположение: C:\Users\vitya\VirtualBox VMs\snolla-recovery\
  • OS внутри: Windows (вероятно Server 2016/2019, hostname SNOLLA)
  • RAM: 4096 MB
  • vCPU: 2 (после оптимизации vbox-windows-stability-tuning — было 4)
  • Disk: snolla-disk1.vmdk, max 120 GB, реально ~92 GB на хосте
  • Storage controller: SATA AHCI (после миграции с SCSI LsiLogic, см. vbox-windows-stability-tuning)
  • Network: NAT (после миграции с bridged WiFi из-за нестабильности)
  • Paravirt: kvm (matching исходному гипервизору Synology VMM)
  • OS type: Windows10_64 (исходно был Other_64, поправили для оптимальных дефолтов)
  • Guest Additions: 7.2.8 r173730, RunLevel=3 (полностью активны)

NAT Port Forwards

Host port VM port Назначение
13389 (console) VRDE (VBox Remote Display) — для отладки, не зависит от Windows RDP
23389 3389 RDP внутри VM (Windows Remote Desktop)
8022 22 SSH (OpenSSH Server в VM)
18080 80 IIS Default — основной HTTP CMS
18180 8080 IIS site stostayer
18181 8081 IIS site stostayer.old
18189 8089 (запасной)

Учётка

  • Admin: vitya (домен SNOLLA)
  • Default shell для sshd: PowerShell (зарегистрирован в HKLM:\SOFTWARE\OpenSSH → DefaultShell)
  • Authorized SSH key для admin-users: C:\ProgramData\ssh\administrators_authorized_keys (особое место для admin Windows OpenSSH; permissions через icacls, group Администраторы:F + СИСТЕМА:F)

IIS-сайты

Site Path Bindings Прим.
MoreThenCms.Web C:\inetpub\wwwroot\MoreThenCms.Web *:80 active prod — catch-all для 11 главных доменов; traefik backend host.docker.internal:18080
Snolla.IdentityManager C:\inetpub\wwwroot\Snolla.IdentityManager *:8089 публично не используется
stostayer C:\stayer\MoreThenCms.Web *:8080 active prod — traefik backend host.docker.internal:18180; conn → внешний 89.253.219.2,1433 (но user в session 2026-05-19 поменял на www.stostayer.ru,1433 для host-копии; в VM остался старый)
stostayer.old C:\stayer\stostayer.old *:8081 active prod — traefik backend host.docker.internal:18181
stostayer.old/calc C:\stayer\Mis.StoStayer.Calculator.Web (sub-app под :8081) существует, sub-app pool calc
stostayer.old/price C:\stayer\Mis.StoStayer.Price.Api (sub-app под :8081) существует, sub-app pool price
stostayer.old/price/tireService C:\stayer\Mis.StoStayer.TireService.Api (sub-app под :8081) существует, sub-app pool tireService

CMS распознаёт клиента по Host header — все 11 клиентских доменов идут на :80 и роутятся внутри CMS-кода.

Важно для следующей попытки миграции: stostayer Web.config в VM указывает на старый 89.253.219.2,1433, а на host-копии (C:\sites\stostayer\Web.config) уже patched на www.stostayer.ru,1433 с XML-escape & в password. Если когда-то будем сводить эти конфиги — host-копия правильнее (старый сервер мёртв).

Web.config — критичные настройки (после recovery patch)

  • Connection string: Data Source=10.0.2.2;Initial Catalog=MoreThenCms;User Id=snolla;Password=fXkH4@8O%3pc;...
    • 10.0.2.2 = NAT gateway в VBox = адрес хоста windows-recovery-host изнутри VM
    • До патча было Data Source=192.168.1.10 (старая мёртвая синка)
    • Тот же пароль fXkH4@8O%3pc совпадает с SA-паролем MSSQL контейнера (production password из старого compose)
  • Encoding файла: UTF-8 with BOM (важно — см. cms-config-rewrite-pattern)
  • 4 файла пропатчены аналогично: MoreThenCms.Web/Web.config, Snolla.IdentityManager/Web.config, stostayer.old/web.config, и stayer-проектов (если применимо)

Связь со внешним миром

  • VM в NAT-режиме → не имеет LAN-IP
  • Из traefik (на хосте) достижима по host.docker.internal:18080 → NAT-форвард в Windows → VM:80
  • Раньше (когда было bridged) — VM имела IP 192.168.1.15 с MAC 02:11:32:2A:7C:B9. snolla.yml в traefik/data/custom/ исходно ссылался на http://192.168.1.15/ — пропатчен на host.docker.internal:18080/.

Стабильность

  • Нестабильна на bridged-WiFi → переведена в NAT (стало лучше, но всё равно требует осторожности).
  • Один случай (после нескольких часов uptime): network adapter в VM "повис" — все TCP-handshake проходили, но через них трафик не шёл. Лечится ipconfig /release && /renew внутри VM через VBoxManage guestcontrol.
  • Долгосрочно: пора планировать scheduled task внутри VM, который при детекции downtime автоматически перезагружает network adapter / iisreset. Или вообще переезд на Hyper-V — рекомендация Microsoft для Windows-гостей.

Известные баги в текущей конфигурации

  • X-Forwarded-Proto/Host headers не передаются с traefik в IIS → CMS делает redirect на http://www.<domain>:4443/ (mixing HTTP scheme with HTTPS port). Не критично, но требует фикса.
  • *Логи в C:\inetpub\logs* растут (~6 GB на момент recovery) — нужна ротация.
Reference in New Issue View Git Blame Copy Permalink