Broadcom के बाद VMware छोड़ना: जाँची हुई माइग्रेशन गाइड

Broadcom के बाद VMware छोड़ना: जाँची हुई माइग्रेशन गाइड

Broadcom के बाद VMware छोड़ना: जाँची हुई माइग्रेशन गाइड

संक्षिप्त उत्तर (2026-11-03 को जाँचा गया): VMware को खरीदने के बाद से Broadcom ने स्थायी लाइसेंस बेचना बंद कर दिया, उत्पाद सूची को दो सब्सक्रिप्शन बंडलों में समेट दिया, यूरोप में अपना पुराना क्लाउड-पार्टनर प्रोग्राम बंद कर दिया और इस पतझड़ में VDDK का सार्वजनिक डाउनलोड हटा दिया। VDDK वह डिस्क लाइब्रेरी है जिससे ज़्यादातर माइग्रेशन टूल VMware डिस्क पढ़ते हैं। आज The Register ने इस लाइब्रेरी के एक ओपन-सोर्स, केवल-पढ़ने वाले विकल्प की खबर दी है। फिर भी बाहर निकलने के हर रास्ते को VDDK की ज़रूरत नहीं है: OVA एक्सपोर्ट और डिस्क कन्वर्शन में VMware का कोई कोड इस्तेमाल नहीं होता। नीचे: तारीख सहित बदलाव, किसी EU टीम के लिए व्यावहारिक विकल्प, चरण-दर-चरण माइग्रेशन, और एक कन्वर्टर जिसे हमने असली VMware-फ़ॉर्मेट एक्सपोर्ट पर चलाया।

स्रोत। "Architect creates open-source replacement for VM migration tool VMware has hidden" (Simon Sharwood, The Register का लेख, 2026-11-03)। बाकी तथ्यों के लिंक वहीं दिए गए हैं जहाँ वे आते हैं। आपका अपना अनुबंध सार्वजनिक शर्तों से अलग हो सकता है, इसलिए लाइसेंस का विवरण अपने रीसेलर से पक्का कर लें।

Broadcom ने क्या बदला, तारीखों के साथ

तारीख बदलाव स्रोत
2023-12-11 स्थायी लाइसेंस और सपोर्ट रिन्यूअल की बिक्री बंद; पेशकश घटाकर VMware Cloud Foundation (VCF) और vSphere Foundation (VVF) सब्सक्रिप्शन तक सीमित Broadcom की खबर, Krish Prasad
2025-03-28 डिस्ट्रीब्यूटर Arrow ने पार्टनरों को बताया कि 2025-04-10 से हर प्रोडक्ट लाइन का न्यूनतम ऑर्डर 16 से बढ़कर 72 कोर होगा The Register की रिपोर्ट
2026-01-26 EEA में क्लाउड-प्रोवाइडर (VCSP) अनुबंधों का नवीनीकरण नहीं; खुली डील 2026-03-31 तक बंद होनी हैं; उसके बाद प्रोग्राम केवल आमंत्रण पर The Register की रिपोर्ट, 2026-01-31
अगस्त-सितंबर 2026 VDDK सार्वजनिक डाउनलोड से हटाया गया: "The VDDK is not a customer entitlement" (VDDK ग्राहक का अधिकार नहीं है), पहुँच चुनिंदा TAP पार्टनरों के ज़रिए TechTarget की रिपोर्ट, 2026-09-09
2026-11-03 Andrija Panić का OpenVDDK: Apache लाइसेंस वाला, libvixDiskLib.so.8.0.3 की जगह सीधे लगने वाला केवल-पढ़ने वाला विकल्प, जो "contains no VMware code" (इसमें VMware का कोई कोड नहीं है) The Register, 2026-11-03

दो सावधानियाँ। 72-कोर की न्यूनतम सीमा एक डिस्ट्रीब्यूटर ने बताई थी, हमें यह किसी Broadcom पेज पर नहीं मिली: Broadcom का कोर गिनने वाला लेख (KB 313548, 2026-11-03 को जाँचा गया) कहता है "You must license a minimum of 16 physical cores for each CPU" (हर CPU के लिए कम से कम 16 फ़िज़िकल कोर का लाइसेंस लेना होगा), और कुछ रीसेलर कहते हैं कि 72-कोर की न्यूनतम ऑर्डर सीमा फिर से हटा दी गई। अपने कोटेशन में कोर की संख्या लिखित में माँगें। और EU वाला मामला अभी खुला है: क्लाउड उद्योग समूह CISPE ने जुलाई 2025 में EU General Court से विलय को कमीशन की मंज़ूरी रद्द करने को कहा (केस T-503/25); हमें अब तक कोई फ़ैसला नहीं मिला।

VDDK क्यों मायने रखता है, और कौन से रास्ते इससे बचते हैं

VDDK की लाइब्रेरी, libvixDiskLib, किसी टूल को उन VM की डिस्क पढ़ने देती है जो अभी भी vSphere में चल रहे हैं। The Register इसे लोड करने वाले टूल में virt-v2v, nbdkit, Forklift / MTV इम्पोर्टर, Apache CloudStack और इन-हाउस स्क्रिप्ट गिनाता है। Windows Admin Center के लिए Microsoft का VM Conversion एक्सटेंशन (vCenter से Hyper-V, Change Block Tracking के ज़रिए वॉर्म सिंक के साथ) इसके डॉक्यूमेंटेशन (2026-02-20 को अपडेट) में अभी भी preview चिह्नित है, और लॉन्च कवरेज इसकी पूर्व-आवश्यकताओं में VDDK गिनाता है। इन सभी के लिए OpenVDDK नया विकल्प है, हालाँकि इसके लेखक ख़ुद चेतावनी देते हैं कि टेस्टरों की रिपोर्ट "not independently audited customer endorsements" (स्वतंत्र रूप से ऑडिट न की गई ग्राहक सिफ़ारिशें) हैं।

बिना किसी VDDK वाले रास्ते, virt-v2v के VMware इनपुट डॉक्यूमेंटेशन के अनुसार (2026-11-03 को जाँचा गया): OVA एक्सपोर्ट (-i ova), NFS पर या SSH के ज़रिए VM की फ़ाइलें (-i vmx, -it ssh), NFC, और सामान्य vCenter HTTPS रास्ता, जिसे डॉक्यूमेंटेशन "the slowest method" (सबसे धीमा तरीका) कहता है। Proxmox VE का ESXi इम्पोर्ट विज़ार्ड, जिसकी घोषणा 2024-03-27 को हुई, अपने Rust यूज़र-स्पेस फ़ाइलसिस्टम के साथ ESXi API के ज़रिए डिस्क पढ़ता है और ESXi 6.5 से 8.0 पर परखा गया है (Proxmox फ़ोरम की घोषणा)।

कहाँ जाएँ: पाँच व्यावहारिक विकल्प

विकल्प कब उपयुक्त किस बात का ध्यान रखें
आपके हार्डवेयर पर Proxmox VE (KVM) 3+ होस्ट, ऐसी टीम जो GUI और क्लस्टरिंग चाहती है अपग्रेड, स्टोरेज (ZFS, Ceph) और सपोर्ट आपकी ज़िम्मेदारी
OpenStack कई टेनेंट, सब कुछ API के ज़रिए चलाना भारी; केवल बड़े पैमाने पर फ़ायदेमंद
Hyper-V (Windows Server) Windows-प्रधान इन्फ्रास्ट्रक्चर, Datacenter लाइसेंस पहले से भुगतान किए हुए Microsoft के टूल को पहले Linux गेस्ट में Hyper-V ड्राइवर चाहिए
क्लाउड सर्वर (KVM) कुछ से लेकर कुछ दर्जन VM, हाइपरवाइज़र चलाने की इच्छा नहीं हर VM का अलग इम्पोर्ट, नए IP पते
डेडिकेटेड सर्वर + आपका अपना हाइपरवाइज़र स्थिर लोड, आपको पूरी मशीन चाहिए हाइपरवाइज़र आप ख़ुद चलाते और पैच करते हैं

पाँच चरणों में VM माइग्रेट करें

  1. इन्वेंटरी और सफ़ाई। फ़र्मवेयर (BIOS या EFI), डिस्क कंट्रोलर, NIC प्रकार, स्टैटिक IP और MAC पते से जुड़ा कोई भी लाइसेंस नोट करें। स्नैपशॉट हटाएँ या मर्ज करें ताकि आप एक मौजूदा डिस्क एक्सपोर्ट करें।
  2. गेस्ट को तब तैयार करें जब वह अभी VMware पर चल रहा हो। Windows: virtio ड्राइवर (virtio-win) अभी इंस्टॉल करें; इनके बिना virtio डिस्क पर ले जाया गया Windows गेस्ट बूट नहीं होता। Linux: virtio ड्राइवर कर्नेल में हैं, लेकिन host-only initramfs उन्हें छोड़ सकता है; lsinitramfs या lsinitrd से जाँचें और ज़रूरत हो तो उसे फिर से बनाएँ।
  3. एक्सपोर्ट करें या कनेक्ट करें। VM बंद करें और OVF / OVA एक्सपोर्ट करें (vSphere Client "Export OVF Template", या ovftool), या virt-v2v या Proxmox विज़ार्ड को उसे खींचने दें।
  4. कन्वर्ट करें। केवल डिस्क qemu-img से, पूरा गेस्ट virt-v2v से (यह ड्राइवर भी ठीक करता है), या OVF से सीधे Proxmox में।
  5. कंसोल पर बूट करें, फिर सफ़ाई करें। NIC का नाम और IP जाँचें, VMware Tools या open-vm-tools हटाएँ, qemu-guest-agent इंस्टॉल करें।
qemu-img convert -p -f vmdk -O qcow2 disk1.vmdk disk1.qcow2
virt-v2v -i ova VM.ova -o local -os /var/tmp -of qcow2
qm importovf 120 VM.ovf local-lvm

ये हर टूल के मैनुअल में दिए गए दस्तावेज़ित रूप हैं; इन तीनों को हमने यहाँ नहीं चलाया। जो कन्वर्शन हमने चलाया, वह नीचे है।

परखा गया: कन्वर्शन असल में क्या करता है (ova2raw.js)

इसके हिस्से दिखाने के लिए हमने कन्वर्शन को बिना किसी डिपेंडेंसी के Bun की लगभग 100 पंक्तियों में लिखा। यह OVA (एक सामान्य tar) खोलता है, SHA-256 मैनिफ़ेस्ट जाँचता है, OVF जो हार्डवेयर माँगता है उसे प्रिंट करता है, streamOptimized VMDK को grain-दर-grain एक sparse raw इमेज में खोलता है और GPT जाँचता है। हमने इसे Ubuntu का आधिकारिक 24.04 OVA दिया, जो एक असली VMware-फ़ॉर्मेट एक्सपोर्ट है: noble-server-cloudimg-amd64.ova, 2026-10-17 का बिल्ड, जिसका SHA-256 Ubuntu के SHA256SUMS से मेल खाता था। इसे ova2raw.js नाम से सेव करें:

// ova2raw.js - check a VMware OVA export and turn its disk into a raw image for KVM
// usage: bun ova2raw.js <export.ova> <out.raw>
import { openSync, readSync, writeSync, ftruncateSync, closeSync, fstatSync } from 'node:fs'
import { inflateSync } from 'node:zlib'
import { createHash } from 'node:crypto'

const [ova, out] = process.argv.slice(2)
const fd = openSync(ova, 'r')
const read = (pos, len) => {
  const b = Buffer.alloc(len)
  readSync(fd, b, 0, len, pos)
  return b
}

// 1. an OVA is a plain tar: list its members
const files = {}
for (let o = 0; o + 512 <= fstatSync(fd).size; ) {
  const h = read(o, 512)
  if (h.every(x => x === 0)) break
  const name = h.toString('utf8', 0, 100).replace(/\0.*$/s, '')
  const size = parseInt(h.toString('ascii', 124, 136).replace(/\0.*$/s, '').trim(), 8)
  files[name] = { pos: o + 512, size }
  o += 512 + Math.ceil(size / 512) * 512
}
const find = ext => Object.keys(files).find(n => n.endsWith(ext))
const text = n => read(files[n].pos, files[n].size).toString('utf8')
console.log('OVA members:', Object.entries(files).map(([n, f]) => `${n} (${f.size} B)`).join(', '))

// 2. the .mf manifest: every member's SHA-256 must match
const mf = find('.mf')
for (const line of mf ? text(mf).split('\n') : []) {
  const m = line.match(/^SHA(1|256)\((.+)\)\s*=\s*([0-9a-f]+)/i)
  if (!m || !files[m[2]]) continue
  const h = createHash('sha' + m[1])
  const f = files[m[2]]
  for (let p = 0; p < f.size; p += 1 << 24) h.update(read(f.pos + p, Math.min(1 << 24, f.size - p)))
  console.log(`  manifest ${m[2]}: ${h.digest('hex') === m[3].toLowerCase() ? 'OK' : 'MISMATCH'}`)
}

// 3. the .ovf descriptor: what the VM expects from its hardware
const ovf = text(find('.ovf'))
const items = [...ovf.matchAll(/<(?:ovf:)?Item\b[\s\S]*?<\/(?:ovf:)?Item>/g)].map(x => x[0])
const tag = (s, t) => s.match(new RegExp(`<(?:rasd:)?${t}>([^<]*)<`))?.[1]
const kind = { 3: 'CPU', 4: 'RAM', 5: 'IDE controller', 6: 'SCSI controller', 10: 'NIC', 17: 'disk', 20: 'SATA controller' }
console.log('OVF:', ovf.match(/vmw:osType="([^"]+)"/)?.[1] ?? '?', '| firmware',
  ovf.match(/key="firmware" ovf:value="([^"]+)"/)?.[1] ?? 'bios (default)')
for (const it of items) {
  const k = kind[tag(it, 'ResourceType')]
  if (k) console.log(`  ${k.padEnd(16)} ${tag(it, 'ElementName') ?? ''} ${tag(it, 'ResourceSubType') ?? ''} ${tag(it, 'VirtualQuantity') ?? ''}`.trimEnd())
}

// 4. the streamOptimized VMDK: a header, then compressed grains and markers
const vmdk = files[find('.vmdk')]
const hd = read(vmdk.pos, 512)
if (hd.readUInt32LE(0) !== 0x564d444b) throw new Error('not a sparse VMDK (no KDMV magic)')
const capacity = Number(hd.readBigUInt64LE(12)) * 512
const desc = read(vmdk.pos + Number(hd.readBigUInt64LE(28)) * 512, Number(hd.readBigUInt64LE(36)) * 512)
console.log(`VMDK ${desc.toString().match(/createType="([^"]+)"/)?.[1]}, virtual size ${capacity} B, grain ${Number(hd.readBigUInt64LE(20)) * 512} B`)

const ofd = openSync(out, 'w')
ftruncateSync(ofd, capacity) // sparse: unwritten grains stay holes = zeros
let pos = Number(hd.readBigUInt64LE(64)) * 512
let grains = 0
let written = 0
while (pos < vmdk.size) {
  const m = read(vmdk.pos + pos, 512)
  const val = Number(m.readBigUInt64LE(0))
  const size = m.readUInt32LE(8)
  if (size) { // compressed grain: lba, size, zlib data
    const raw = inflateSync(read(vmdk.pos + pos + 12, size))
    writeSync(ofd, raw, 0, raw.length, val * 512)
    grains++
    written += raw.length
    pos += Math.ceil((12 + size) / 512) * 512
  } else if (m.readUInt32LE(12) === 0) break // end-of-stream marker
  else pos += 512 + val * 512 // grain table / directory / footer: metadata only
}
closeSync(ofd)
console.log(`Wrote ${out}: ${grains} grains, ${written} B of data in ${capacity} B`)

// 5. check the result: a valid GPT, and the file systems where the partitions say they are
const rfd = openSync(out, 'r')
const at = (p, l) => { const b = Buffer.alloc(l); readSync(rfd, b, 0, l, p); return b }
const gpt = at(512, 92)
const crc = Buffer.from(gpt)
crc.writeUInt32LE(0, 16)
console.log(`GPT "${gpt.toString('ascii', 0, 8)}", header CRC ${(Bun.hash.crc32(crc) >>> 0) === gpt.readUInt32LE(16) ? 'OK' : 'BAD'}`)
const n = gpt.readUInt32LE(80)
const es = gpt.readUInt32LE(84)
const ents = at(Number(gpt.readBigUInt64LE(72)) * 512, n * es)
console.log(`  partition array CRC ${(Bun.hash.crc32(ents) >>> 0) === gpt.readUInt32LE(88) ? 'OK' : 'BAD'}`)
for (let i = 0; i < n; i++) {
  const e = ents.subarray(i * es, (i + 1) * es)
  if (e.subarray(0, 16).every(x => x === 0)) continue
  const first = Number(e.readBigUInt64LE(32))
  const last = Number(e.readBigUInt64LE(40))
  const sb = at(first * 512 + 1024, 136)
  const fs = sb.readUInt16LE(56) === 0xef53 ? `ext4 label "${sb.toString('ascii', 120, 136).replace(/\0.*$/s, '')}"`
    : at(first * 512, 512).toString('ascii', 82, 87) === 'FAT32' ? 'FAT32 (EFI system partition)'
    : e.toString('ascii', 0, 16) === 'Hah!IdontNeedEFI' ? 'BIOS boot (GRUB for legacy BIOS)' : 'unknown'
  console.log(`  p${i + 1} ${String((last - first + 1) * 512 / 2 ** 20 | 0).padStart(5)} MiB  ${fs}`)
}
bun ova2raw.js noble-server-cloudimg-amd64.ova noble.raw

आउटपुट, DCXV Cloud सर्वर पर Bun 1.4.4 के साथ 2026-11-03 को चलाया गया:

OVA members: ubuntu-noble-24.04-cloudimg.ovf (11186 B), ubuntu-noble-24.04-cloudimg.mf (213 B), ubuntu-noble-24.04-cloudimg.vmdk (590749696 B)
  manifest ubuntu-noble-24.04-cloudimg.vmdk: OK
  manifest ubuntu-noble-24.04-cloudimg.ovf: OK
OVF: ubuntu64Guest | firmware bios (default)
  CPU              2 virtual CPU(s)  2
  RAM              1024MB of memory  1024
  SCSI controller  SCSI Controller 0 VirtualSCSI
  IDE controller   VirtualIDEController 1
  IDE controller   VirtualIDEController 0
  disk             Hard Disk 1
  NIC              Ethernet 1 VmxNet3
VMDK streamOptimized, virtual size 10737418240 B, grain 65536 B
Wrote noble.raw: 28663 grains, 1878458368 B of data in 10737418240 B
GPT "EFI PART", header CRC OK
  partition array CRC OK
  p1  2558 MiB  ext4 label "cloudimg-rootfs"
  p14     4 MiB  BIOS boot (GRUB for legacy BIOS)
  p15   106 MiB  FAT32 (EFI system partition)
  p16   913 MiB  ext4 label "BOOT"

उस सर्वर पर तीन रन में 14.6 से 16.2 s वॉल-क्लॉक समय लगा। raw फ़ाइल का आकार 10 GiB है और डिस्क पर यह 1.8 GB लेती है।

कटओवर से पहले आउटपुट आपको क्या बताता है

  1. VmxNet3 और VirtualSCSI VMware डिवाइस हैं। KVM पर ये virtio-net और virtio-blk या virtio-scsi बन जाते हैं। पहले बूट से पहले गेस्ट को दोनों के ड्राइवर चाहिए, और नेटवर्क इंटरफ़ेस को आमतौर पर नया नाम मिलता है, इसलिए पुराने नाम से जुड़ा स्टैटिक IP चालू नहीं होगा। पहले बूट के लिए कंसोल इस्तेमाल करें।
  2. फ़र्मवेयर मेल खाना चाहिए। यह OVF कुछ सेट नहीं करता, इसलिए यह BIOS है; डिस्क में BIOS boot और EFI system पार्टीशन दोनों हैं, इसलिए यह दोनों तरह से बूट होती है। firmware=efi के साथ एक्सपोर्ट किए गए VM को टार्गेट पर UEFI (OVMF) चाहिए, वरना उसे कोई बूट लोडर नहीं मिलता।
  3. thin डिस्क तभी thin रहती है जब आप उसे वैसा रखें। 10 GiB वर्चुअल, 1.8 GB डेटा। sparse को समझने वाले टूल से कॉपी करें (cp --sparse=always, rsync -S) या qcow2 इस्तेमाल करें, वरना आप शून्य ढोते और स्टोर करते रहेंगे।
  4. मैनिफ़ेस्ट ही आपकी ट्रांसफ़र जाँच है। साइटों के बीच हर कॉपी के बाद SHA-256 सत्यापित करें: बीच में कटा हुआ अपलोड बिना किसी शिकायत के ऐसी डिस्क में बदल जाता है जो बाद में फ़ेल होती है।

डाउनटाइम की योजना बनाएँ

कोल्ड माइग्रेशन की लागत है एक्सपोर्ट + ट्रांसफ़र + कन्वर्ट + पहला बूट। एक टेस्ट VM पर हर चरण का समय नापें, फिर गुणा करें। ट्रांसफ़र का हिसाब (हमारा, प्रोटोकॉल ओवरहेड से पहले): 1 Gbit/s पर 1.8 GB में लगभग 15 s, 1 TB में लगभग 2.2 घंटे। वॉर्म टूल VM चलते हुए कॉपी करते हैं और अंत में केवल बदले हुए ब्लॉक भेजते हैं; The Register के टेस्टर Forklift और MTV के साथ कोल्ड और वॉर्म रन की रिपोर्ट देते हैं। डेटाबेस और व्यस्त ऐप के लिए रेप्लिकेशन और DNS स्विच किसी भी डिस्क कॉपी से बेहतर है: पहले TTL घटाएँ (देखें DNS प्रोपेगेशन और TTL) और क्लाउड सर्वर पर माइग्रेट करने की गाइड की चेकलिस्ट का पालन करें।

DCXV क्लाउड या डेडिकेटेड सर्वर कब उपयुक्त हैं

  • कुछ VM, कोई हाइपरवाइज़र टीम नहीं: हमारे क्लाउड सर्वर virtio डिस्क के साथ KVM पर चलते हैं। पैनल में रीइंस्टॉल -> "अपनी इमेज (URL)" https के ज़रिए qcow2, raw या vmdk फ़ाइल लेता है; प्लान की डिस्क से बड़ी इमेज डिस्क को बढ़ा देती है और उसका बिल डिस्क अपग्रेड के रूप में आता है, और नेटवर्क सेटिंग केवल तभी लागू होती हैं जब इमेज में cloud-init हो। प्लान EUR 15.00/माह से शुरू (2 vCPU, 4 GB RAM, 40 GB; 2026-11-03 को जाँचा गया, VAT के बिना)।
  • दर्जनों VM या आपका अपना Proxmox क्लस्टर: डेडिकेटेड सर्वर EUR 210/माह से, आपकी पसंद के हाइपरवाइज़र के साथ।
  • Windows गेस्ट: हम Windows Server लाइसेंस रीसेल करते हैं; माइग्रेशन से पहले पूछें ताकि पहले दिन से लाइसेंस तैयार रहे।

दोनों प्राग और कोविल्या में हमारे Tier III डेटा सेंटरों में चलते हैं।

हमारे साथ माइग्रेशन की योजना बनाएँ

एक्सपोर्ट किए गए किसी एक VM पर ova2raw.js चलाएँ और उसके आउटपुट की हार्डवेयर पंक्तियाँ sales@dcxv.com पर भेजें, या एक क्लाउड सर्वर शुरू करें और इम्पोर्ट ख़ुद परखें।

Broadcom के बाद VMware छोड़ना: जाँची हुई माइग्रेशन गाइड
clouddedicatedinfrastructure

Broadcom के बाद VMware छोड़ना: जाँची हुई माइग्रेशन गाइड

Broadcom ने स्थायी लाइसेंस बंद किए, पार्टनर घटाए और VDDK छिपाया। EU टीमें VM को KVM, Proxmox या Hyper-V पर कैसे ले जाएँ: तारीखें, तथ्य और परखा हुआ OVA कन्वर्टर।

DNS प्रसार समय: Cloudflare के 3 सेकंड बनाम आपका TTL
networkingcloudinfrastructure

DNS प्रसार समय: Cloudflare के 3 सेकंड बनाम आपका TTL

Cloudflare ने DNS बिल्ड देरी लगभग 3.3 s कर दी। फिर भी सर्वर बदलने पर TTL, नेगेटिव कैश और .com के 2 दिन के डेलिगेशन का इंतज़ार होता है। हमने दो ज़ोन पर मापा।

10,000 अमेरिकी परिषद टिप्पणियाँ: डेटा सेंटर ग्राहकों का सबक
clouddedicatedinfrastructure

10,000 अमेरिकी परिषद टिप्पणियाँ: डेटा सेंटर ग्राहकों का सबक

एक नया डेटासेट अमेरिकी परिषदों में डेटा सेंटर पर 10,202 टिप्पणियों को कोड करता है: 90.5% विरोध में, पानी सबसे ऊपर। हमने इसे दोबारा गिना और अर्थ समझाया।

AWS सपोर्ट और बिलिंग: EU टीमों के लिए जांची-परखी गाइड
cloudpricingcompare

AWS सपोर्ट और बिलिंग: EU टीमों के लिए जांची-परखी गाइड

AWS के सपोर्ट प्लान और कीमतें, बिलिंग डेटा में देरी, egress शुल्क, लागत जांचने की एक स्क्रिप्ट, और कब फिक्स्ड कीमत वाला EU प्रोवाइडर बेहतर विकल्प होता है.

क्लाउड सर्वर पर मेमोरी लेटेंसी: अनुमान नहीं, माप
clouddedicatedinfrastructure

क्लाउड सर्वर पर मेमोरी लेटेंसी: अनुमान नहीं, माप

एक वायरल पोस्ट कहती है कि व्यस्त CPU अक्सर बस RAM का इंतज़ार करता है। हमने अपने क्लाउड सर्वर पर L1 से DRAM तक की लेटेंसी मापी और उसका मतलब समझाया।