วิธีการจัดเก็บข้อมูลบนเครื่องที่กำลังถูกตัดแบบสุ่ม


13

ฉันมีเครื่องเสมือน (Debian) ทำงานบนโฮสต์เครื่องจริง เครื่องเสมือนทำหน้าที่เป็นบัฟเฟอร์สำหรับข้อมูลที่ได้รับบ่อยผ่านเครือข่ายท้องถิ่น (ระยะเวลาสำหรับข้อมูลนี้คือ 0.5 วินาทีดังนั้นปริมาณงานที่ค่อนข้างสูง) ข้อมูลใด ๆ ที่ได้รับจะถูกเก็บไว้ในเครื่องเสมือนและส่งต่อไปยังเซิร์ฟเวอร์ภายนอกผ่าน UDP ซ้ำ ๆ เมื่อเซิร์ฟเวอร์ภายนอกยอมรับ (เกิน UDP) ว่าได้รับแพ็กเก็ตข้อมูลข้อมูลดั้งเดิมจะถูกลบออกจากเครื่องเสมือนและไม่ได้ส่งไปยังเซิร์ฟเวอร์ภายนอกอีกครั้ง การเชื่อมต่ออินเทอร์เน็ตที่เชื่อมต่อ VM และเซิร์ฟเวอร์ภายนอกไม่น่าเชื่อถือซึ่งหมายความว่าอาจหยุดให้บริการหลายครั้งต่อวัน

เครื่องทางกายภาพที่โฮสต์ VM ได้รับการตัดไฟหลายครั้งต่อวันโดยการสุ่ม ไม่มีวิธีที่จะบอกได้ว่าเกิดเหตุการณ์นี้ขึ้นเมื่อใดและไม่สามารถเพิ่ม UPS แบตเตอรี่หรือโซลูชันที่คล้ายกันในระบบ

เริ่มแรกข้อมูลถูกจัดเก็บในฐานข้อมูล HSQLDB แบบอิงไฟล์บนเครื่องเสมือน อย่างไรก็ตามการตัดไฟบ่อยครั้งในที่สุดทำให้ไฟล์สคริปต์ฐานข้อมูลเสียหาย (ไม่ใช่ระดับระบบไฟล์นั่นคือสามารถอ่านได้ แต่ HSQLDB ไม่สามารถเข้าใจได้) ซึ่งนำไปสู่คำถามของฉัน:

ข้อมูลควรถูกจัดเก็บในสภาพแวดล้อมที่การตัดกระแสไฟฟ้าสามารถเกิดขึ้นบ่อยครั้งได้อย่างไร?

ทางเลือกหนึ่งที่ฉันนึกได้คือการใช้ไฟล์แฟล็ตบันทึกแต่ละแพ็คเก็ตของข้อมูลเป็นไฟล์ในระบบไฟล์ วิธีนี้หากไฟล์เสียหายเนื่องจากการสูญเสียพลังงานก็สามารถถูกละเว้นและส่วนที่เหลือของข้อมูลยังคงเหมือนเดิม สิ่งนี้ทำให้เกิดปัญหาเล็กน้อย แต่ส่วนใหญ่เกี่ยวข้องกับปริมาณข้อมูลที่น่าจะถูกเก็บไว้ในเครื่องเสมือน ที่ 0.5s ระหว่างข้อมูลแต่ละส่วนจะมีการสร้างไฟล์ 1,728,000 ไฟล์ใน 10 วัน อย่างน้อยนี่หมายถึงการใช้ระบบไฟล์ที่มีจำนวน inodes เพิ่มขึ้นเพื่อจัดเก็บข้อมูลนี้ (การตั้งค่าระบบไฟล์ปัจจุบันหมด inodes ที่ ~ 250,000 ข้อความและใช้พื้นที่ดิสก์ 30%) นอกจากนี้ยังเป็นเรื่องยากที่จะจัดการ

มีตัวเลือกอื่น ๆ อีกไหม? มีเอ็นจิ้นฐานข้อมูลที่ทำงานบน Debian ที่ไม่ได้รับความเสียหายจากการตัดไฟหรือไม่? นอกจากนี้ควรใช้ระบบไฟล์ใดสำหรับเรื่องนี้ ext3 คือสิ่งที่ใช้ในขณะนี้

ซอฟต์แวร์ที่ทำงานบนเครื่องเสมือนเขียนด้วย Java 6 ดังนั้นหวังว่าโซลูชันจะไม่เข้ากัน


14
"เครื่องทางกายภาพที่โฮสต์ VM ได้รับการตัดไฟหลายครั้งต่อวันโดยการสุ่มไม่มีทางที่จะบอกได้ว่าจะเกิดอะไรขึ้นและมันเป็นไปไม่ได้ที่จะเพิ่ม UPS แบตเตอรี่หรือโซลูชันที่คล้ายกัน ระบบ." ฉันจริงๆต้องการทราบวิธีการที่เป็นไปได้ อยู่ในสถานีอวกาศนานาชาติหรือเปล่าดังนั้นต้องใช้เงิน 20 ล้านดอลลาร์ในการส่ง UPS หรืออะไรทำนองนั้น?
ceejayoz

3
เครื่องอย่างน้อยมีตัวควบคุม RAID พร้อมแคชแบตเตอรี่สำรองหรือไม่?
Zoredache

4
เราสามารถแนะนำวิธีแก้ปัญหาที่น่าสนใจสร้างสรรค์และอาจแก้ปัญหาได้ในทางทฤษฎี อย่างไรก็ตามเราไม่ทราบว่าไฮเปอร์ไวเซอร์และฮาร์ดแวร์ทำงานอยู่บนโฮสต์ดังนั้นจึงไม่รับประกันว่าการเขียนดิสก์จะถูกเขียนจริง ๆ หรือเขียนตามลำดับที่ถูกต้อง…
pino42

5
@Sevas ดูเหมือนจะไม่ใช่การโทรของคุณ แต่ฉันขอแนะนำว่ามันคุ้มค่าที่จะชี้ให้เห็นว่า 50 เครื่อง UPS ขั้นพื้นฐานราคาถูกจะมีราคา 2,500 เหรียญสหรัฐและไม่ต้องการการบำรุงรักษา (คุณต้องเปลี่ยนพวกเขาหลังจากสองสามปี ) ค่าใช้จ่ายในการพยายามแก้ไขปัญหานี้ในซอฟต์แวร์จะสูงกว่านั้นมากยกเว้นว่าคุณรู้ว่ามีโคเดอร์จำนวนหนึ่งที่ทำงานได้ฟรี อาจเป็นประโยชน์ต่อการจัดการเพื่อแก้ปัญหานี้ในราคา $ 50 / หน่วยแทนที่จะเป็นชั่วโมงหรือชั่วโมงที่มีทักษะ @ 3 ตัวเลขต่อชั่วโมง
HopelessN00b

9
ฟังดูเหมือนโปรแกรมที่เป็นอันตราย ผู้ใช้ไม่ทราบว่า "VM" กำลังทำงานอยู่บนคอมพิวเตอร์ของพวกเขา มันกำลังขโมยข้อมูลจากทั่วทั้งเครือข่าย - จากนั้นทำการส่งข้อมูลผ่านการเชื่อมต่อเดียวเพื่อซ่อนตัวเอง ผู้ใช้ "ปิดและเปิดคอมพิวเตอร์" แบบสุ่มดังนั้นคุณไม่สามารถเพิ่ม UPS ได้
ลอเรนซ์

คำตอบ:


23

วิธีการที่ดีที่สุดของคุณตรงนี้คือการแก้ไขการตัดไฟหรือปรับใช้ระบบที่แตกต่างกันในตำแหน่งที่ดีขึ้น

ใช่มีระบบเช่น redis ซึ่งจะเก็บข้อมูลไว้ใน append-only-log เพื่อเล่นซ้ำ แต่คุณเสี่ยงต่อความเสียหายในระดับที่ต่ำกว่า - เช่นหากระบบไฟล์ของคุณมีสัญญาณรบกวนข้อมูลจากดิสก์อาจมีความเสี่ยง

ฉันขอขอบคุณการปรับปรุงใด ๆ ที่จะเป็นประโยชน์กับคุณ แต่จริงๆแล้วปัญหาไม่ใช่ปัญหาที่สามารถแก้ไขได้ตามสถานการณ์ที่คุณได้อธิบายไว้


8
1 คำตอบที่ถูกต้องคือ "อย่าทำอย่างนั้น"
คริส S

6
+1 การตัดไฟแบบสุ่มในที่สุดจะทำให้ระบบไฟล์ของคุณเสียหาย อิเล็กทรอนิคส์ทำสิ่งที่คาดเดาไม่ได้ในขณะที่พลังของพวกเขาล้มเหลว
แกรนท์

-1 (เสมือน -1) ฉันคิดว่าระบบดังกล่าวจะต้องสร้างบนสมมติฐานที่ว่าการตัดไฟเกิดขึ้นเป็นครั้งคราว สมมติฐานนี้เป็นความจริงในโลกแห่งความเป็นจริงที่คุณต้องจัดการ
Igal Serban

11

วิธีการของคุณสามารถทำงานได้ ฉันขอแนะนำการปรับปรุงบางอย่าง มีคำถามในกองมากเกินไปในการเขียนอะตอมไฟล์ โดยพื้นฐานแล้วคุณจะบันทึกแต่ละแพ็คเก็ตของข้อมูลเป็นไฟล์ชั่วคราวจากนั้นเปลี่ยนชื่อเป็นชื่อสุดท้าย การเปลี่ยนชื่อเป็นการดำเนินการแบบปรมาณูที่จะปลอดภัยจากไฟฟ้าดับ ด้วยวิธีนี้คุณรับประกันได้ว่าไฟล์ทั้งหมดในปลายทางสุดท้ายของคุณจะได้รับการบันทึกอย่างถูกต้องโดยไม่มีความเสียหาย

จากนั้นสิ่งที่คุณสามารถทำได้เพื่อจัดการกับปัญหาของการมีไฟล์หลายล้านไฟล์ cron เป็นงานที่อาจทำงานทุกชั่วโมงที่ใช้ไฟล์ทั้งหมดที่เก่ากว่าหนึ่งชั่วโมงและรวมเข้าเป็นไฟล์ขนาดใหญ่ไฟล์เดียวโดยใช้การดำเนินการไฟล์อะตอมมิกอีกครั้งเพื่อให้งานนี้ทำงานได้อย่างปลอดภัยแม้ในช่วงที่ไฟฟ้าขัดข้องแล้วจึงลบไฟล์เก่า ชนิดของการหมุนบันทึกเช่น ไฟล์หนึ่งชั่วโมงจะมีค่าประมาณ 7,200 ไฟล์ ดังนั้น ณ เวลาใดก็ตามคุณไม่ควรมีไฟล์มากกว่า 20,000 ไฟล์บนดิสก์


1
ไม่ใช่คำตอบที่ไม่ถูกต้อง แต่ปัญหาที่เกิดขึ้นกับมันคือการสมมติว่าการเขียนตัวเองเป็นการดำเนินการแบบอะตอมมิกซึ่งไม่ใช่ ดังนั้นไฟฟ้าขัดข้องในเวลาที่ผิดยังสามารถสร้างข้อมูลหรือความเสียหายของ FS ได้ อาจเกี่ยวกับตัวเลือกที่ดีที่สุดในการแก้ไขกำลังไฟฟ้าหรือเสียบสิ่งต่างๆเข้ากับ UPS ดังนั้น +1
HopelessN00b


ใช่การเปลี่ยนชื่อไฟล์เมื่อมีการเขียนเป็นการดำเนินการปรมาณู การเขียนไฟล์ในตอนแรกไม่ใช่
HopelessN00b

3
@ HopelessN00b ไม่สำคัญว่าไฟล์ใหม่นั้นเขียนได้ครึ่งหนึ่งหรือเสียหาย คุณมีไฟล์เก่าซึ่งอยู่ในสภาพดี เมื่อคุณกู้คืนระบบคุณทำลายไฟล์ที่เขียนครึ่งหนึ่ง
DJClayworth

2
@ HopelessN00b แน่นอน! เฉพาะไฟล์ชั่วคราวในไดเรกทอรีชั่วคราวเท่านั้นที่สามารถบอกได้ว่าสามารถเขียนได้ครึ่งเดียว ไฟล์ทั้งหมดในไดเรกทอรีปลายทางสุดท้ายของคุณจะไม่เสียหายและอยู่บนดิสก์อย่างปลอดภัยเสมอ
Marwan Alsabbagh

7

คุณติดตั้งยูพีเอสหรือการ์ด RAID ที่มีแคชการเขียนสำรองแบตเตอรี่ลงในระบบและเพียงแค่ $ 49.95คุณจะทำสิ่งที่เป็นไปไม่ได้ให้สำเร็จโดยใช้ซอฟต์แวร์เพียงอย่างเดียว

การอ้างสิทธิ์ของคุณว่าไม่สามารถเชื่อมต่อเซิร์ฟเวอร์นี้กับ UPS หรือแบตเตอรีได้ ... ไม่น่าเชื่อ


9
ความโง่เขลาของข้าราชการนั้นเชื่อได้เสมอ
Dan เล่นซอโดย Firelight

3
@DanNeely My PHB won't let me hook this up to a UPS/batteryเป็นสิ่งที่แตกต่างอย่างมากจากการที่it is not possible to add a UPS, a battery, or a similar solution to the system. จะไม่อวดอ้าง เกินไป แต่มันเป็นความแตกต่างที่สำคัญเพราะมันเปลี่ยนแนวทางและวิธีแก้ปัญหาที่มีให้
HopelessN00b

หรือตามที่กล่าวไว้ในที่อื่นผู้ใช้คอมพิวเตอร์ที่ถูกแย่งชิงจะประหลาดใจถ้าฉันขอให้ติดตั้ง UPS สถานการณ์นั้นไม่น่าเชื่อเลย ทุกคนจะยอมรับ UPS ด้วยข้อมูลที่เสียหายเนื่องจากเหตุผลทางธุรกิจที่เหมาะสม
WernerCD

@WernerCD ฉันต้องการให้คุณพบ CIO ของเรา ในขณะที่ฉันยอมรับว่าการไฮแจ็กคอมพิวเตอร์ของใครบางคนเป็นกรณีใช้งานที่เป็นไปได้สำหรับเรื่องนี้ฉันก็สามารถนึกถึงคอมพิวเตอร์ที่ถูกกฎหมายได้เช่นกันดังนั้นฉันจะให้ประโยชน์กับคนที่สงสัย ลองนึกถึงระบบและตัวควบคุมแบบฝังตัวหรือเช่น Raspberry Pi - อาจเป็นกรณีที่ "คอมพิวเตอร์" ที่คุณใช้มีค่าน้อยกว่า $ 50 ที่ต้องใช้เพื่อแนบกับ UPS
HopelessN00b

แม้ว่าคอมพิวเตอร์จะมีค่าน้อยกว่า UPS ราคา $ 50 แต่เป็นข้อมูลในคอมพิวเตอร์ที่มีค่าบางอย่าง Google สร้างขึ้นบนคอมพิวเตอร์ "ไร้ค่า" สำคัญกว่าค่าใช้จ่ายของ CPU คือค่าใช้จ่ายของข้อมูลที่สูญหาย, กำลังคนที่สูญเสียไป (การผจญภัยการเขียนโปรแกรมนี้, การติดตามความเสียหายของข้อมูล, การติดตามข้อผิดพลาดในระบบเก่ารวมทั้งส่วนใหม่นี้) โปรด บริษัท ต่อไป) และอื่น ๆ
WernerCD

5

เมานต์ทั้งระบบเป็นแบบอ่านอย่างเดียวยกเว้นอุปกรณ์บล็อกที่เก็บข้อมูลทั้งหมดของคุณ ใช้อุปกรณ์บล็อกนั้นโดยตรงและใช้กลไกการจัดเก็บข้อมูลของคุณเองโดยใช้อุปกรณ์บล็อกดิบนั้น


3
... และลงทุนในการ์ดคอนโทรลเลอร์ดิสก์ที่สำรองแบตเตอรีและตรวจสอบให้แน่ใจว่าไม่มีแคชการเขียนบนดิสก์หรือคุณยังเมาอยู่
voretaq7

มาที่นี่เพื่อบอกว่าพวกเขาควรจะบูทออกจากระบบ Live-CD หรือ ROM เทียบเท่ากับหน่วยความจำโซลิดสเตตบางตัวที่ใช้กับโซลูชั่นไฟล์แฟล็ต
Mark Allen

แคชการเขียนสามารถปิดใช้งานได้ วิธีนี้ใช้ได้ แนะนำให้ผนวกเฉพาะกลไกการจัดเก็บข้อมูล บล็อกถูกเขียนแบบอะตอม (ฉันถือว่า) เพื่อให้คุณสามารถมีสอง "ตัวชี้" บล็อกที่ชี้ไปที่จุดเริ่มต้นและจุดสิ้นสุดของส่วนที่มีข้อมูลใหม่ / สิ่งที่ต้องทำ พอยน์เตอร์จะได้รับการอัปเดตหลังจากเขียน / เสร็จสิ้นข้อมูล ควรปิดใช้งาน NCQ ด้วย
sleeplessnerd
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.