انجمن‌ها

سلام

سیستم نوسا نیاز به MS SQL Server دارد که حتما روی Windows اجرا شده باشد.

ارادت

یعنی امکان اتصال به اوبونتو ندارد

آیا امکان اتصال به دیتا بیسی که برروی یک ویندوز دیگر در شبکه داخلی باشد را دارد یا آنهم خیر؟

برنامه (ها)  بر روی یک ویندوز باشند

دیتا بیس بر روی یک ویندوز دیگر باشد

هر دو ویندوز در شبکه داخلی باشند و IP داخلی داشته باشند

این مورد چطور ، امکان دارد؟

سلام

سرور MS SQL روی یک ویندوز دیگر همان موردی است که همکار ما فرموده‌اند "روی کاغذ میسر است." 15 سال پیش یکبار این روش را بکار برده‌ایم و کار کرده است. الآن با وضعیت Windowsهای جدید و SQL Serverهای بروز واقعا نمی‌دانم چه رفتاری خواهیم دید.

ارادت

با توجه به فرمایش شما، و با توجه به شناخت کمی که من هم از شبکه شدن برنامه نوسا دارم، با این پیش فرض که رایانه ریموت عملکردی مانند کامپیوتر داخل شبکه داشته باشد:
آیا اینکه بر روی آن صرفا MS SQL نصب و دیتا بیس الصاق شود و برنامه کامپلاس و نرم افزار نوسا روی ویندوز دیگری باشند سناریوی مشکوک شما هست؟
که در مقابل دیتا بیس و برنامه کامپلاس روی یک رایانه باشند سناریوی قطعی شما هست
درست متوجه شدم؟
تشکر

سلام

مطمئن نیستم بحث در مورد معماری سیستم و اینکه لایه‌های مختلف چگونه با هم به تبادل داده می‌پردازند در ظرفیت این انجمن باشد - به هر حال با پوزش قبلی از اکثر کاربران، که قاعدتا نباید با این مسائل درگیر باشند، توضحیاتی را به صورت خلاصه ارائه می‌کنم. چنین است که رایانه‌ها در سیستم ما در نقش‌های سرور داده، سرور نرم‌افزار (com+)، سرور Web Api و کلاینت قرار دارند. ارتباط کلاینت با سرور نرم‌افزار با dcom و با سرور Web با https انجام می‌شود. ارتباط سرور Web Api فقط با سرور اصلی است و با dcom انجام می‌شود. ارتباط سرور نرم‌افزار و سرور داده (MS SQL Server) با TCP یا Shared Memory انجام می‌شود.
در این معماری قاعدتا هیچ محدودیتی برای نصب سه سرور برروی سه رایانه‌ی مختلف وجود ندارد. البته با توجه به نقش رایانه‌ها، آنها که سرور را اجرا می‌کنند نمی‌توانند و نباید Remote باشند. نصب سرور Web Api و سرور نرم‌افزار روی دو رایانه‌ی متفاوت، از قضا، یک راهکار متداول است و مشکلی ایجاد نمی‌کند.
در جدا کردن رایانه‌های سرور اصلی و داده چند نکته (فکر کنم 4 عدد بشود) وجود دارد...
1) ساختار امنیتی و تعریف کاربران در سیستم نوسا کاملا مبتنی بر Windows است - با این هدف که مشکلات احتمالی امنیتی سیستم ما دقیقا معادل مشکلات امنیتی Windows باشد و کد اختصاصی برای هک کردن وجود نداشته باشد. در این ساختار کاربران رایانه‌ی سرور یا کاربران Active Directory به عنوان کاربران سیستم تعریف می‌شوند. در ادامه MS SQL Server نیز فقط به کاربران Windows سرویس می‌دهد و کاربران پرخطری که معمولا به صورت جداگانه تعریف می‌شوند (sa و دوستان) در این ساختار جایی ندارند. از آن جلوتر اینکه پایگاه‌های داده‌ی نوسا فقط توسط اعضای گروه Administrators قابل دسترسی هستند. سرور com+ با یک کاربر عضو همین گروه کار می‌کند و قاعدتا فقط این موجود است که امکان دسترسی مستقیم به داده‌ها را دارد. اگر قرار باشد رایانه‌ی سرور com+ متفاوت از رایانه‌ی SQL Server باشد، کاربری که com+ با آن کار می‌کند دیگر نمی‌تواند local باشد و حتما باید عضو domain باشد ولی همزمان در رایانه‌ی com+ و رایانه‌ی SQL Server عضو گروه Administrators باشد.

2) Transactionها (طبیعتا) در هر نرم‌افزاری که با داده‌ها کار می‌کند اهمیت فوق‌العاده‌ای دارند. در Windows این امکان وجود دارد که یک Transaction را از com+ آغاز کنیم و همان را به SQL Server تحویل دهیم و در ادامه دوباره همانرا در com+ تحویل بگیریم. پس کل عملیاتی که سرور(ها) برای هر کاربر انجام می‌دهند در یک Transaction واحد اجرا می‌شوند. اگر هر یک از سرور‌ها در هر مرحله‌ای این Transaction را لغو کنند (مثلا در صورت بروز خطا در هر یک از عملیات)، "کل" عملیات لغو می‌شود (اگر به توضیحات بیشتر در این زمینه علاقه دارید زیرنویس الف را مطالعه کنید). اگر قرار باشد این دو سرور در دو رایانه‌ی مختلف اجرا شوند باید در کل domain مکانیزم distributed transactions فعال شود.

3) اگر قرار باشد کاربری که به سرور com+ متصل شده است فعالیت‌اش به سرور دیگری منتقل شود، com+ باید به جای impersonate، کاربر را delegate کند. البته برای اینکه کاربران قابل delegate باشند تشریفات خاصی در Active Directory لازم است.

4) اگر همه‌ی این دردسرها برای تصمیم‌گیری کفایت نمی‌کند، یادآوری می‌کنیم که جداکردن سرورهای com+ و SQL Server باعث خواهد شد که ارتباط بین این سرورها از callهای ساده‌ی مبتنی بر shared memory به ارتباط TCP تبدیل شود که قاعدتا سرعت کمتری خواهد داشت.

همانطور که قبلا عرض شد، فقط یکبار، تقریبا 15 سال پیش ساختار مورد بحث را برای یکی از مشتریان نوسا آزمایش کردیم و با رعایت همه‌ی تشریفات فوق، کار کرد. اما همانطور که از ابتدا پیش‌بینی می‌کردیم، مجموعه‌ی نکات فوق وضعیتی را پدید آورد که مشتری مزبور از این روش پشیمان شد و دوباره به همان ساختار پیشنهادی ما (یعنی اجرای سرور نوسا و سرور SQL روی یک رایانه) بازگشت.

امیدوارم این توضیحات، برای شما (و همچنین همکاران ما که به درستی تشخیص داده بودند این کارها روی کاغذ میسر است) مفید بوده باشد.

ارادت

پانویس الف:
بسته به منطق تجاری سیستم، تغییراتی که فعالیت کاربران در داده‌ها ایجاد می‌کنند ممکن است از تعداد (بعضا زیادی) تغییرات جزیی‌تر در داده‌ها تشکیل شده باشند: مثلا در درج یک فاکتور فروش در سیستم، فرمانی که به صورت یک واحد عملیات از کلاینت صادر می‌شود صرفا همین تنظیم فاکتور فروش جدید به همراه داده‌های آن است. این فرمان در سرور com+ به عملیات متعددی تفکیک می‌شود که تنوع و تعداد آن، البته، حسب مورد ممکن است متفاوت باشد: درج تعدادی برگه‌ی انبار جدید، درج تعدادی سطر در آن برگه‌های انبار (مشابه و احتمالا همزمان برای برگه‌های درخواست کالا، درخواست انجام خدمات، اجرای خدمات)، درج یک برگه‌ی فروش، درج تعدادی سطر از انواع مختلف (در جدول‌های مختلف) اصلی، جنبی، کسور و اضافات، پورسانت، طرف حساب در آن برگه‌ی فروش...
البته هر برگه‌ی انبار و فروش همراه با سند در سیستم درج می‌شود و نیز سطرهای اصلی این برگه‌ها نیز همراه با رخدادهای مالی درج می‌شوند.
هر یک از این عملیات جزیی ممکن است با خطاهایی مواجه شوند - مثلا کمبود موجودی کالا، که اگرچه ابتدا در کلاینت کنترل شده است اما ممکن است تا زمانی که سرور به پردازش داده‌ها می‌پردازد، توسط سایر کاربران به مصرف رسیده باشد. برای ما بسیار مهم بوده که تمام عملیات مفصل فوق، یا همه به درستی انجام شوند یا هیچیک از آنها انجام نشود و همین نقطه نظر باعث شده که وجود یک Transaction واحد در بین سرور com+ و سرور SQL تا این حد مهم باشد. از تبعات این ساختار یکی این است که احتمال خرابی داده‌ها (به جز البته اشکالات سخت‌افزاری یا قطع برق و مانند آنها و البته به جز اشکالاتی که ممکن است در کار برنامه‌نویس‌ها وجود داشته باشد) بسیار کم شده است و دیگر اینکه وجود Windows و com+ و MS SQL Server در این ساختار نقش اساسی ایفا می‌کنند - البته به جز Transactionها، در تعریف کاربران و رعایت نکات امنیتی در معماری کلی سیستم نیز روی این موجودات حساب شده است.