დატაცენტრი და კერძო ღრუბელი
კერძო ღრუბელი, სადაც კვანძის დაკარგვა ინციდენტია და არა ავარია
Fabric-ის დიზაინი, საცავი, HA და provisioning-ის ავტომატიზაცია — ჩვენივე დატაცენტრში მომუშავე პლატფორმის იმავე პრინციპებით.
პრობლემა
კერძო ღრუბელი ერთი სტელაჟია, რომელიც უბრალოდ გაიზარდა
სერვერები დაემატა მაშინ, როცა დასჭირდა; საცავი ერთია და ყველაფერი მასზეა; ქსელი ორ კომუტატორზე გადის, რომელთა კონფიგურაცია ერთმანეთს აღარ ემთხვევა. capacity-ს ვერავინ ითვლის, რადგან N+1 მხოლოდ პრეზენტაციაში იყო.
- საცავი ერთადერთი წერტილია
- ჰოსტების ვერსიები ერთმანეთს დაშორდა
- მანქანები ხელით იქმნება, შაბლონების გარეშე
- აღდგენა არასდროს გაშვებულა ბოლომდე
რას ვაწვდით
კერძო ღრუბელი, სადაც კვანძის დაკარგვა ინციდენტია და არა ავარია
Fabric-ის დიზაინი
leaf/spine ან collapsed core, LACP, MTU, მართვის ცალკე ქსელი და out-of-band წვდომა.
Compute და capacity
ჰოსტების რაოდენობა N+1-ით, დატვირთვების განაწილება და ზრდის პროგნოზი.
საცავის ტოპოლოგია
ZFS/RAID დონეები, NFS/iSCSI, სნეპშოტები, რეპლიკაცია და დისკების ჯანმრთელობის მონიტორინგი.
HA და failover-ის ტესტი
კვანძის დაკარგვა რეალურად სრულდება და შედეგი იწერება.
Provisioning და შაბლონები
cloud-init, შაბლონები და API — ხელით შექმნილი მანქანა გამონაკლისი ხდება.
ბექაპი და აღდგენის რეპეტიცია
პოლიტიკა, შენახვის ვადები და აღდგენა scratch გარემოში, განრიგით.
არქიტექტურა
არქიტექტურა
- 01ფიზიკური ფენა
- Redundant power
- Cooling
- OOB
- 02ქსელიleaf-spine
- EVPN-VXLAN
- LACP
- MTU 9000
- 03Computeვირტუალიზაციის კლასტერი
- KVM / Proxmox
- VMware
- HA
- 04საცავი
- Ceph
- ZFS
- NVMe
- 05აღდგენატესტირებული restore
- Snapshots
- Off-site
- DR runbook
საოპერაციო ეკრანები
საოპერაციო ეკრანები
ეს კონკრეტული სისტემები ჯგუფის რეალურ ინფრასტრუქტურაზე მუშაობს — სქრინშოტები დამუშავებულია გამოქვეყნებამდე.
ვირტუალიზაციის კლასტერი
მრავალკვანძიანი Proxmox კლასტერი: KVM ვირტუალური მანქანები და LXC კონტეინერები, NFS/HA საცავი, ცალკე backup-NAS და მიგრირებული ESXi ჰოსტები. ეს საიტიც ამ კლასტერზე მუშაობს — კონტეინერში, იმავე ინფრასტრუქტურაზე, რომელსაც ვყიდით.
8 კლასტერი ერთი ინტერფეისიდან
Proxmox Datacenter Manager აერთიანებს ერთმანეთისგან დამოუკიდებელ Proxmox VE კლასტერებს ერთ სივრცეში. ჩვენს ინფრასტრუქტურაში ის 8 კლასტერს მართავს — სხვადასხვა ფიზიკურ ლოკაციაზე, მათგან 3 საქართველოს ფარგლებს გარეთ. ეკრანზე ჩანს მასშტაბიც: 211 კვანძი ონლაინ, 1480 ვირტუალური მანქანა და 127 კონტეინერი — ერთი ხედით, ერთი პროცედურით.
vSphere — კლასტერი, ჰოსტები და სამუშაო დატვირთვები
vCenter რამდენიმე ESXi ჰოსტით და მათზე განთავსებული სერვისებით: ვებ, ბილინგი, დომენის კონტროლერი, backup აგენტები. ეს არის ის გარემო, სადაც VMware და Proxmox ერთდროულად ცხოვრობს — ნაწილი ჯერ კიდევ vSphere-ზეა, ნაწილი უკვე მიგრირებულია. ორივეს ერთი გუნდი ოპერირებს, ერთი backup-პოლიტიკით.
საცავი — ZFS პულები და რეპლიკაცია
ZFS საცავი RAIDZ2 ტოპოლოგიაზე — 12 დისკი ერთ vdev-ში, ~33 TiB სასარგებლო მოცულობა, ECC მეხსიერება და მისი დიდი ნაწილი ZFS ქეშად. აქვე ჩანს ის, რაც მთავარია: დისკები შეცდომებით — 0, scrub და scan შეცდომების გარეშე. ვირტუალიზაციის კლასტერისა და backup-ის ქვეშ სწორედ ეს ფენა დგას.
შესაძლებლობები
შესაძლებლობები
თითოეული პუნქტი აღნიშნულია: დადასტურებული პროდაქშენ გამოცდილება თუ საინჟინრო შესაძლებლობა.
საკუთარი დატაცენტრი საქართველოში
Provenenterprise კლასის აღჭურვილობა დაცული კვებითა და გაგრილებით — ჯგუფის ჰოსტინგის პლატფორმა სწორედ აქ მუშაობს.
- Cisco
- Juniper
- Arista
- Dell
- HP
KVM პლატფორმა საათობრივი ბილინგით
ProvenRAID 10 SSD საცავი Xeon Gold პლატფორმაზე, გამოყოფილი IPv4 და 1 Gbps პორტი თითოეულ ვირტუალურ სერვერზე.
- KVM
- RAID 10 SSD
- Xeon Gold
მრავალკლასტერული Proxmox
Proven8 დამოუკიდებელი Proxmox VE კლასტერი სხვადასხვა ფიზიკურ ლოკაციაზე, ერთი ინტერფეისიდან მართული — 3 მათგანი საქართველოს ფარგლებს გარეთ.
- Proxmox VE
- Datacenter Manager
- PBS
VMware vSphere კლასტერები
Proven- vSphere
- ESXi
- vCenter
ZFS საცავი და რეპლიკაცია
Proven- TrueNAS
- ZFS
- NFS
ბექაპი და ტესტირებული აღდგენა
Proven- Proxmox Backup Server
- Cyber Backup
- Snapshots
EVPN-VXLAN fabric
Capability- EVPN
- VXLAN
- Arista
- Open vSwitch
განაწილებული საცავი (Ceph)
Capability- Ceph
- NVMe
- CRUSH
Provisioning-ის ავტომატიზაცია
Provenჯგუფის ჰოსტინგში სერვერი API-დან იქმნება, ოპერატორის ჩარევის გარეშე.
- API
- cloud-init
- Control panel
პროცესი
პროცესი
- 01
აუდიტი
ჰოსტები, საცავი, ქსელი, ლიცენზიები და დატვირთვები.
- 02
დიზაინი
სამიზნე fabric, capacity და საცავის ტოპოლოგია.
- 03
აწყობა
კვანძები, ქსელი, საცავი და ბექაპი — დოკუმენტირებულად.
- 04
მიგრაცია
დატვირთვები ეტაპებად, rollback-ის გეგმით.
- 05
ვალიდაცია
კვანძის დაკარგვა და აღდგენა სრულდება, არა იგულისხმება.
- 06
ოპერირება
მონიტორინგი, capacity და პატჩების ციკლი.
ტექნოლოგიური სტეკი
ტექნოლოგიური სტეკი
- Compute
- Proxmox VEKVMVMware vSphereLXC
- საცავი
- TrueNASZFSRAID 10 SSDNFSiSCSICeph
- ქსელი
- AristaLACPOpen vSwitchEVPN-VXLAN
- ბექაპი
- Proxmox Backup ServerCyber BackupZFS snapshots
- ავტომატიზაცია
- cloud-initAnsibleTerraformAPI
- მონიტორინგი
- ZabbixPrometheusGrafanaLibreNMS
თანამშრომლობის მოდელი
თანამშრომლობის მოდელი
პროექტი
ერთჯერადი scope: აუდიტი, მიგრაცია ან დანერგვა ფიქსირებული შედეგით.
რეტეინერი
ყოველთვიური საინჟინრო საათები — სპეციალისტზე წვდომა მოთხოვნისამებრ.
Co-Managed
NetWizard და თქვენი შიდა გუნდი ერთად, გაყოფილი პასუხისმგებლობით.
სრულად მართული
შეთანხმებულ საოპერაციო scope-ს მთლიანად ჩვენ ვფლობთ.
გამოყენების შემთხვევები
გამოყენების შემთხვევები
ერთი ჰოსტიდან კლასტერამდე
ყველაფერი ერთ სერვერზეა და მისი გადატვირთვა კომპანიის გაჩერებას ნიშნავს. ვაშენებთ კლასტერს საერთო საცავითა და HA-თი, დატვირთვებს ეტაპებად ვიტანთ.
მეორე ლოკაცია აღდგენისთვის
ბექაპი იმავე შენობაშია, სადაც პროდაქშენი. ვამატებთ მეორე ლოკაციას რეპლიკაციით და ვწერთ, რომელი სერვისი რა რიგით აღდგება.
ჰოსტინგის პლატფორმის აშენება
ვირტუალური სერვერების გაყიდვა ავტომატური provisioning-ითა და ბილინგით — ზუსტად ის, რაც ჯგუფის საკუთარ პლატფორმაზე მუშაობს.
ხშირი კითხვები
ხშირი კითხვები
Ceph გვჭირდება?
ხშირად არა. სამ-ოთხკვანძიან კლასტერზე ZFS რეპლიკაციით უფრო მარტივი და იაფია; Ceph მაშინ ამართლებს, როცა კვანძების რაოდენობა და ზრდის ტემპი მას ამართლებს. არჩევანი capacity-ის გეგმიდან გამომდინარეობს.
თქვენს დატაცენტრში განთავსება შეიძლება?
დიახ — ჯგუფს აქვს საკუთარი დატაცენტრი და ჰოსტინგის პლატფორმა. ორივე ვარიანტს განვიხილავთ: თქვენს ლოკაციაზე აშენება ან ჩვენთან განთავსება, ერთი და იმავე საინჟინრო სტანდარტით.
RPO და RTO რას გვპირდებით?
ციფრს დიზაინამდე არ ვამბობთ. სამიზნეები დატვირთვის კრიტიკულობით განისაზღვრება და ტესტირებული აღდგენით მოწმდება — გამოცხადებული ციფრი, რომელიც არ გატესტილა, დაპირება არაა.
დაკავშირებული