2011-09-26

על בעיות של ניהול פיתוח לענן


  1. על ניהול סביבת פיתוח מול הענן: הבעיה המרכזית בניהול פיתוח לענן שייכת לתחום הבדיקות  - שום ענן מקומי ושם אימולטור אינו מדמה במאה אחוזים את מה שקורה בענן עצמו. בכל רכיבי הבדיקות, על בעיה זו ניתן להתגבר בשיטת עבודה טובה והקמת מערכת בדיקות בענן עצמו.
  2. על ניהול גרסאות מול הענן:  במידה ואתם עובדים מול לקוחות רגילים ומול לקוחות הרוצים מוצרים בענן  - מהי הדרך הטובה ביותר לנהל את הפיתוח כך שאפשר יהיה לתחזק את שתי המערכות ואת שתי סביבות הבדיקות? אפשר לומר כי מטרת מנהל הפיתוח היא להקים סביבת פיתוח אחת - אם הדבר לא אפשרי צריך למצוא את הפתרון לסינכרון 2 הסביבות.
  3. Check List - למנהל המבולבל - מה הצוות צריך לבצע לפני העלאה לענן:
    1. על הפרוייקט להיות מקומפל בסביבת VS2010 - רצוי 64 Bits ולא 32.
    2. יש להריץ בענן מקומי (אימולטור) ולראות שהכול עובד כהלכה
    3. במידה ואתה משתמש ב Registery או ב Event Log עליך ליצור קובץ StartUp command שבעצם ירוץ בעליית ה Role וייצור את מה שצריך במחשב המיועד לך בענן.
    4. יש ליצור חבילה להעלאה - רצוי לשמור חבילה זו עם מספר ותיאור כללי.
    5. יש להעלות את החבילה ולבדוק שהכול רץ ועובד תקין.
    6. יש להעביר אתר ל PROD
  4. כיצד מנהלים קבצי publish - הקבצים - או החבילות שנוצרות  אינן נשמרות ויכול להיווצר מצב שנדרסה גירסה. לכן מומלץ לשמור בספריה מיוחדת על חבילה עם תיאור כללי ועם פרטים כלליים.
  5. תיעוד בעיית התיעוד, גם היא מהווה בעיה למנהל הפיתוח - ניתן לומר כי עולמות התיעוד וההצגה הסכמתית של המערכת - אינה דומה מערכת שמוצגת כמנוהלת בתוך האירגון עם הצגת האחראים לבין מערכת שיושבת מחוץ למה שהארגון מנהל.
  6. ניהול גרסה מקומית פעילה ועובדת מול גרסה לענן והיכן מתבצעות הבדיקות - פה מגיעים לבעיה המרכזית שבענן אין אפשרות להגיע לתאימות באתר מקומי מול אתר הענן (הדבר בא במיוחד לידי ביטוי לחברה שרוצה להחזיק 2 גירסאות של אתרים  - לענן ולשימוש בתוך החברה.)- אם נתאר אפליקציה קטנה המורכבת משלושה רכיבים: ,SQLAzure,Web Role,Worker Role.
    1. כעת נפרק את 3 הרכיבים לגורמים וניראה מה יש בענן מקומי, SQL 2008R2 או כל גירסה אחרת אינה תואמת את גירסת ה SQL Azure ובעצם הבדיקה אינה אמיתית. לכן ניתן לבדוק ב SQL Server רגיל אבל לדעת את מגבלת הבדיקות.
    2. כידוע בעת קימפול בmode של ענן נוצר ענן מקומי - יש לשים לב כי גם ה WEB site אינם מדמים במלוא מובן המילה את מה שיקרה בענן. יש שוני בהגבלות של 32 מול 64 BITS, ועוד הבדלים שונים.
    3. גם סרביסים רגילים סובלים ממה שמוזכר בנקודה מספר 2
לסיכום ניתן לומר כי הקונפליקטים בהם חי מנהל הפיתוח מול הצוות ומול מקבלי ההחלטות באים לידי ביטוי במישור של ציפיות והגדרות - מה רוצים מהמוצר והיכן רוצים שהוא יחיה, כמו כל מוצר - ככל שרוצים יותר סביבות חיים אפשריות למוצר - הדבר דורש תחזוקה רבה יותר וזמן פיתוח רב יותר.


עוד אכתוב בהמשך פוסטים - המציגים גם פתרונות יצירתיים לבעיות שעלו, וכן על ארכיטקטורה בכלל.

2011-09-20

והיום על Azure Table Storage -ארכיטקטורה חדשה שוחררה

שמעתם על המושג geo-replicating?
ובכן גם אני לא עד שקראתי את הפוסט החדש שהוציאו הצוות שמטפל ב ATS .



מדובר פה על רפליקציה כפולה בין אזורים ובין Data Centers - אח... מתי אנשי ה SQL Azure יעשו גם הם את אותו הדבר?
ובכן העניין הוא כזה - כשם שב SQL Azure הרחבנו והסברנו על מבנה הרפליקציה המובנית בענן - 3 רפליקציות לכל בסיס נתונים - אחד ראשי ושנים משניים, כך גם ל ATS וגם ל BLOBS שנמצאים ב Windows Azure Storage.
כל טבלה או בלוב מרופלקים ל 3 מחשבים וירטואליים אחרים.
כאשר החידוש היום ב ATS הוא שמועברים הנתונים בצורה א-סינכרונית ל DATA Center אחר באותו אזור.
כידוע העולם מחולק ל 3 אזורים כרגע - ראו פוסט מיוחד על זה, ובכל אזור יש 2  DATA Centers, כך למשל בארופה יש מרכז אחד בדבלין ואחד באמסטרדם - אז במקרה שלנו לאחר שנתון ייכנס לטבלה או לבלוב, למשל בדבלין וירופלק ל 3 טבלאות או בלובים באותו מרכז הוא יועבר בצורה א-סינכרונית למרכז השני באמסטרדם. וכן להיפך - הכל לפי הגדרת המשתמש מה ראשי ומה משני


וכך לשאלת רבים - מה ייקרה אם יהיה אסון במרכז אחד - התשובה תהיה שמידע נשמר גם במרכז אחר,
זה חידוש רציני והוא בחינם.
אסון ב DATA Center נקרא בשפה של Microsoft :
"in case of a major data center disaster"


עולם ה noSql קורץ מתמיד...

כבר יש דיונים אצלם על נעילות וכדומה - כיצד יש להתנהג ואיך לכתוב קוד  - אולם זה נושא לפוסט אחר.

2011-09-19

מה יש ומה אין - מה נתמך ומה לא ב SQL Azure

בפרק זה נציג מספר דוגמאות לאילו פונקציות ורכיבים אין ב SQL Azure לעומת SQL Server, לכל אחד ואחד מהרשימה נקדיש בעתיד פוסט בפני עצמו


  • אין job agent
  • אין קריאה בין 2 בסיס נתונים באותו השרת
  • אין אפשרות לפקודה של select into - אלא חייבים להגדיר את הטבלה קודם ואז insert into.
  • אין גיבויים ושחזורים
  • לכל טבלה חייב להיות Clustered Index
  • אין אפשרות לקבוע הודעות מערכת דרך sp_addmassage
ועוד ועוד הרשימה קיימת באתרי מיקרוסופט וגם יכולה להשתנות בכל גירסה.


זה הלינק לרשימת הפקודות הלא נתמכות ב SQL Azure


או כמו שהם קוראים לזה:
Unsupported Transact-SQL Statements 

אם גוללים עמוד למעלה יש רשימה של פונקציות מערכת נתמכות ולא נתמכות.

אפשר לומר כי כרגע הסטנדרטים יותר נמוכים ממה שהורגלנו אליהם, מצד שני זה מאפשר תמיכה בוירטואליות של הפעילות בענן.
כשניגשים לפתח צריך להחליט האם כותבים בתקן של SQL Azure ואז ניתן לתחזק בקלות את הסביבות גם בענן וגם בסביבת הפיתוח או לא.
הכל לשיקול המנהל.

2011-09-11

פורטל חדש יצא ל SQL Azure

שלום רב.
ובכן יצא פורטל חדש ל SQL Azure, צבעוני יותר, יפה יותר, והרבה יותר בשל ומועיל.
כזכור באחד הפוסטים הקודמים דיברנו על אפשרויות חיבור ל - SQL Azure, והראנו שמעבר ל SSMS אפשר להתחבר דרך עמוד ווב.
ובכן כרגע אפשר להתחבר לבסיס הנתונים דרך הפורטל המרכזי עצמו של ה Azure:
נכנסים לפורטל הראשי בוחרים בצד ימים את בסיס הנתונים:


אחרי כן עולה בסרגל למעלה המסך הבא ואז בוחרים בכפתור Manage:

מכאן נפתח עמוד שנותן אפשרות כניסה לבסיס הנתונים, ממלאים מה שצריך ונכנסים פנימה:



המסך בפנים נראה ככה:


על החלק העליון של Database life Cycle נדבר פעם אחרת...
היום נראה מה יש ב Database Schema and Data:
ראשית כאשר אתה מבצע מספר פעולות הוא מראה את העמודים הפתוחים - פונקציה דומה למה שיש ב SSMS תחת השם Windows:


שנית נכנסים פנימה ורואים שהמסך מחולק ל 4 חלקים:


סרגל עליון - מספר 1 -  מאפשר פעולות שונות על טבלאות פרוצדורות וניהול כללי
חלק אמצעי שמאלי - מספר 3 - מציג היכן אתה נמצע בפורטל הכללי
חלק אמצעי שני משמאל - מספר 2 - מציג על איזה חלק אתה עובד בצורה יותר פרטנית - ובכך אילו כפתורים בסרגל למעלה יהיו פתוחים
חלק אמצעי מימין - מספר 4 - מציג לפי כל מצב בו אתה נמצע בחלק 2 נתונים שונים כמו סיכום גודל בסיס הנתונים, רשימת טבלאות, פרוצדורות ועוד.

כאמור כל זה אינו רלוונטי למי שרוצה עדיין להשתמש ב SSMS שיכוליו גדולות יותר.

גם הגירסה של ה SQL Azure השתנתה ועתה היא


  Microsoft SQL Azure (RTM) - 11.0.1467.26 

מצורפים גם 2 לינקים המסכמים את השינויים:






2011-09-09

מה יש ב DATA Centers של Microsoft ?

מהו הענן ? כולם שואלים, האם זה משהו וירטואלי? היכן הוא נמצא ומה יש בו? כיצד הוא מנוהל?
ובכן כידוע מאחורי כל דבר וירטואלי עומדים ברזלים אמיתיים. ומאחורי הענן של MicroSoft עומדים ה DATA CENTERS ב 6 מקומות ברחבי הגולבוס.

DATA CENTERS אלו הם מרכזי מחשבים גדולים וחדישים המכילים כמויות עצומות של שרתים ומהווים בעצם את הענן.

שרתים אלו מתוחזקים ומנוהלים על ידי Microsoft, שהשקיעה ומשקיעה כמויות עצומות של משאבים לתכנון ולבניה.
מי שרוצה לעשות סיור קצר  במרכז המחשבים מוזמן לצפות בוידאו מעניין זה (גם למי שיש מבט ביקורתי על התשבחות שמוצגות בוידאו לא יכול שלא להתפעם מהעוצמה של מרכז המחשבים):

וידאו קצר על DATACenters


2011-09-05

על גיבויים שחזורים ו DRP ב SQL Azure

כידוע בבסיס הנתונים של הענן אין באפשרות המשתמשים לבצע כלל גיבויים.
פקודת BackUp לא עובדת ב SQLAzure!
ישנם 2 סוגי גיבויים:
1. בתור גיבוי יומי או לפי פרק זמן לצורך ניהול אסונות - פה בענן ישנה רפליקציה אוטמטית המתוארת בפרק על הארכיטקטורה, במידה ורוצים גיבויים נוספים למשל בין DATA Centers האפשרויות לביצוע שלהם הן:

   א. כלים חינמיים להורדה מהאינטרנט שלמשל מעבירים כל טבלה ל ATS, ואז יש גיבוי למידע.
   ב. כלים בעלות כספית שמבצעים בצורה מסודרת גיבויים כמו Red Gate, שמגבה ומעביר אליך את בסיס הנתונים
   ג. כלים שהענן עצמו מציע כמו Sql Azure DataSync - שעליו נפרט במקום אחר, ממילא לא זמין כרגע.
   ד. ניתן לבצע COPY בתוך אותו שרת לבסיס הנתונים על ידי פקודה. וכ בעצם ייבצר גיבוי מלא. ישנה פקודה שמראה כל זמן נתון מה מצבו של ה COPY וכמה הועתק.
 CREATE DATABASE DBName_Copy AS COPY OF DBName

ניטור מצבו של ה COPY
'SELECT name, STATE, state_desc,* FROM sys.databases WHERE name = 'DBName_copy




2. בתור גיבוי לצורך שמירת בסיס נתונים או לפני ביצוע פעולות וכדומה - כאשר אתה רוצה בצורה יזומה לשמור את בסיס הנתונים אתה יכול גם כן להשתמש באחד משלושת כלים המוזכרים למעלה, וכמו ניתן בסקריפט להעתיק תוכן של טבלאות או של פרוצדורות לבסיס נתונים מקומי.

לגבי DRP - בעיקרון כל מהותו של ה SQL Azure שלא יהיה צורך ב DRP כלל - והם מבצעים את הרפליקציות וכל הקשור.
לכן בעבודה הרגילה אין בזה צורך שוטף למי שסומך על המוצר.
למי שלא סומך על המוצר מומלץ לבצע אחד  מהגיבויים המוזכרים למעלה.