راهاندازی EPLAN در شبکه با SQL Server؛ وقتی نصب نرمافزار فقط نصف ماجراست
- علی پریزاد
فرض کنید EPLAN روی چند سیستم شرکت نصب شده و هر کاربر بخشی از اطلاعات را روی کامپیوتر خودش نگه میدارد. دیتابیس قطعات یکجا است، پروژهها جای دیگری هستند، ماکروها بین چند سیستم کپی شدهاند و با تغییر یک سیستم، بقیه کاربران همان اطلاعات را نمیبینند.
تا زمانی که یک یا دو نفر با پروژههای کوچک کار میکنند، شاید این وضعیت خیلی آزاردهنده نباشد. اما وقتی EPLAN به ابزار کاری یک تیم مهندسی تبدیل میشود، پراکندگی اطلاعات خیلی زود خودش را نشان میدهد: نسخههای متفاوت یک پروژه، دوبارهکاری، دیتابیس قطعات غیرهمسان، مشکل در Backup و وابستگی اطلاعات مهم شرکت به کامپیوتر یک کاربر.
راهحل اصولی، مرکزی کردن بخشهایی از EPLAN روی زیرساخت شبکه است؛ اما یک نکته مهم وجود دارد: راهاندازی EPLAN تحت شبکه فقط کار EPLAN نیست.
بخشی از کار داخل EPLAN انجام میشود، اما SQL Server، Windows Server، File Sharing، Permission، Firewall، Backup و ارتباط Clientها عملاً در حوزه زیرساخت IT قرار میگیرند. اگر سازمان برای این بخش نیاز به زیرساخت مناسب دارد، صفحه سرویسهای شبکه و نرمافزار تیشتا دقیقاً به همین لایههای سرور، SQL، فایل شیرینگ و دسترسی کاربران مربوط است.
چرا اصلاً دیتابیس EPLAN را روی SQL Server ببریم؟
یکی از مهمترین کاندیداهای مرکزیسازی، Parts Database است. بهجای اینکه هر کاربر دیتابیس قطعات خودش را داشته باشد، میتوان یک دیتابیس مشترک روی SQL Server ایجاد کرد تا کاربران EPLAN به یک منبع مرکزی متصل شوند.
مزیت اصلی فقط کم شدن حجم اطلاعات روی Client نیست. ارزش واقعی زمانی مشخص میشود که یک قطعه، مشخصات فنی یا اطلاعات مرتبط اصلاح میشود و قرار است تیم طراحی از یک مرجع مشترک استفاده کند.
اما اینجا یک اشتباه رایج وجود دارد: SQL Server قرار نیست تمام فایلهای EPLAN را داخل خودش نگه دارد. دیتابیس قطعات یک موضوع است و فایلهای Projects، Macros، Templates، Forms، Symbols و سایر Master Data موضوع دیگری هستند.
یک دلیل عملی دیگر: فضای هارد سیستمهای مهندسی
همیشه دلیل انتقال بخشی از اطلاعات EPLAN به سرور، چندکاربره شدن یا یکپارچه کردن دیتابیس نیست. گاهی مسئله خیلی سادهتر است: فضای سیستم کاربران دیگر جواب نمیدهد.
هنوز در بسیاری از شرکتها Workstationهای مهندسی با SSDهای 128 یا 256 گیگابایتی در حال استفاده هستند. بخشی از این فضا را ویندوز، آپدیتها و نرمافزارهای دیگر اشغال میکنند و وقتی EPLAN، پروژههای متعدد، Macroها، تصاویر، Documents، فایلهای DXF/DWG و سایر Master Dataها به آن اضافه میشوند، فضای آزاد سیستم میتواند خیلی سریع محدود شود.
این فقط یک مسئله مربوط به راحتی کاربر نیست. EPLAN برای Workstation در مشخصات پیشنهادی خود 500GB فضای ذخیرهسازی را ذکر میکند. بنابراین در سیستمی که SSD کوچکتری دارد، نگهداری تمام اطلاعات مهندسی بهصورت Local از ابتدا انتخاب ایدهآلی نیست.
البته راهحل این نیست که هر چیزی را از Client برداریم و روی Server بریزیم. خود نرمافزار EPLAN، Cache و بخشهایی که به اجرای سریع نرمافزار مربوط هستند بهتر است روی SSD سیستم کاربر باقی بمانند؛ اما Projects و Master Dataهای مشترک که قرار است چند کاربر به آنها دسترسی داشته باشند، کاندیدای مناسبی برای انتقال به File Server هستند.
این کار چند مزیت را همزمان ایجاد میکند: فضای Local آزادتر میماند، اطلاعات بین چند سیستم تکرار نمیشود، نسخه واحدی از پروژهها و منابع مهندسی در اختیار تیم قرار میگیرد و Backup گرفتن از اطلاعات مهم شرکت نیز سادهتر میشود.
انتقال دیتا به Server به معنی بیاهمیت شدن Storage نیست. اگر چند کاربر قرار است مستقیماً از روی Server با پروژهها و فایلهای مشترک کار کنند، سرعت Disk، ظرفیت، Backup و سلامت Storage اهمیت بیشتری پیدا میکند. برای این بخش میتوانید صفحه سرور و ذخیرهسازی اطلاعات تیشتا را ببینید. اگر در انتخاب نوع Storage بین SSD و HDD مردد هستید، مطلب چه زمانی نباید برای سرور هارد SSD بخرید؟ هم میتواند دید بهتری درباره انتخاب متناسب با نوع استفاده بدهد.
معماری درست برای یک شرکت کوچک یا متوسط چیست؟
در بسیاری از شرکتها لازم نیست برای EPLAN چند سرور مجزا تهیه شود. برای یک تیم کوچک چندنفره میتوان معماری سادهتری داشت: یک Windows Server مرکزی که هم SQL Server روی آن قرار دارد و هم یک فضای File Share کنترلشده برای اطلاعات مشترک EPLAN.
روی کامپیوتر مهندسان، خود EPLAN بهصورت Local نصب میشود. پردازش نرمافزار همچنان روی Workstation انجام میشود، اما اطلاعات مشترک از Server دریافت میشوند.
در این معماری دو مسیر مستقل داریم: مسیر اول EPLAN Client → SQL Server → Parts Database
و مسیر دوم EPLAN Client → File Server → Projects / Macros / Templates / Forms / Documents
این تفکیک ساده است، ولی از بسیاری از مشکلات بعدی جلوگیری میکند. اگر ارتباط Client و Server یا طراحی شبکه نیاز به بازبینی داشته باشد، خدمات نصب و راهاندازی شبکه تیشتا به همین لایه ارتباطی مربوط است.
SQL را نصب کردیم؛ چرا EPLAN هنوز وصل نمیشود؟
اینجا همان بخشی است که معمولاً بیشترین زمان را میگیرد. در یک نمونه واقعی، سؤال اولیه خیلی ساده بود: «آیا میتوان SQL Server را روی Server شرکت نصب کرد و Clientهای EPLAN را به آن متصل کرد؟» پاسخ پشتیبانی نرمافزار از نظر فنی روشن بود: بله؛ اما نصب SQL Server، تنظیم Firewall، ارتباط شبکه، دسترسی کاربران و امنیت Server دیگر موضوع خود EPLAN نیست و باید توسط مسئول IT یا متخصص زیرساخت انجام شود.
دقیقاً همینجاست که پروژه از یک «نصب نرمافزار» به یک «پروژه زیرساخت» تبدیل میشود. ممکن است SQL Server کاملاً سالم باشد، EPLAN هم سالم نصب شده باشد و IP سرور هم در دسترس باشد، ولی اتصال همچنان برقرار نشود.
مشکل میتواند در Driver، نوع Authentication، Certificate، Encryption، Port، SQL Protocol، Windows Firewall یا Permission قرار داشته باشد. برای همین روشن و خاموش کردن تصادفی تنظیمات معمولاً روش خوبی برای عیبیابی نیست. باید لایهها یکییکی تست شوند؛ ابتدا Network، سپس SQL Service، سپس Authentication و در نهایت خود EPLAN.
اگر EPLAN شما به SQL وصل نمیشود و نمیخواهید تنظیمات Server را با آزمونوخطا تغییر دهید،
میتوانید از خدمات پشتیبانی و نگهداری شبکه تیشتا برای بررسی لایههای Server، SQL و Network استفاده کنید.
معرفی خدمات پشتیبانی تیشتا
تلفن: 02192005212
فقط دیتابیس را مرکزی نکنید؛ پروژهها هم باید مدیریت شوند
گاهی شرکت SQL Server را راهاندازی میکند ولی پروژههای EPLAN همچنان روی Desktop یا هارد سیستم کاربران باقی میمانند. در این حالت فقط بخشی از مشکل حل شده است.
برای یک ساختار واقعی سازمانی، بهتر است Projects و Master Dataهای مشترک نیز روی یک Share مرکزی قرار بگیرند؛ با Permission مشخص، Backup مشخص و یک مسیر واحد برای همه Clientها. در عمل، مواردی مانند Projects، Macros، Templates، Forms، Plot Frames، Symbols، Images و Documents میتوانند از مسیرهای شبکهای مشترک استفاده کنند.
نتیجه این است که کاربر شماره ۲ برای پیدا کردن آخرین Macro یا پروژه مجبور نیست از کاربر شماره ۱ فایل بگیرد. اما Share کردن یک Folder و دادن دسترسی Everyone Full Control راهحل حرفهای نیست. دسترسی باید بهاندازه نیاز کاربران تعریف شود و خود File Server نیز وارد برنامه Backup سازمان شود.
همچنین برای پروژههای چندکاربره، محل ذخیره باید واقعاً برای این کار مناسب باشد؛ راهکارهای Sync عمومی مثل OneDrive جای File Server کنترلشده را نمیگیرند.
چه اطلاعاتی بهتر است روی Client بماند؟
مرکزی کردن به این معنا نیست که همهچیز باید از Client حذف شود. خود EPLAN و فایلهای اجرایی نرمافزار بهتر است روی SSD یا NVMe سیستم مهندس نصب شوند. Cacheها و فایلهای موقت نیز Local باقی میمانند.
Server برای اطلاعات مشترک و پایدار سازمان است، نه اینکه هر Read/Write ساده سیستم کاربر را به شبکه منتقل کنیم. این تفاوت در پروژههای واقعی مهم است؛ چون معماری بیشازحد پیچیده میتواند بهاندازه معماری ضعیف دردسر ایجاد کند. در یک تیم دو یا سه نفره معمولاً نیازی به چند SQL Server، Cluster یا طراحیهای Enterprise نیست.
قبل از انتقال EPLAN به Server چه چیزهایی باید بررسی شوند؟
- نسخه دقیق EPLAN چیست و با کدام نسخه Windows Server، SQL Server و Driver سازگار است؟
- Parts Database فعلی کجاست و آیا باید Migration شود؟
- حجم Projects و Master Data چقدر است و رشد سالانه آن چقدر خواهد بود؟
- چند کاربر همزمان کار میکنند؟
- Backup فعلی شرکت چیست و Restore واقعاً تست شده است؟
- کاربران چگونه به Share دسترسی خواهند داشت؟
- اگر Server برای یک ساعت خاموش شود، چه بخشهایی از کار شرکت متوقف میشوند؟
- آیا همان Server سرویسهای دیگری هم اجرا میکند؟
این بررسی معمولاً از خود نصب مهمتر است. خصوصاً در مهاجرت بین نسخههای EPLAN، ساختار Parts Database و Driver سازگار باید قبل از Migration مشخص شود.
اشتباه رایج: همه Clientها را با sa به SQL وصل نکنید
برای راهاندازی اولیه ممکن است Administrator SQL نیاز باشد، اما نگه داشتن حساب مدیریتی SQL روی همه سیستمهای کاربران تصمیم خوبی نیست. در محیط عملیاتی بهتر است Login مخصوص برنامه با سطح دسترسی لازم ساخته شود.
این موضوع دو مزیت دارد: رمز مدیریتی SQL بین کاربران پخش نمیشود و بعداً میتوان دسترسی EPLAN را بدون تغییر حسابهای مدیریتی Server کنترل کرد. همین منطق درباره Folderهای مشترک نیز وجود دارد؛ کاربری که فقط باید پروژه را بخواند، الزاماً نباید مجوز حذف همه آرشیو شرکت را داشته باشد.
Backup بخش اختیاری پروژه نیست
وقتی Parts Database و Projects روی Server منتقل میشوند، اهمیت Backup بیشتر میشود، نه کمتر. قبلاً اگر یک Client خراب میشد ممکن بود فقط اطلاعات همان کاربر آسیب ببیند. بعد از Centralization، Server تبدیل به نقطه مرکزی اطلاعات مهندسی شرکت میشود.
بنابراین Backup باید دو بخش را پوشش دهد: SQL Database و EPLAN Files. و Backup واقعی نباید فقط روی همان هارد یا همان RAID سرور نگهداری شود. برای طراحی Storage و Backup میتوانید بخش سرور و ذخیرهسازی اطلاعات تیشتا را ببینید.
آیا برای EPLAN حتماً Server قدرتمند لازم است؟
نه همیشه. تعداد کاربران، اندازه Parts Database، حجم Projects و سرویسهای دیگری که روی Server اجرا میشوند تعیینکنندهاند. یک شرکت سهنفره با یک شرکت مهندسی چنددهنفره نیاز یکسانی ندارد.
یکی از اشتباهات رایج این است که قبل از اندازهگیری واقعی نیاز، یا Server بسیار ضعیف انتخاب میشود یا برعکس، زیرساختی بسیار گران و پیچیده طراحی میشود که هیچوقت از ظرفیت آن استفاده نمیشود. رویکرد بهتر این است که Server، Storage و Network براساس Load واقعی طراحی شوند و امکان توسعه بعدی نیز در نظر گرفته شود.
یک سناریوی اجرایی معمول
فرض کنید سه مهندس برق در یک شرکت با EPLAN کار میکنند. هر سه نفر EPLAN را روی Workstation خود دارند. بهجای سه Parts Database جداگانه، یک SQL Database مرکزی وجود دارد. Projects و Macros نیز روی File Server شرکت قرار گرفتهاند و همه کاربران مسیر یکسانی دارند. SQL Server Backup جدا دارد و فایلهای پروژه نیز وارد سیستم Backup سازمان شدهاند.
در چنین ساختاری اگر سیستم یکی از مهندسان تعویض شود، قرار نیست دوباره کل دانش فنی شرکت از روی همان PC استخراج شود. Client جدید به Server و Shareهای موجود متصل میشود و کار ادامه پیدا میکند. این تفاوت بین «نصب EPLAN روی چند کامپیوتر» و «استقرار EPLAN در یک زیرساخت سازمانی» است.
اگر EPLAN شما نصب است ولی Server آماده نیست
لازم نیست تیم طراحی برق درگیر تنظیمات SQL Server، Firewall، Driver، File Server و Permission شود. در بسیاری از پروژهها بهترین تقسیم مسئولیت این است که تیم EPLAN مشخص کند چه دیتابیس و چه مسیرهایی لازم دارد و تیم IT زیرساخت Server، Network و Security را آماده و تست کند.
اگر داخل مجموعه مسئول IT ندارید، تیشتا میتواند بخش زیرساخت را از آمادهسازی Windows Server و SQL Server تا ارتباط Clientها، File Sharing، Permission و Backup اجرا کند و در نهایت محیط آماده را در اختیار تیم EPLAN قرار دهد.
لازم نیست قبل از تماس، Server جدید بخرید یا معماری را خودتان حدس بزنید.
ابتدا وضعیت فعلی بررسی میشود و بعد درباره مسیر اجرا تصمیم گرفته میشود.
درخواست بررسی و مشاوره فنی
تلفن: 02192005212
سوالات متداول
آیا SQL Server باعث میشود EPLAN سریعتر شود؟
هدف اصلی SQL Server در این سناریو Centralization و مدیریت بهتر Parts Database است. سرعت نهایی به Server، Storage، Network، Database و Workstation بستگی دارد؛ بنابراین صرف نصب SQL تضمینکننده افزایش سرعت نیست.
آیا تمام پروژههای EPLAN داخل SQL ذخیره میشوند؟
خیر. Parts Database و فایلهای Projects/Master Data دو لایه متفاوت هستند. برای یک استقرار درست باید هر دو بخش جداگانه طراحی شوند.
آیا میتوان SQL و فایلهای EPLAN را روی یک Server گذاشت؟
برای یک مجموعه کوچک یا متوسط، بله؛ مشروط به اینکه منابع Server، Storage، Backup و دسترسیها درست طراحی شده باشند. ایجاد چند Server صرفاً برای پیچیدهتر کردن معماری ضرورتی ندارد.
آیا EPLAN باید روی Server نصب شود؟
در سناریوی معمول، EPLAN روی Workstation کاربران نصب میشود و Clientها به SQL Database و Shareهای شبکهای متصل میشوند.
اگر EPLAN به SQL وصل نشود، مشکل حتماً از EPLAN است؟
خیر. در عمل ممکن است SQL Service، Driver، Authentication، Encryption، Network، Firewall یا Permission عامل مشکل باشد. به همین دلیل تست اتصال باید لایهبهلایه انجام شود.
آیا میشود این کار را بدون توقف طولانی مجموعه انجام داد؟
در اکثر سناریوهای کوچک، بله. اگر Migration از قبل برنامهریزی شود، میتوان Server و Shareها را آماده کرد، اطلاعات را منتقل کرد و سپس Clientها را مرحلهای به محیط جدید متصل کرد.
جمعبندی
مرکزی کردن EPLAN روی شبکه فقط به معنی نصب SQL Server نیست. یک استقرار درست باید سه موضوع را کنار هم حل کند: Parts Database مشترک، فایلهای مهندسی مشترک و زیرساخت Server/Network قابل اعتماد.
اگر هر سه بخش درست طراحی شوند، تغییر Client، اضافه شدن کاربر جدید، Backup و مدیریت اطلاعات بسیار سادهتر میشود. اما اگر فقط SQL نصب شود و پروژهها، دسترسیها و Backup همچنان پراکنده باشند، بخش مهمی از مزیت شبکهای کردن EPLAN از دست میرود.
اگر قصد دارید EPLAN را برای چند کاربر روی Server شرکت راهاندازی کنید یا الان در مرحلهای هستید که Client به SQL متصل نمیشود، با تیم فنی تیشتا تماس بگیرید تا Server، SQL، Network و File Sharing بهصورت یکپارچه بررسی شوند.
